内存使用率达到 72% 时溢出

内存使用率达到 72% 时溢出

我的 48gb 内存服务器目前存在一个问题:它会因为内存不足而随机终止进程,即使它只使用了 72%(我从我的监控界面获得了这个数字)。(交换使用率:60%)

我进行了一些调查,但确实找不到问题所在。

我目前正在尝试“读取”系统日志以查看我的内存使用率是否确实为 72%,但找不到相关信息。另外,你们有没有发现任何可以帮助我进行调查的东西?

系统日志:http://pastebin.com/4DczHYqF

谢谢

谢谢

答案1

您的问题的答案是您使用的内存超过 72%。您可以通过 OOM 报告计算出来。

告诉您内存状态的是这个位:

Aug 11 04:20:14 myserver kernel: Node 0 DMA free:15884kB min:8kB low:8kB high:12kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:15884kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Aug 11 04:20:14 myserver kernel: lowmem_reserve[]: 0 3539 48337 48337
Aug 11 04:20:14 myserver kernel: Node 0 DMA32 free:181176kB min:2060kB low:2572kB high:3088kB active_anon:1334312kB inactive_anon:445152kB active_file:221600kB inactive_file:1327176kB unevictable:0kB isolated(anon):0kB isolated(file):384kB present:3644928kB managed:3624548kB mlocked:0kB dirty:1328084kB writeback:0kB mapped:220kB shmem:7852kB slab_reclaimable:75340kB slab_unreclaimable:34920kB kernel_stack:48kB pagetables:4684kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:2463022 all_unreclaimable? yes
Aug 11 04:20:14 myserver kernel: lowmem_reserve[]: 0 0 44797 44797
Aug 11 04:20:14 myserver kernel: Node 0 Normal free:25892kB min:26072kB low:32588kB high:39108kB active_anon:31943548kB inactive_anon:1879196kB active_file:5038872kB inactive_file:5769308kB unevictable:0kB isolated(anon):0kB isolated(file):4224kB present:46661632kB managed:45873100kB mlocked:0kB dirty:6184880kB writeback:324kB mapped:41268kB shmem:1577696kB slab_reclaimable:442212kB slab_unreclaimable:314476kB kernel_stack:3296kB pagetables:92756kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:17216562 all_unreclaimable? yes

在Linux中,内存被分成区域它们是分配的物理 RAM 区域(通常按地址范围),用于特定目的。

DMA适用于只能在 DMA 中寻址一小块区域的非常老旧的硬件。此区域不会积累太多内存,并且很少使用(如果有的话)。 DMA32是为只能寻址 32 位内存的硬件保留的区域。这在 64 位系统中用于该特定类别的硬件。通常覆盖约 4G 内存(但可能更少)。

然而,绝大多数内存被分配给“正常”区域。几乎所有内存都进出这里。当没有针对所分配内存的特殊用途标记时,就会使用它。当此区域中的内存变得难以找到时,内核通常会开始使用其他区域中的内存来查找它(尽管我相信DMA从未被触及)。

根据您的日志,可以进行以下计算。

 DMA Present + DMA32 Present + Normal Present = Total available memory
 15968kB     + 3644928kB     + 46661632kB     = 50322528kB
-
 DMA Free    + DMA32 Free    + Normal Free    = Total free memory
 15884kB     + 181176kB      + 25892kB        = 222952kB
=
 Total available memory - Total free memory = Total Used Memory
 50322528kB             - 222952kB          = 50099576kB
=
 (Total used memory / Total available memory) * 100 = Total used percent
 50099576kB         / 50322528kB              * 100 = 99.55%

其他区域实际上可以释放内存,但您仍然会遇到 OOM,因为您不是免费的。

min当值大于该值时,OOM killer 是一种释放内存的可能方法free。如果您检查您的Normal区域,您会发现这里的情况就是这样。

最大的内存消耗者是mysqljava。要么重新调整它们以改变它们的内存使用情况,要么为它们获取更多内存。

答案2

它可能不是总内存,而是通过命令定义的允许某个用户的内存ulimit

相关内容