我最近遇到了一个非常奇怪的问题，可能是由于内核内存分配器造成的。起初，我怀疑我的C ++代码中存在某种类型的内存错误，但我看到的确切行为让我相信它可能不是由于代码中的错误引起的。这很奇怪，但这是我对这个问题的最佳描述。
我有一个应用程序，可以在我的机器的/ dev / shm区域中写入和覆盖文件。 在程序开始时，它为它要写入的所有文件声明文件指针并连续覆盖。这些指针都是在程序开始时创建的。
当我运行代码时，我注意到以下内容。第一次内存使用率上升到我系统总数的4.3％（查看顶部）。当我启动可执行文件时会发生这种情况。然后，在代码开始执行任何操作之前，CPU使用率会徘徊在40-50％左右。大约2-3分钟后，内存使用量将达到5.0％，并且没有进一步增加。当发生这种情况时，CPU使用率降至5-15％，这是程序通常运行的范围（由于数据传递给它的速率）。
在我的程序启动期间，在内存中发生了一些事情，但我无法理解它是什么，感觉它不应该花2-3分钟来分配5％的系统内存（1.2GB）一个现代的x86_64服务器。请注意，在这个奇怪的启动之后，程序通常会毫无问题地运行。
但是，今天，我不得不在/ dev / shm中增加程序写入的文件数量，并相应地增加指针数量。这就是问题所在，在启动过程中，CPU使用率突然上升到100％并保持不变。这是一个很大的问题，因为它导致我的应用程序大幅减速，低于可接受的水平。它和工作可执行文件之间的唯一区别是我写的文件数。为了详细说明，我将文件数量从1345增加到1350.事实上，只有超过1346的文件足以启动这个100％的cpu问题。
对于我在这里处理的事情，我真的很茫然。我怀疑可能是SLAB / SLUB分配器（我的系统是带有2.6.35内核的Centos 5.8）。任何关于如何解决这个问题的想法或提示都将非常感激。
答案 0 :(得分：2)
我认为这不太可能是SLUB的问题。 /dev/shm是通过tmpfs（在现代系统上）实现的，它使用页面缓存，而不是SLUB。
你需要弄清楚程序在咀嚼CPU时正在做什么。您可以从strace开始，这至少会告诉您程序是在内核中还是在代码中花费了大量时间。从那里你应该学会使用perf。