Recommended maximum number of threads for the SiteMinder Policy Server
Article ID: 74927
Updated On:
Products
Issue/Introduction
Determining the maximum number of concurrent execution threads the Policy Server can use per processor, whether the thread pool is managed dynamically, and whether the values are fixed is necessary to correctly size the database connection pool for the authorization repository.
The Policy Server records thread pool activity in "smps.log", for example: [9450/2216][Tue May 30 2017 12:25:09][CServer.cpp:7484][INFO] [sm-Server-02360] Server 'Stats' command received [9450/2216][][CServer.cpp:5003][INFO][sm-Server-02030] Thread pool: Msgs=48213 Throughput=612.400000/sec Response Time=1.850000ms Wait Time In Queue=0.960000ms Max HP Msg=3 Max NP Msg=48210 Current Depth=6 Max Depth=41 Current High Depth=0 Current Norm Depth=6 Current Threads=32 Max Threads=32 Busy Threads=32
This illustrative example shows the accompanying thread pool statistics line under active load, with all configured threads busy processing requests.
Busy Threads equal to Max Threads, together with a nonzero and growing Current/Max Depth, indicates the thread pool is saturated.
This combination is a signal to increase the maximum thread count using the sizing guidance below.
For a full explanation of each field in this output, see [1].
Environment
- Policy Server 12.8.x
- Policy Server 12.9.x
Resolution
SiteMinder runs as a single-process, multi-threaded application.
The "smpolicysrv" process manages worker threads through a thread pool.
Configure the maximum thread count using the Policy Server Management Console [2].
Consider the following when sizing the thread pool: - The thread pool creates threads as needed to service Web Agent requests. - Systems with multiple CPUs generally support higher thread pool values. - I/O-intensive deployments, such as those with frequent directory access, need a larger thread pool. - Computation-bound deployments, such as those with fully cached policies, work well with a smaller thread pool.
As a starting point, set the thread count to 4 times the number of CPU cores, up to a
maximum of 64 threads.
After applying a starting value, monitor actual load using the "smpolicysrv -stats" command [1] and adjust the thread count so CPU utilization stays between 60% and 80%.
Avoid setting the thread count too high. Excess threads increase context-switching overhead, and on Linux each thread consumes approximately 10 MB of process memory. For
the exact registry procedure used to apply these values, see [3].
Additional Information
Feedback
