首先介绍一些环境细节：
硬件：
英特尔服务器主板 S2600GZ
2 个英特尔至强 CPU E5-2620
64GB DDR3 RAM
英特尔 RAID 控制器 RS2BL (LSI SAS2108)，带 4TB LVM 卷（由 SAS 磁盘组成）
软件：
Ubuntu 12.04.4 LTS / Linux 3.11.0-24-generic x86_64（包含最新更新）
qemu/KVM（libvirt）带有 6 个 VM（尽管情况如此，但仍能正常运行）
glusterfs 服务器 3.4.5（似乎也能正常工作）
一些其他轻量级软件（例如 bind9、keepalived、openvpn 等）
不定制/实验/自主研发的软件！
我们已经有一个很奇怪我们的一台 Ubuntu 服务器存在问题：它会定期向系统日志中发送“分配失败”消息，如下所示：
Aug 28 07:00:18 srvname kernel: [4210234.157335] irqbalance: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:19 srvname kernel: [4210234.711173] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:20 srvname kernel: [4210235.938599] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:34 srvname kernel: [4210250.307283] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:00:51 srvname kernel: [4210267.170359] irqbalance: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:01:02 srvname kernel: [4210278.625530] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
Aug 28 07:01:19 srvname kernel: [4210295.671569] zabbix_agentd: page allocation failure: order:4, mode:0x1040d0
这些消息大约每 30 秒记录一次，它们确实反映了真实情况：此日志片段中显示的进程确实失败了（例如 zabbix 代理无法将数据传输到 zabbix 服务器）。但这只是冰山一角。虽然内存耗尽正在发生任何过程需要读取/proc目录（例如，ps等）的程序在启动后立即崩溃，因为它无法读取目录（也无法用手动列出），并且此事件立即以相同的顺序 4 分配失败错误记录到系统日志中。topmpstat/procls
有了这些，就有足够的可用 RAM（总大小的 1/4），但如果我们按块检查 - 4 阶块确实已经耗尽。但，我真正不明白的是为什么这些进程实际上确实请求了如此大的块？我们有另一台几乎完全相同（硬件和软件）的服务器 - 它的 4 阶块也用完了 - 感觉很好，没有 4 阶分配失败！此外，这台相同的服务器处于很多更重的负荷。
我多次在网上深入搜索“（高阶）分配失败”的症状，但似乎没有任何相关内容。我们尝试使用各种 sysctl 参数（例如vm.min_free_kbytes，vm.vfs_cache_pressure等等，如一些文章所建议的那样），但没有任何帮助。最终，我们回滚了所有这些更改，现在大多数 sysctl 设置都是系统默认设置。我们也尝试过，echo没有/proc/sys/vm/compact_memory任何/proc/sys/vm/drop_caches明显（或长期）的效果。经过一段长时间的疲惫之后，突然间，一切都恢复正常（似乎内存被碎片整理，并且第 4 阶块/proc也变得可用），但不会持续很长时间 - 经过一段短暂的时间后，一切都会重新开始。重新启动有助于延长一段时间（由于内存完全没有碎片），但最终一切都会恢复原样......
总的来说，唯一真正的麻烦（我们意识到的所述行为导致的问题是无法监控和管理服务器资源，无论是远程（zabbix）还是本地（ps、top等mpstat）。
据我了解，缺少 4 阶区块是正常常规状态Linux 下的内存。进程通常不应该请求这样的块（尤其是进程不在其他服务器上执行此操作）。如果有人知道这种行为可能的原因是什么，我们可以检查什么或在哪里挖掘 - 我们将不胜感激！我们已准备好根据需求提供任何其他信息。
答案1
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1319244这表明这是一个内核错误，而且 Trusty 的修复程序最近才发布。不过抱歉我现在无法解决这个问题（它也影响到我，行为完全一样）。
答案2
你确定这不是硬件问题吗？如果我是你，我会怀疑是 RAM。尝试运行 memtest 或类似程序。