c++ - 缓慢的 SLAB/SLUB 内存分配

Question

我最近遇到一个很奇怪的问题，可能是内核内存分配器引起的。起初，我怀疑我的 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 分配器可能有问题(我的系统是 Centos 5.8 和 2.6.35 内核)。非常感谢任何有关如何解决此问题的想法或提示。

Answer 1

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

您需要了解您的程序在占用 CPU 时正在做什么。您可以从 strace 开始，它至少会告诉您您的程序是否在内核或代码中花费了大量时间。从那里你应该学会使用 perf。