搜索

第 13 章 配置线程池的概念

download PDF

本节旨在帮助您了解如何为红帽构建的 Keycloak 配置线程池的注意事项和最佳实践。对于应用此功能的配置,请访问红帽构建的 Keycloak Operator 的 Deploy Red Hat build of HA

13.1. 概念

13.1.1. Quarkus executor 池

红帽构建的 Keycloak 请求以及阻塞探测由 executor 池处理。根据可用的 CPU 内核,最大为 200 或多个线程。线程根据需要创建,并在不再需要时结束,因此系统将自动缩放和缩减。红帽构建的 Keycloak 允许通过 http-pool-max-threads 配置选项配置最大线程池大小。请参阅 使用红帽构建的 Keycloak Operator 部署红帽 Keycloak for HA

在 Kubernetes 上运行时,调整 worker 线程数量,以避免创建比 Pod 允许的 CPU 限值更多的负载,从而避免节流,从而导致拥塞。在物理机上运行时,调整 worker 线程数量,以避免创建比节点可以处理的负载更多的负载以避免拥塞。拥塞会导致响应时间较长,增加内存用量,最终会导致系统不稳定。

理想情况下,您应该从低线程限制开始,并将其相应地调整到目标吞吐量和响应时间。当负载和线程数量增加时,数据库连接也可以成为瓶颈。当请求在 5 秒内无法获取数据库连接后,它将失败,并显示 Unable to acquire JDBC Connection 的消息。调用者将收到显示服务器端错误的 5xx HTTP 状态代码的响应。

如果您增加数据库连接的数量和线程数量过多,则系统将处于高负载下,请求排队,从而导致性能不良。数据库连接的数量通过 Database 设置 db-pool-initial-sizedb-pool-min-sizedb-pool-max-size 分别进行配置。低数字可确保所有客户端快速响应时间,即使存在负载激增时偶尔会出现请求失败。

13.1.2. JGroups 连接池

集群中所有红帽构建的 Keycloak 节点合并的 executor 线程数量不应超过 JGroups 线程池中提供的线程数量,以避免错误 org.jgroups.util.ThreadPool: thread pool is full。要查看第一次发生错误,系统属性 jgroups.thread_dumps_threshold 需要设为 1,否则消息仅在 10000 请求被拒绝后才会出现。

JGroup 线程的数量默认为 200。虽然可以使用属性 Java 系统属性 jgroups.thread_pool.max_threads 进行配置,但我们建议将其保持在这个值中。如试验中所示,集群中 Quarkus worker 线程总数不能超过每个节点 200 的 JGroup 线程池中的线程数量,以避免 JGroups 通信中的死锁。鉴于带有四个 Pod 的红帽构建的 Keycloak 集群,则每个 Pod 应该有 50 Quarkus worker 线程。使用红帽构建的 Keycloak 配置选项 http-pool-max-threads 来配置最大 Quarkus worker 线程数。

使用指标来监控池中的总 JGroup 线程,以及池中活跃的线程。当使用 TCP 作为 JGroups 传输协议时,指标 vendor_jgroups_tcp_get_thread_pool_sizevendor_jgroups_tcp_get_thread_pool_size_active 可用于监控。使用 UDP 时,指标 vendor_jgroups_udp_get_thread_pool_sizevendor_jgroups_udp_get_thread_pool_size_active 可用。这对于监控限制 Quarkus 线程池大小会保持在最大 JGroup 线程池大小下的活跃 JGroup 线程数量。

13.1.3. Load Shedding

默认情况下,红帽构建的 Keycloak 将无限地排队所有传入的请求,即使请求处理停滞也是如此。这将在 Pod 中使用额外的内存,可能会耗尽负载均衡器中的资源,请求最终会在客户端超时,而无需客户端了解请求是否已被处理。要限制红帽构建的 Keycloak 中排队的请求数,请设置额外的 Quarkus 配置选项。

配置 http-max-queued-requests 以指定最大队列长度,以便在超过此队列大小后实现有效的负载。假设红帽构建的 Keycloak Pod 每秒处理 200 个请求,队列 1000 会导致最多等待时间 5 秒。

当此设置处于活动状态时,超过排队请求数量的请求将返回 HTTP 503 错误。Red Hat build of Keycloak 会在日志中记录错误信息。

13.1.4. probes

红帽构建的 Keycloak 存活度探测不是阻止的,以避免在高负载下重启 Pod。

总体健康探测和就绪度探测在某些情况下可以探测到数据库,因此它们可能会在高负载下失败。因此,Pod 可能会在高负载下变得未就绪。

13.1.5. OS 资源

为了让 Java 创建线程,在 Linux 上运行时需要文件句柄。因此,打开的文件数量(作为 ulimit -n 在 Linux 上检索)需要为红帽构建的 Keycloak 提供头空间,以增加所需的线程数量。每个线程也会消耗内存,容器内存限值需要设置为允许此值或 Pod 由 Kubernetes 终止的值。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.