Maximum number of threads
Article ID: 74927
Updated On:
Products
CA Single Sign On Secure Proxy Server (SiteMinder)
CA Single Sign On SOA Security Manager (SiteMinder)
CA Single Sign-On
Issue/Introduction
We need to know the maximum number of concurrent execution threads we can set in the Policy Server by processor. There is a pool of execution threads used? Is this configured dynamically somewhere or it is a fixed value?
Our goal is to know this maximum to configure the number of connections pool from CA SSO to DB layer, where this DB will be the repository of authorizations.
Environment
Policy Server R12.x
Resolution
First thing to note, is that Support cannot give specific recommendations on tuning as it depends on many factors specific to the environment, as there is no maximum number of threads you can set. The number of maximum threads can be configured through the Policy Server Management Console (smconsole).
Siteminder is a Single-Process/Multi-Threaded application. The single process being the 'smpolicysrv' process. A Process is simply an independent execution unit that contains its own state information and uses its own address spaces.
A Thread is a lightweight process contained within a process. In this case the thread would be contained within the smpolicysrv process. With multiple threads, each thread can work independently of the others to process a given task. This multi-threading model allows us to facilitate multi-tasking. In the SMPS.log, the first entry we see is the [<ProcessID>/<ThreadID>]. Example:
[2738/3650276240][Tue May 30 2017 12:25:09][CServer.cpp:7484][INFO] [sm-Server-02360] Server 'Stats' command received
Process ID = 2738
ThreadID = 3650276240
As mentioned above the maximum threads can be specified in the smconsole Maximum Threads field:
Regarding Maximum Threads field
===============================
Determines the maximum number of worker threads in the thread pool. Threads are created as needed and reside in a thread pool.
Requests received through connections with Web Agents are serviced by available threads in the thread pool.
For systems with multiple CPUs, a higher maximum thread pool value is desirable. The higher value provides more threads for the increased performance provided by the processing power of multiple CPU systems.
For deployments that are bound by computation, such as those that include fully-cached policy stores and static responses, a smaller thread pool size can be used.
For deployments that require constant input/output with directories, a larger thread pool size is desirable.
You can use the OneView monitor or run the stats command (smpolicysrv -stats) periodically to show how many threads are currently used and the maximum number of threads used, as well as the depth of the thread queue to fine-tune your environment.
However, you can check for yourself the impact of changing the threadpool size via the OneView monitor or the counters in the stats data over time. If there are sufficient Worker Threads defined for the load on the Policy server, then the Policy Server should be able to keep up with the load and the “Max NP Msg” value should be low. If the value grows and it is high, then you could add additional worker threads to handle the load, after determining if the issue is due to a poor performing back-end User Directory or not.
Adding more threads when the issue is actually the back-end directory is not really going to help.
Note that you need to make sure not to configure the Policy Server to have too many worker threads, since:
1. Using too many threads can cause excessive context switch (switching from one thread to another), which impose an expensive overhead.
2. On Linux, each thread uses 10MB of memory from the Policy Server's process memory. Using too many threads may result in running out of memory.
A rule of thumb for determining the number of threads is to use 4*(# of cores). This formula works pretty well as long as the result does not exceed 64 threads. The best way to get to the optimal number is to monitor the machine under load. The machine needs to be able to reach 60%-80% of CPU utilization under high load. If the CPU utilization is lower than that, consider adding additional worker threads. Notice that sometimes it makes sense to increase the number of connections to the backend user stores (using max connections, or for LDAP, using multiple LDAP banks), to increase the number of concurrent queries going to the user stores (check the CPU utilization of the user store machine for that).
Also, increasing the number of Worker Threads when there is a bottleneck getting to the user directory would not improve performance. Increasing the number of User Directory Connections available to the Policy Server using Alias entries would improve performance, not to mention properly tuning and indexing your directory so there is no delay in responding to search requests.
The number of threads that are appropriate for an environment is dictated by more than just the number of CPUs, so there is no exact “formula” based on the number of CPUs. There are multiple factors that would come into play. This is a tuning exercise that is outside of the scope of Support, which is why a customer should engage CA Services for assistance in properly tuning their environment for the expected load if they cannot tune the environment on their own.
Siteminder is a Single-Process/Multi-Threaded application. The single process being the 'smpolicysrv' process. A Process is simply an independent execution unit that contains its own state information and uses its own address spaces.
A Thread is a lightweight process contained within a process. In this case the thread would be contained within the smpolicysrv process. With multiple threads, each thread can work independently of the others to process a given task. This multi-threading model allows us to facilitate multi-tasking. In the SMPS.log, the first entry we see is the [<ProcessID>/<ThreadID>]. Example:
[2738/3650276240][Tue May 30 2017 12:25:09][CServer.cpp:7484][INFO] [sm-Server-02360] Server 'Stats' command received
Process ID = 2738
ThreadID = 3650276240
As mentioned above the maximum threads can be specified in the smconsole Maximum Threads field:
Regarding Maximum Threads field
===============================
Determines the maximum number of worker threads in the thread pool. Threads are created as needed and reside in a thread pool.
Requests received through connections with Web Agents are serviced by available threads in the thread pool.
For systems with multiple CPUs, a higher maximum thread pool value is desirable. The higher value provides more threads for the increased performance provided by the processing power of multiple CPU systems.
For deployments that are bound by computation, such as those that include fully-cached policy stores and static responses, a smaller thread pool size can be used.
For deployments that require constant input/output with directories, a larger thread pool size is desirable.
You can use the OneView monitor or run the stats command (smpolicysrv -stats) periodically to show how many threads are currently used and the maximum number of threads used, as well as the depth of the thread queue to fine-tune your environment.
However, you can check for yourself the impact of changing the threadpool size via the OneView monitor or the counters in the stats data over time. If there are sufficient Worker Threads defined for the load on the Policy server, then the Policy Server should be able to keep up with the load and the “Max NP Msg” value should be low. If the value grows and it is high, then you could add additional worker threads to handle the load, after determining if the issue is due to a poor performing back-end User Directory or not.
Adding more threads when the issue is actually the back-end directory is not really going to help.
Note that you need to make sure not to configure the Policy Server to have too many worker threads, since:
1. Using too many threads can cause excessive context switch (switching from one thread to another), which impose an expensive overhead.
2. On Linux, each thread uses 10MB of memory from the Policy Server's process memory. Using too many threads may result in running out of memory.
A rule of thumb for determining the number of threads is to use 4*(# of cores). This formula works pretty well as long as the result does not exceed 64 threads. The best way to get to the optimal number is to monitor the machine under load. The machine needs to be able to reach 60%-80% of CPU utilization under high load. If the CPU utilization is lower than that, consider adding additional worker threads. Notice that sometimes it makes sense to increase the number of connections to the backend user stores (using max connections, or for LDAP, using multiple LDAP banks), to increase the number of concurrent queries going to the user stores (check the CPU utilization of the user store machine for that).
Also, increasing the number of Worker Threads when there is a bottleneck getting to the user directory would not improve performance. Increasing the number of User Directory Connections available to the Policy Server using Alias entries would improve performance, not to mention properly tuning and indexing your directory so there is no delay in responding to search requests.
The number of threads that are appropriate for an environment is dictated by more than just the number of CPUs, so there is no exact “formula” based on the number of CPUs. There are multiple factors that would come into play. This is a tuning exercise that is outside of the scope of Support, which is why a customer should engage CA Services for assistance in properly tuning their environment for the expected load if they cannot tune the environment on their own.
Additional Information
https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/siteminder/12-8/implementing/implementing-siteminder/performance-tuning.html
Feedback
Yes
No
Powered by
