我最近遇到了一个非常奇怪的问题，可能是由于内核内存分配器造成的。起初，我怀疑我的 C++ 代码中存在某种类型的内存错误，但我看到的确切行为让我相信这可能不是由于代码中的错误造成的。这很奇怪，但这是我对这个问题的最佳描述。
我有一个应用程序可以写入和覆盖我机器的 /dev/shm 区域中的文件。在程序开始时，它为要写入的所有文件声明文件指针，并不断覆盖。这些指针都是在程序开始时创建的。
当我运行代码时，我注意到以下内容。第一次内存使用量上升到我系统总数的 4.3%（从顶部看）。当我启动可执行文件时，就会发生这种情况。然后，在代码开始执行任何操作之前，CPU 使用率徘徊在 40-50% 左右。大约 2-3 分钟后，内存使用率达到 5.0%，并且没有进一步增加。发生这种情况时，CPU 使用率下降到 5-15%，这是程序通常运行的范围（由于数据传递给它的速率）。
在我的程序启动内存期间，幕后发生了一些事情，但我不明白它是什么，感觉在现代 x86_64 上分配 5% 的系统内存（1.2GB）不应该花费 2-3 分钟服务器。请注意，在这个奇怪的启动之后，程序通常运行没有问题。
但是，今天，我不得不增加程序在 /dev/shm 中写入的文件数量，并相应地增加指针数量。问题就在这里，在启动过程中，CPU 使用率突然跳到 100% 并停留在那里。这是一个巨大的问题，因为它导致我的应用程序大幅减速，低于可接受的水平。这个和工作可执行文件之间的唯一区别是我让它写入的文件数量。具体来说，我将文件数从 1345 增加到 1350。事实上，仅 1346 多一个就足以解决这个 100% cpu 问题。
我真的对我在这里处理的事情感到茫然。我怀疑可能与 SLAB/SLUB 分配器有关（我的系统是带有 2.6.35 内核的 Centos 5.8）。任何有关如何解决此问题的想法或提示将不胜感激。