If you run your Gateway with large numbers of clients and large container payloads, for example, 2 MB or more, you should consider using a 64-bit z/OS® Gateway.
For the Gateway daemon running under the 64-bit SDK for z/OS. the memory requirements vary based on environmental factors or the characteristics of the workload. This topic describes a configuration which could not be achieved with a Gateway daemon using the 31-bit SDK for z/OS.
In this example, a workload of 250 concurrent clients each sending ECI requests with 2 MB containers to CICS® TS, requires a Gateway daemon defined with 250 connection managers, 250 worker threads, and 250 IPIC send sessions. To avoid running out of memory you would require a maximum heap size (-Xmx), of at least 1536 MB. Better performance is obtained with a maximum heap size of 2048 MB, to avoid excessive garbage collection. A Gateway daemon with a heap size of 2048 MB is only possible with the 64-bit SDK for z/OS.
The maximum heap size directly affects the value that must be used for MEMLIMIT, and the Gateway daemon threads still utilize 31-bit storage. In this example, the REGION size was set to 300 MB, tuned by reviewing the SE_CELOAL statistic, and MEMLIMIT set to 3.3 GB.
To tune the heap size, you should review the SE_CHEAPGCMIN statistic as a percentage of SE_SHEAPMAX to ensure the value is in the range 40-70%. If the percentage goes above 70% you can increase the maximum heap size. If the percentage is below 40% then you can reduce the maximum heap size.
Increasing the ECI payload size to 4 MB containers, the heap size needs to be increased to avoid excessive garbage collection. In the example of 250 clients, -Xmx was set to 2048 MB. Increasing the heap size requires MEMLIMIT to be increased. In this example, 3.73 GB was used, so MEMLIMIT was set to 4 GB.
Gateway daemon performance improvements may also be gained using the Java™ directive -Xcompressedrefs with 64-bit SDK for z/OS. The compressed references feature was added to the IBM® Developer Kit for Java 6, 64-bit edition, J9 Java virtual machine (JVM) and Just-in-Time (JIT) compiler to provide relief for memory footprint growth incurred when migrating from a 31-bit JVM to a 64-bit JVM.
Table 1 contains some example scenarios displaying the benefits of using a 64-bit gateway with increasing channel sizes: All scenarios use 200 clients, with 250 connection managers, 250 worker threads and 250 IPIC Send Sessions defined in the configuration file.
Channel Size | MEMLIMIT | REGION | SE_CELOAL | SE_C31MAX | Max Heap | SE_CHEAPGCMIN | SE_SHEAPMAX | Heap Occupancy |
---|---|---|---|---|---|---|---|---|
1 MB | 4 GB | 300 MB | 262 MB | 1688 MB | 2048 MB | 320010016 | 2147483648 | 15% |
2 MB | 4 GB | 300 MB | 262 MB | 1688 MB | 2048 MB | 315898512 | 2147483648 | 15% |
3 MB | 4 GB | 300 MB | 262 MB | 1688 MB | 2048 MB | 492042016 | 2147483648 | 23% |
4 MB | 4 GB | 300 MB | 262 MB | 1688 MB | 2048 MB | 451839424 | 2147483648 | 21% |
For optimum performance you should aim for a heap occupancy of between 30% and 70%.
In a similar scenario with a 31-bit Gateway, only a 1 MB channel with 200 clients is possible. 2 MB channels caused the Gateway daemon to run out of memory. See Table 2.
Channel Size | MEMLIMIT | REGION | SE_CELOAL | SE_C31MAX | Max Heap | SE_CHEAPGCMIN | SE_SHEAPMAX | Heap Occupancy |
---|---|---|---|---|---|---|---|---|
1 MB | n/a | 800 MB | 800 MB | 1688 MB | 500 MB | 195826792 | 524288000 | 37% |