Elastic Beanstalk运行一周后CPU负载很高

我正在AWS Beanstalk上运行单实例工作器。这是一个单容器的Docker，每个工作日运行一次。大多数情况下，这些进程同步S3中的大量小文件并分析这些文件。

该设置运行良好大约一个星期，然后CPU负载开始时间线性增长，如在此屏幕截图。

AWS Elastic Beanstalk CPU负载图表

CPU负载保持在相当的水平，放慢我的预定进程。同时，我在容器内运行的顶级资源跟踪（特权的 Docker模式启用它）：

echo "%CPU %MEM ARGS $(date)" && ps -e -o pcpu,pmem,args --sort=pcpu | cut -d" " -f1-5 | tail

几乎没有CPU负载（仅在我的日常过程运行的时间内发生变化，看起来准确地反映了那些时间的系统负载）。

这个“背景”系统负载的来源是什么？想知道是否有人看到一些类似的行为，并且/或者可以从正在运行的容器内部build议额外的诊断。

到目前为止，我一直在重新启动设置每周删除“背景”的负载，但这是次优，因为每次重新启动后第一次运行必须从S3收集超过100万的小文件（而随后的每日运行只添加每天几千个文件）。

简介有点奇怪。特别是它是一个线性增长。几乎就像积累了一些东西，并逐渐花费更长的时间来处理。我没有足够的信息来指出具体的问题。有几件事你可以检查：

你是否在任何地方收集文件，无论是有意或caching或传输文件夹？这可能是系统正在运行后台进程（AV，索引，碎片整理，重复数据删除等），“大量的小文件”正在积累，成为需要分页或处理效率低下的事情。
您的stream程的任何部分是否使用每周的命名约定或内务过程。你可能会遇到冲突，或积累工作负荷，因为这一周过去了。即第二周实际上是处理第一周和第二周的数据，但从来没有完成，所以第二天就越来越差。我看到了一个类似的地方，一个不恰当的冒泡sorting过程没有完成（由于缓慢但稳定的数据stream入导致它不断复位，所以从未达到完成状态），随着arrays变大，过程的需求也逐渐增加。
你有每周翻转周期的日志吗？
这个趋势是否还有其他关键性能指标？（networking，磁盘IO，内存，分页等）
请考虑是否是误报。如果是高CPU，则应该有其他度量CPU镜像，caching使用，磁盘IO，S3传输统计/日志logging的度量。