Memory overload protection

Memory overload protection limits the rate at which the on demand router (ODR) forwards traffic in order to prevent an out of memory exception from occurring in an application server. If traffic without server affinity arrives at the ODR and the rate for all potential servers has been exceeded, the traffic is rejected. Memory overload protection does not reject traffic that has server affinity. For example, HTTP requests with session affinity or SIP in-dialog messages.

To protect against memory overload, memory overload protection must initially discover the maximum rate, that is, calls per second, that can be sustained without exceeding the maximum percentage of the maximum heap size. As it is discovering the maximum rate, memory overload protection slowly allows more traffic through without affinity, but will reject the remainder. Initially, a potentially large number of HTTP requests or SIP messages without affinity are rejected with a 503 (unless the error code is changed). Intelligent Management persists the maximum rate across server restarts, so it needs to learn the maximum rate once. The maximum rate can change over time due to changes in the session or dialog lifetimes, but these lifetimes generally change relatively slowly and memory overload protection is able to react to such changes. To discover the maximum rate, the product must keep the rate relatively steady for at least an averaging window. The averaging window must be at least as long as the lifetime of most of the HTTP sessions, SIP dialogs, or application sessions. Therefore, the longer the averaging window, the longer it will take to initialize.

For SIP and HTTP, memory overload protection and CPU overload protection are not guaranteed to work if a dynamic cluster is in automatic mode, because of the CPU and heap overhead incurred by replication

WebSphere eXtreme Scale considerations

WebSphere eXtreme Scale might allocate additional memory in a running application server when another application server starts or stops. Memory overload protection does not currently control this memory allocation. So, if the memory utilization is already high, the additional uncontrolled allocation of memory can cause an out of memory exception to occur. For example, if the maximum percentage memory setting is 90% and the current heap utilization is near 90% in application server AS1, and application server AS2 starts or stops, an out of memory exception might occur in AS1 due to replication to AS2. The maximum heap percentage should be set low enough so that there is always enough memory in reserve for the potential replication needs when an application server starts or stops. Memory overload protection will prevent an OutOfMemoryException in a dynamic cluster if the maximum percentage memory setting is set to 56%.

Related concepts

Overview of request flow prioritization

Related tasks

Configure memory overload protection

Related information:

Intelligent Management: autonomic request flow manager custom properties