我的应用程序由多个进程组成。每个进程都有多个线程。
堆内存区域在操作过程中动态分配和释放。
我的应用程序中存在内存泄漏错误并修复了它。然后我在元旦假期进行了老化测试，证明这个bug已经被彻底修复了。
在老化测试期间，另一个监视进程定期读取应用程序进程的 /proc/PID/statm 并将这些值记录在文件中。
13天后，我分析了内存日志文件。
在最初的 10 个小时左右，驻留内存 (RES) 的大小不断增加。
这是预期的行为，因为 glibc 库内存分配器不会将“已释放的内存”返回给系统，而是将内存片段保留在“arena”中以供将来重用。
然后，驻留内存 (RES) 的大小达到了上限，并在 10 天内保持不变。
这意味着内存泄漏错误已得到修复。万岁！
（修复之前，它没有达到任何上限，并且不断增加。）
令我惊讶的是，11天（约270小时）后，常驻内存的大小开始以陡峭的角度（比增加期更陡）减少，然后触及“地板”并保持平坦，直到老化期结束。
大多数应用程序进程都显示相同的行为（其中一些没有）。
270 小时后，它们的常驻内存大小开始减少。
谁能描述一下这种下降的原因吗？
欢迎任何假设。
你可能会问“RES大小减小有什么问题吗？”。
减少本身是可以接受的，但它似乎会触发我的应用程序中关键进程和线程的计时减慢或暂时暂停。
“我真正想做的”是消除这种速度减慢或暂时暂停的原因，并保持进程及其线程没有任何延迟地运行。
环境信息：
操作系统：Rocky Linux 8.8 版（绿黑曜石） CPU：Intel(R) Core(TM) i7-9850HE CPU @ 2.70GHz 语言：C++17 gcc版本（dnf信息gcc）： 名称：海湾合作委员会 版本：8.5.0 发布：18.el8 架构：x86_64 尺寸 : 59 M 来源：gcc-8.5.0-18.el8.src.rpm glibc 版本（dnf 信息 glibc）： 名称：glibc 版本：2.28 版本：225.el8 架构：x86_64 尺寸：6.4M 来源：glibc-2.28-225.el8.src.rpm
我有两个假设：
1.
其他进程（不是应用程序进程）为它们分配了驻留内存，并且整个系统的总量达到了极限。
应用程序进程无法再保留已释放的常驻内存区域，并且它们开始将其“囤积的内存区域”返回给系统。
我在第13天检查了“top”命令的结果，但没有发现RES大小大幅增长的进程。
2.
Linux或glibc内存分配器有一种“管家”机制，用于自动修剪内存空间。
它定期工作并强制进程将其释放的内存返回给系统。
我也在网上查了资料，但查到的都是类似下面这样的，并不是我的“减少”的情况。
我通过调试了解了堆内存管理的基础知识（因此我了解了什么是“arena”），但我不知道它的细节。