在我们的一台 MySQL master 上，OOM Killer 被调用并杀死了 MySQL 服务器，导致严重中断。以下是内核日志：
[2006013.230723] mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
[2006013.230733] Pid: 1319, comm: mysqld Tainted: P 2.6.32-5-amd64 #1
[2006013.230735] Call Trace:
[2006013.230744] [<ffffffff810b6708>] ? oom_kill_process+0x7f/0x23f
[2006013.230750] [<ffffffff8106bde2>] ? timekeeping_get_ns+0xe/0x2e
[2006013.230754] [<ffffffff810b6c2c>] ? __out_of_memory+0x12a/0x141
[2006013.230757] [<ffffffff810b6d83>] ? out_of_memory+0x140/0x172
[2006013.230762] [<ffffffff810baae8>] ? __alloc_pages_nodemask+0x4ec/0x5fc
[2006013.230768] [<ffffffff812fca02>] ? io_schedule+0x93/0xb7
[2006013.230773] [<ffffffff810bc051>] ? __do_page_cache_readahead+0x9b/0x1b4
[2006013.230778] [<ffffffff810652f8>] ? wake_bit_function+0x0/0x23
[2006013.230782] [<ffffffff810bc186>] ? ra_submit+0x1c/0x20
[2006013.230785] [<ffffffff810b4e53>] ? filemap_fault+0x17d/0x2f6
[2006013.230790] [<ffffffff810cae1e>] ? __do_fault+0x54/0x3c3
[2006013.230794] [<ffffffff812fce29>] ? __wait_on_bit_lock+0x76/0x84
[2006013.230798] [<ffffffff810cd172>] ? handle_mm_fault+0x3b8/0x80f
[2006013.230803] [<ffffffff8103a9a0>] ? pick_next_task+0x21/0x3c
[2006013.230808] [<ffffffff810168ba>] ? sched_clock+0x5/0x8
[2006013.230813] [<ffffffff81300186>] ? do_page_fault+0x2e0/0x2fc
[2006013.230817] [<ffffffff812fe025>] ? page_fault+0x25/0x30
这台机器有 64GB RAM。
以下是 mysql 配置变量：
innodb_buffer_pool_size = 48G
innodb_additional_mem_pool_size = 512M
innodb_log_buffer_size = 64M
除了一些 nagios 插件和指标收集脚本之外，这台机器上没有运行其他任何东西。有人可以帮我找出为什么 OOM Killer 被调用以及如何防止它在将来被调用。有什么方法可以告诉 OOM 杀手不要杀死 mysql 服务器。我知道我们可以将oom_adj进程的值设置得非常小，以防止它被 OOM 杀手杀死。但有没有其他方法可以防止这种情况发生。
答案1
Linux 确实存在内存过量使用的情况。这意味着它允许进程请求比系统上实际可用的内存更多的内存。当程序尝试 malloc() 时，内核会说“好吧，您获得了内存”，但不保留它。仅当进程在该空间中写入内容时，才会保留内存。
要查看差异，有 2 个指标：虚拟内存和常驻内存。 Virtual是进程请求的内存，Resident是进程真正使用的内存。
使用这个系统，您可能会进入“超额预订”，内核授予的内存多于可用内存。然后，当你的系统出现0字节的空闲内存和Swap时，他必须牺牲（杀戮）获得空闲内存的过程。
这就是 OOM Killer 发挥作用的时候。 OOM 根据进程的内存消耗和许多其他因素来选择进程（父进程获得子进程分数的 1/2；如果是 root 拥有的进程，则分数除以 4，等等。看看Linux-MM.org/OOM_Killer
您可以通过调整文件来影响 OOM 评分/proc/MySQL_PID/oom_adj。通过将其设置为-17，您的进程将永远不会被终止。但在这样做之前， 你应该调整你的 MySQL 配置文件以限制MySQL内存使用。否则，OOM Killer 将杀死其他系统进程（如 SSH、crontab 等...），并且您的服务器将处于非常不稳定的状态，可能会导致数据损坏这比什么都糟糕。
另外，您可以考虑使用更多交换。
[编辑]
您还可以通过这两个 sysctls 更改其过度使用行为：
vm.overcommit_memory
vm.overcommit_ratio
如中所述内核文档
过度使用内存：
该值包含一个启用内存过量使用的标志。
当此标志为 0 时，内核尝试估计用户空间请求更多内存时剩余的可用内存量。
当此标志为 1 时，内核假装始终有足够的内存，直到实际耗尽为止。
当此标志为 2 时，内核使用“从不过度使用”策略来尝试防止任何内存过度使用。请注意，user_reserve_kbytes 会影响此策略。
此功能非常有用，因为有很多程序“以防万一”使用 malloc() 大量内存，但并不使用太多内存。
默认值为 0。
有关更多信息，请参阅 Documentation/vm/overcommit-accounting 和 security/commoncap.c::cap_vm_enough_memory() 。
过量使用比率：
当 overcommit_memory 设置为 2 时，提交的地址空间不允许超过 swap 加上物理 RAM 的此百分比。往上看。
[/编辑]