好如果是这样的话，到真正使用分配时，内存不足了，是不是MySQL就出错了经测试，真的是这样的，到了MYSQL真正想用物理内存时就会出错，但是这里也有个很奇妙的地方就是Linux下的OOM Killer假如我一个程序A已经运行，并且分配了22G内存（机器配置是物理内存16G+SWAP 8G），但是没有真正的映射到物理内存，这是MySQL启动，innodb_buffer_pool_size=8G，启动正常，然后程序A开始实际分配物理内存，一下子只剩下2G SWAP内存了，这时MYSQL也开始实际使用内存，因为只有2G SWAP，所以性能很差，再超过2G时，内存耗尽，OOM Killer开始杀进程，怎么杀呢，谁占用内存多杀谁，于是将进程A杀掉了，内存一下子回来了，MySQL不会退出。但是一般系统中MySQL都是分配内存最大的，所以经常性的是MySQL被杀掉Linux OOM Killer可参见：理解和配置 Linux 下的 OOM Killerthe article you referred to is misleading...OOM actually has a heuristic algorithm based upon weight. So, the statement of "always kill the process that consumes most of memory" is not accurate:The answer lies inside mm/oom_kill.c of the Linux source code. This C code represents the so-called OOM killer of the Linux kernel. The function badness() give a score to each existing processes. The one with highest score will be the victim. The criteria are:#1, VM size. This is not the sum of all allocated pages, but the sum of the size of all VMAs owned by the process. The bigger the VM size, the higher the score. #2, Related to #1, the VM size of the process's children are important too. The VM size is cumulative if a process has one or more children. #3, Processes with task priorities smaller than zero (niced processes) get more points. #4, Superuser processes are important, by assumption; thus they have their scores reduced. #5, Process runtime. The longer it runs, the lower the score. #6, Processes that perform direct hardware access are more immune. #7, The swapper (pid 0) and init (pid 1) processes, as well as any kernel threads immune from the list of potential victims.The process with the biggest score "wins" the election and the OOM killer will kill it very soon.
好如果是这样的话，到真正使用分配时，内存不足了，是不是MySQL就出错了经测试，真的是这样的，到了MYSQL真正想用物理内存时就会出错，但是这里也有个很奇妙的地方就是Linux下的OOM Killer假如我一个程序A已经运行，并且分配了22G内存（机器配置是物理内存16G+SWAP 8G），但是没有真正的映射到物理内存，这是MySQL启动，innodb_buffer_pool_size=8G，启动正常，然后程序A开始实际分配物理内存，一下子只剩下2G SWAP内存了，这时MYSQL也开始实际使用内存，因为只有2G SWAP，所以性能很差，再超过2G时，内存耗尽，OOM Killer开始杀进程，怎么杀呢，谁占用内存多杀谁，于是将进程A杀掉了，内存一下子回来了，MySQL不会退出。但是一般系统中MySQL都是分配内存最大的，所以经常性的是MySQL被杀掉Linux OOM Killer可参见：理解和配置 Linux 下的 OOM Killer
好如果是这样的话，到真正使用分配时，内存不足了，是不是MySQL就出错了经测试，真的是这样的，到了MYSQL真正想用物理内存时就会出错，但是这里也有个很奇妙的地方就是Linux下的OOM Killer假如我一个程序A已经运行，并且分配了22G内存（机器配置是物理内存16G+SWAP 8G），但是没有真正的映射到物理内存，这是MySQL启动，innodb_buffer_pool_size=8G，启动正常，然后程序A开始实际分配物理内存，一下子只剩下2G SWAP内存了，这时MYSQL也开始实际使用内存，因为只有2G SWAP，所以性能很差，再超过2G时，内存耗尽，OOM Killer开始杀进程，怎么杀呢，谁占用内存多杀谁，于是将进程A杀掉了，内存一下子回来了，MySQL不会退出。但是一般系统中MySQL都是分配内存最大的，所以经常性的是MySQL被杀掉Linux OOM Killer可参见：理解和配置 Linux 下的 OOM Killerthe article you referred to is misleading...OOM actually has a heuristic algorithm based upon weight. So, the statement of "always kill the process that consumes most of memory" is not accurate:The answer lies inside mm/oom_kill.c of the Linux source code. This C code represents the so-called OOM killer of the Linux kernel. The function badness() give a score to each existing processes. The one with highest score will be the victim. The criteria are:#1, VM size. This is not the sum of all allocated pages, but the sum of the size of all VMAs owned by the process. The bigger the VM size, the higher the score.
#2, Related to #1, the VM size of the process's children are important too. The VM size is cumulative if a process has one or more children.
#3, Processes with task priorities smaller than zero (niced processes) get more points.
#4, Superuser processes are important, by assumption; thus they have their scores reduced.
#5, Process runtime. The longer it runs, the lower the score.
#6, Processes that perform direct hardware access are more immune.
#7, The swapper (pid 0) and init (pid 1) processes, as well as any kernel threads immune from the list of potential victims.The process with the biggest score "wins" the election and the OOM killer will kill it very soon.