bryancall commented on issue #9625: URL: https://github.com/apache/trafficserver/issues/9625#issuecomment-4013553857
To answer the outstanding questions: **Why the OOM with 92GB RAM cache on a 128GB system:** Setting `proxy.config.cache.ram_cache.size` to 92GB on a 128GB machine leaves very little room for the OS, ATS's own heap (IO buffers, connection state, header heaps, etc.), and other processes. The RAM cache is in addition to ATS's normal working memory, so OOM is expected in this configuration. A safer guideline is to allocate no more than 50-60% of total RAM to the RAM cache, leaving headroom for ATS internals and the OS page cache (which also helps cache performance). **Freelist behavior (ATS 8.x/9.x):** In ATS 8.x and 9.x, the freelist holds onto freed memory for reuse rather than returning it to the system allocator. This means `free()` doesn't reduce RSS — memory stays mapped for future ATS allocations. This is by design for performance (avoiding repeated `malloc`/`free` syscall overhead), but it makes RSS appear to only grow. Disabling the freelist (`proxy.config.allocator.enable_reclaim: 0`) causes ATS to return memory to the allocator, but may increase allocation overhead. **ATS 10 memory management changes:** ATS 10 includes significant changes to memory management, including removal of the custom freelist allocator in favor of relying on jemalloc (now the default allocator). This means memory reclamation behavior is much improved out of the box — jemalloc handles arena management, dirty page purging, and memory return to the OS automatically. If you're still experiencing memory growth issues, upgrading to ATS 10 is recommended. **SSL session cache note:** @cheluskin reported that reducing `proxy.config.ssl.session_cache.size` from the default (102,400) to 10,240 helped with memory issues on Debian 11. The SSL session cache stores TLS session data for resumption — each entry is typically 2-4KB, so at the default size the cache can consume several hundred MB under heavy TLS load. While the cache doesn't pre-allocate (it grows on demand), reducing it may help in memory-constrained environments. However, setting it too low can hurt TLS performance due to increased full handshakes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
