454cff5introduced haproxy's `tune.ssl.cachesize` for TERMINATED_HTTPS listeners. During a reload of haproxy the old worker process stays running until the new worker process is ready. This means that two TLS session caches are allocated/held simultaneously during a reload of the service. For small Amphorae, this works fine. The default connection limit is 50000, which takes enough of a chunk out of the 50% allocation that there is enough wiggle room for the new haproxy worker to allocate its cache and coexist with the old worker for some time. However, for larger amphorae, the memory calculated for the session cache approaches 50%. haproxy allocates an additional 48 bytes for each 200 byte chunk, so the total memory allocated exceeds 50% of the available memory, triggering the OOM-killer on haproxy reload. Out of an abundance of caution this also reduces the proportion of memory Octavia considers "available" for the TLS session cache from 1/2 to 2/5. Closes-Bug: #2119987 Change-Id: I91b6907c3e3e456860f7274153e0ecf030e0519e Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com> (cherry picked from commit6b51d75b0c) (cherry picked from commitf17744640d)
6 lines
149 B
YAML
6 lines
149 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Reduce the value of tune.ssl.cachesize for HTTPS termination listeners to
|
|
prevent OOM during haproxy reload (LP: #2119987).
|