MySQL OOM Series III get rid of MySQL by kill Doom _mysql

In the previous two chapters, we analyzed the Linux memory allocation strategy and Linux through the use of Oom_killer mechanism to solve the "over selling" risk, MySQL, like other applications, within the scope of the operating system can also be sold, the General people understand, innodb_ The Buffer_pool must be less than the actual physical memory, or MySQL will fail to start. In fact, this is a misunderstanding, this is not the MySQL layer control, this is the operating system (OS) layer control, is the previous mentioned/proc/sys/overcommit_memory control OS to allow "over sale." If "Innodb_buffer_pool" is allowed, it can be far more than the actual amount of memory space, but this part of the space is not used. We can do a small experiment, see the following figure:

MySQL's innodb_buffer_pool is open 5G, but the actual memory is only 3g.
Speaking so much, now back to the first mention of the RDS instance of the OS kill the problem, we also mentioned earlier, once the instance available memory is not enough, MySQL will generally become Oom_killer's preferred target. Here are two questions:

1. Why is there not enough memory?
2. How to let MySQL get rid of the fate of the kill?
First, let's take a look at the first question. The problem of insufficient memory causes a lot of reasons, but mainly on two aspects, the first is the memory of MySQL's own planning problems. The second is the general deployment of MySQL server, will deploy a lot of monitoring or timed task scripts, and these scripts often lack the necessary memory limits, resulting in the peak time to occupy a large amount of memory, leading to trigger the Linux oom_killer mechanism, MySQL was innocent sacrifice.
So how can MySQL get rid of the fate of the kill? MySQL was killed at the root of the Linux sales of the memory allocation mechanism, mentioned earlier, as long as the existence of such a mechanism, it is impossible to completely avoid the risk of an application to kill. That will make MySQL must not be killed, can only prohibit the operating system beyond the actual memory space allocated memory. But as we mentioned earlier, we do not recommend this for servers that have MySQL deployed, because many of MySQL's memory is just beginning to apply, not immediately, and once the OS is banned, this not only puts more stringent demands on MySQL's own memory plan, There are also problems with the inability to fully use memory. At the same time, MySQL's private memory of each connection is dynamically allocated, if not allocated, will directly lead to server crash, this will increase the risk of MySQL crash.
Since the operating system is limited to avoid being killed completely, you can only minimize the chance that MySQL will be killed. I think there are at least 3 things to do:

1 reasonable planning of MySQL memory use.
2) Adjust the Oom_adj parameters, the MySQL is Oom_killer lock priority reduction.
3 to strengthen the memory monitoring and alarm, once the alarm, the DBA should quickly intervene, kill some of the more memory-intensive connections.