Used to think that Mysql,innodb_buffer_pool_size=8g,mysql together will take up 8G of memory (think top can see the memory is used 8G), but recently carefully studied, it is not the case (perhaps their own Linux malloc memory allocation just knows a fur bar), when MySQL starts up, it actually allocates the address space in virtual memory and does not actually map to physical memory.
Because malloc allocates memory first in virtual memory, it is actually mapped to physical memory.
So this place, if the machine memory is not used properly, when MySQL really want to map physical memory, if the physical memory is not enough, it will be error or even exit.
But here's a fantastic place to be: The Oom Killer under Linux.
If I have a program a already running, and allocate 22G of memory (machine configuration is physical memory 16g+swap 8G), but there is no real mapping to physical memory;
At this time MySQL start, innodb_buffer_pool_size=8g, start normal;
Then program a begins to physically allocate physical memory, leaving only 2G of swap memory at a sudden;
At this time MySQL also began to actually use memory, because only 2G SWAP, so the performance is very poor, and then more than 2G, memory exhaustion, then oom killer start killing process, how to kill, who occupy memory more kill who, so will process a killed, memory suddenly back, MySQL will not quit;
However, in general, MySQL is the largest allocation of memory, so the recurrent is MySQL was killed.
Linux Oom Killer can be found in: Understanding and configuring Oom Killer under Linux