我正在努力分析数据库服务器应用程序中看起来像内部malloc内存碎片的内容。为了排除泄漏，所有malloc，realloc和free调用都包含在我们自己的会计中，该会计预先设置了我们自己的头文件以保持内存平衡，而且代码使用了相当大的测试套件。此外，大多数时候我们使用自定义分配器，直接mmaping内存池并进行自己的管理 glibs malloc仅用于一些不适合我们自己的分配器方案的小东西。
运行测试几天只是在服务器中分配和释放大量内存（许多短连接来来去去，许多DDL操作修改全局编录）导致“RES”内存逐渐增加并且熬夜，高于我们的内部会计。 在这几天的测试之后，我们计算了大约400TB的内存/被释放内存，我们的会计报告的余额大约在几百兆字节到2-3 GB之间（峰值高达15GB） 。然而，该过程的“RES”内存永远不会低于8.3-8.4GB。 解析/ proc / $ PID / maps，几乎全部都在“rw-p”映射中，正好是64MB（或“rw-p”加上“--- p”保留“尾部”） - 在捕获的快照中143这样的竞技场几乎完全适用于8.3-8.4 GB的常驻记忆。
谷歌搜索告诉malloc在这样的64MB竞技场中分配了内存，并且这样的多个竞技场会导致过多的“VIRT”内存：
然而，在我的情况下，大多数区域已满，实际上计入RES而不是VIRT（143个区域中只有9个区域的“--- p”尾部超过1 MB）。
在这种情况下，它只有几GB的内存，但在实际的生产系统中，我们已经看到了这种不足增长到40-50 GB的数字（在512 GB RAM服务器上）。
有没有办法让我更深入地了解这种碎片？ malloc_info输出似乎有些损坏，报告了一些奇怪的数字，如：
<unsorted from="321" to="847883883078550" total="140585643867701" count="847883883078876"/>
- 每个堆中都会重复这样的确切行（完全相同的“to”，“total”和“count”）。
我将以类似的方式测试不同分配器（jemalloc，tcmalloc）的行为。