缓慢的SLAB / SLUB内存分配

Question

我最近遇到了一个非常奇怪的问题，可能是由于内核内存分配器造成的。 起初，我怀疑我的C ++代码中存在某种类型的内存错误，但我看到的确切行为让我相信它可能不是由于代码中的错误引起的。 这很奇怪，但这是我对问题的最佳描述。

我有一个应用程序写入和覆盖我的机器的/ dev / shm区域中的文件。 在程序开始时，它为它要写入的所有文件声明文件指针并连续覆盖。 这些指针都是在程序开始时创建的。

当我运行代码时，我注意到以下内容。 第一次内存使用率上升到我系统总数的4.3％（查看顶部）。 当我启动可执行文件时会发生这种情况。 然后，在代码开始执行任何操作之前，CPU使用率会徘徊在40-50％左右。 大约2-3分钟后，内存使用量将达到5.0％，并且没有进一步增加。 在发生这种情况时，CPU使用率降至5-15％，这是程序通常运行的范围（由于数据传递给它的速率）。

在我的程序启动期间，在内存中发生了一些事情，但我无法理解它是什么，感觉它不应该花2-3分钟在现代x86_64上分配5％的系统内存（1.2GB）服务器。 请注意，在这个奇怪的启动之后，程序通常运行没有问题。

但是，今天，我不得不增加程序在/ dev / shm中写入的文件数量，并相应地增加指针数量。 这就是问题所在，在启动过程中，CPU使用率突然上升到100％并保持不变。 这是一个很大的问题，因为它导致我的应用程序大幅减速，低于可接受的水平。 它和工作可执行文件之间的唯一区别是我写的文件数。 为了详细说明，我将文件数量从1345增加到1350.实际上，只有超过1346的文件足以启动这个100％的cpu问题。

对于我在这里处理的事情，我真的很茫然。 我怀疑可能是SLAB / SLUB分配器（我的系统是带有2.6.35内核的Centos 5.8）。 任何关于如何解决这个问题的想法或提示都将非常感激。

Answer 1

我认为这不太可能是SLUB的问题。 /dev/shm是通过tmpfs （在现代系统上）实现的，它使用页面缓存而不是SLUB。

你需要弄清楚你的程序在咀嚼CPU时正在做什么。 您可以从strace开始，至少会告诉您程序是在内核中还是在代码中花费了大量时间。 从那里你应该学习使用perf 。