MySQL OOM Series one Linux memory allocation _mysql

RDS (NetEase Cloud Relational database service) has been on the line for some time, successive products have moved into the RDS, online operation and maintenance of the process, but also encountered some did not consider, or consider the incomplete things. The follow-up has time to share to everyone.

Today I want to refer to a 4G RDS instance on the line, a problem with oom (out of memory), and the MySQL process was killed directly. In interpreting this issue, we first need to start with the Linux system memory allocation strategy.
    General write C language programs, we are accustomed to using malloc dynamic application memory Space (Java is responsible for memory management by the JVM), the malloc function to the operating system to request a contiguous unit of memory, and then return the starting address of the space. If the malloc function returns NULL, the system does not have an allocated memory space. This is our general thinking, and of course this is true in some operating systems (Solaris).
     But Linux is not the case, Linux memory allocation is a more active allocation strategy, it assumes that the application of memory space will not immediately use it, so allow a certain amount of sales, When the application really needs to use it, the operating system may have been able to meet the needs of the application by reclaiming other applications ' memory space, simply by allowing applications to have more memory than the actual allocated space (including physical memory and swap), which is called Overcommit.
      This feature is also available within the Linux operating system, and you can adjust the Overcommit policy by setting/proc/sys/overcommit_memory for different values.
     Overcommit_memory can take 3 values:
0: Default value, the Linux kernel through some heuristic algorithm to determine whether the size of the sale and the sale, generally allow a slight sale, Reject some clearly impossible requests and make some rule restrictions, such as the size of different user overcommit.
1: Allow, do not limit the sale, of course, this is not infinite, but also by addressing space constraints, 32-bit system is the most likely only 4g,64 bit system about 16T.
2: Prohibit, prohibit the sale, the system can allocate memory will not exceed swap+ actual physical memory *overcommit_ratio, this value can set by/proc/sys/vm/overcommit_ratio, default 50%.

To verify the Linux memory allocation, we use a small program to test:

#include <stdio.h>
#include <stdlib.h>
#define MEGABYTE 1024*1024
int main (int argc, char * Argv[])
{
    void *myblock = NULL;
    int count = 0;

    while (1)
    {
        Myblock = (void *) malloc (megabyte);
        if (!myblock) break;
        printf ("Currently allocating%d mb\n", ++count);
    }
    
    Exit (0);
}

#include <stdio.h>
#include <stdlib.h>

#define MEGABYTE 1024*1024

int main (int argc, char * Argv[])
{
    void *myblock = NULL;
    int count = 0;

    while (1)
    {
        Myblock = (void *) malloc (megabyte);
        if (!myblock) break;
        memset (myblock,1, megabyte);
        printf ("Currently allocating%d mb\n", ++count);
    }
    Exit (0);
    
}

The former malloc () after the application of memory space, and did not immediately to use it, and the latter on the contrary, each time the application is immediately filled with 1. Let's take a look at the results of two programs running.

This is the result of running on a virtual machine on 1G ram,400m swap, which has requested far more space than the actual memory, which does not exceed the actual memory free space. This validates the previously described Linux memory allocation strategy.
itself this is a system of optimization, understandable. But we know that every "super sale" is based on the assumption that there will be no large number of programs using resources at the same time, which is obviously risky. So Linux uses a Oom killer (out of Memory killer) mechanism to selectively kill some processes to free some memory before the system's available memory (including swap) is about to be used. In the next chapter, we will focus on the Linux OOM killer mechanism.