APAR status
Closed as program error.
Error description
After installing fix pack 18.0.0.1, some users occasionally observed the Liberty default executor thread pool growing erratically to large sizes for short periods of time, even though the Liberty server was processing little or no work. As a result, Liberty could abend if the Operating System/environment's per-process thread limits or it's native memory is exhausted while attempting to create these new threads.
Local fix
Setting Liberty's maxThreads property will prevent the thread pool from growing beyond that size regardless of workload, even if the algorithm would otherwise have decided to grow. This can also help ensure that Liberty does not attempt to use more threads than the environment pre-process limits would allow. For z/OS Connect: As a circumvention to this problem check OMVS MAXTHREADS and update server.xml to set <executor name="Default Executor" maxThreads="nnn"/> where maxThreads is approximately 30 below the nnn value that was specified.
Problem summary
**************************************************************** * USERS AFFECTED: All users of IBM WebSphere Application * * Server Liberty * **************************************************************** * PROBLEM DESCRIPTION: Occasional/random excess threadpool * * growth in low/no-load situations * **************************************************************** * RECOMMENDATION: * **************************************************************** Changes made in 18001 to enable the threadpool controller to better handle high-latency workloads had the unexpected side effect of occasionally causing the poolsize to grow to excessive size.
Problem conclusion
The threadpool controller mostly decides to grow/shrink the pool based on historical throughput data at different pool sizes. This core mechanism is augmented by some general principles, for example: If the CPU usage is high, the controller becomes reluctant to add more threads, because more threads is unlikely to improve throughput in a high-cpu environment. The problem reported in this APAR is now addressed by a similar 'rule-of-thumb': If the throughput is low (measured as ratio of tasks completed by the threadpool per controller cycle to number of threads in the pool) and no tasks are waiting in queue, the controller will be reluctant to grow the threadpool. This provides a general downward pressure on the poolsize in no/low- load situations, which greatly reduces the opportunity for the type of excess pool growth reported in this APAR. The fix for this APAR is currently targeted for inclusion in fix pack 18.0.0.4. Please refer to the Recommended Updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
Temporary fix
This problem can be worked around by setting the maxThreads value in the executor clause of the server.xml to a value suitable for the particular environment. <executor maxThreads="N" />
Comments
APAR Information
APAR number
PH03409
Reported component name
LIBERTY PROF -
Reported component ID
5655W6514
Reported release
CD0
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2018-09-28
Closed date
2018-12-11
Last modified date
2018-12-11
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
LIBERTY PROF -
Fixed component ID
5655W6514
Applicable component levels
RCD0 PSY
UP
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M"},"Platform":[{"code":"PF054","label":"z\/OS"}],"Version":"CD0"}]
Document Information
Modified date:
08 September 2021