libre.sh/keycloak-scim
3
0
Fork 0
Code Issues 15 Pull requests Releases Packages Activity Actions

Reduce internal unsupported options in the Keycloak HA documentation

Browse source 
Closes #26068

Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
This commit is contained in:
Alexander Schwartz 2024-01-10 11:34:16 +01:00 committed by Alexander Schwartz
parent b875acbc20
commit 0f48027ffb
5 changed files with 11 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
docs/guides/high-availability/concepts-threads.adoc
View file

@ -27,11 +27,12 @@ When running on physical machines, adjust the number of worker threads to avoid
Congestion would result in longer response times and an increased memory usage, and eventually an unstable system. Congestion would result in longer response times and an increased memory usage, and eventually an unstable system.
Ideally, you should start with a low limit of threads and adjust it accordingly to the target throughput and response time. Ideally, you should start with a low limit of threads and adjust it accordingly to the target throughput and response time.
When the load and the number of threads increases, the bottleneck will usually be the database connections. When the load and the number of threads increases, the bottleneck can become be the database connections.
Once a request cannot acquire a database connection, it will fail with a message in the log like `Unable to acquire JDBC Connection`. Once a request cannot acquire a database connection within 5 seconds, it will fail with a message in the log like `Unable to acquire JDBC Connection`.
The caller will receive a response with a 5xx HTTP status code indicating a server side error. The caller will receive a response with a 5xx HTTP status code indicating a server side error.
With the number of threads in the executor pool being an order of magnitude larger than the number of database connections and with requests failing when no database connection is available within the https://quarkus.io/guides/all-config#quarkus-agroal_quarkus.datasource.jdbc.acquisition-timeout[`quarkus.datasource.jdbc.acquisition-timeout`] (5 seconds default), this is somewhat of a https://en.wikipedia.org/wiki/Demand_response#Load_shedding[load-shedding behavior] where it returns an error response instead of queueing requests for an indefinite amount of time. If you increase the number of database connections and the number of threads too much, the system will be congested under a high load with requests queueing up and all callers getting a bad performance.
Low numbers ensure fast response times for all clients, even if there is an occasionally failing request when there is a load spike.
=== JGroups connection pool === JGroups connection pool

2
docs/guides/high-availability/deploy-keycloak-kubernetes.adoc
View file

@ -43,8 +43,6 @@ The number of all {project_name} threads in the StatefulSet should not exceed th
You might consider limiting the number of {project_name} threads further because multiple concurrent threads will lead to throttling by Kubernetes once the requested CPU limit is reached. You might consider limiting the number of {project_name} threads further because multiple concurrent threads will lead to throttling by Kubernetes once the requested CPU limit is reached.
See the <@links.ha id="concepts-threads" /> {section} for details. See the <@links.ha id="concepts-threads" /> {section} for details.
<5> The JVM options set additional parameters: <5> The JVM options set additional parameters:
* `jgroups.thread_dumps_threshold` ensures that a log message "`thread pool is full`" appears once the JGroup thread pool is full for the first time.
See the <@links.ha id="concepts-threads" /> {section} for details.
* Adjust the memory settings for the heap. * Adjust the memory settings for the heap.
== Verifying the deployment == Verifying the deployment

2
docs/guides/high-availability/examples/generated/keycloak-ispn.yaml
View file

@ -804,7 +804,7 @@ spec:
# tag::keycloak-ispn[] # tag::keycloak-ispn[]
- name: JAVA_OPTS_APPEND # <5> - name: JAVA_OPTS_APPEND # <5>
value: > value: >
-Djgroups.thread_dumps_threshold=1 -Djboss.site.name=keycloak -Djboss.site.name=keycloak
# end::keycloak[] # end::keycloak[]
# end::keycloak-ispn[] # end::keycloak-ispn[]

2
docs/guides/high-availability/examples/generated/keycloak.yaml
View file

@ -480,7 +480,7 @@ spec:
# tag::keycloak-ispn[] # tag::keycloak-ispn[]
- name: JAVA_OPTS_APPEND # <5> - name: JAVA_OPTS_APPEND # <5>
value: > value: >
-Xms512m -Xmx1524m -Djgroups.thread_dumps_threshold=1 -Xms512m -Xmx1524m
# end::keycloak[] # end::keycloak[]
# end::keycloak-ispn[] # end::keycloak-ispn[]

8
docs/guides/high-availability/partials/threads/executor-jgroups-thread-calculation.adoc
View file

@ -1,3 +1,5 @@
The number of JGroup threads is `200` by default, and can be configured using the property Java system property `jgroups.thread_pool.max_threads`. The number of JGroup threads is `200` by default.
As shown in experiments, assuming a Keycloak cluster with 4 Pods, each Pod shouldn't have more than 50 worker threads so that it doesn't run out of threads in the JGroup thread pool of 200. While it can be configured using the property Java system property `jgroups.thread_pool.max_threads`, we advise keeping it at this value.
Use the Quarkus configuration options `quarkus.thread-pool.max-threads` to configure the maximum number of worker threads. As shown in experiments, the total number of Quarkus worker threads in the cluster must not exceed the number of threads in the JGroup thread pool of 200 in each node to avoid deadlocks in the JGroups communication.
Given a Keycloak cluster with four Pods, each Pod should then have 50 Quarkus worker threads.
Use the Quarkus configuration options `quarkus.thread-pool.max-threads` to configure the maximum number of Quarkus worker threads.