运行一周后 Elastic Beanstalk 高 CPU 负载

Posted 2023-03-04

【中文标题】运行一周后 Elastic Beanstalk 高 CPU 负载

【英文标题】：Elastic Beanstalk high CPU load after a week of running

【发布时间】：2017-07-15 16:16:42

【问题描述】：

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

设置运行正常大约一周，然后 CPU 负载开始随时间线性增长，如此屏幕截图所示。

CPU 负载保持在相当高的水平，减慢了我的计划进程。同时，我的top-resource tracking在容器内运行（privilegedDocker模式开启）：

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

显示几乎没有 CPU 负载（仅在我的日常进程运行期间发生变化，似乎准确地反映了当时的系统负载）。

就这个“后台”系统负载的来源而言，我在这里遗漏了什么？想知道是否有人看到了一些类似的行为，和/或可以建议从正在运行的容器内进行其他诊断。

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

【参考方案1】：

个人资料有点奇怪。特别是它是线性增长。几乎就像一些东西正在积累并且需要越来越长的时间来处理。 我没有足够的信息来指出一个特定的问题。您可以检查的几件事：

您是否在任何地方收集文件，无论是有意还是在缓存或传输文件夹中？可能是系统正在运行后台进程（AV、索引、碎片整理、重复数据删除等），并且“大量小文件”正在积累成为需要分页或低效处理的东西。

李>

您的流程的任何部分是否使用每周命名约定或内部管理流程。随着一周的过去，您可能会遇到冲突或工作量增加。即第 2 周实际上正在处理第 1 周和第 2 周的数据，但从未完成，因此第二天情况会变得更糟。我看到了类似的情况，其中不适当的冒泡排序过程没有完成（由于数据缓慢但稳定的流入导致它不断重置，从未达到完成条件）并且随着数组变大，过程的需求逐渐增加。

您是否有一些关于每周滚动周期的日志记录？

是否有任何其他关键性能指标符合趋势？ （网络、磁盘IO、内存、分页等）

请考虑是否为误报。如果是高 CPU，则应该有其他指标反映 CPU 行为、缓存使用、磁盘 IO、S3 传输统计/日志记录。

强化学习

【讨论】：

奇怪的是，我不运行任何每周进程，并且网络输入/输出在 CPU 负载增长时保持接近于零。从 S3 同步的文件保留在 docker 主机实例的 SSD 驱动器上。我可以在 shell 脚本中运行其他一些命令来诊断 CPU 负载的来源吗？不知何故，需要确定一个占用系统资源的进程......

我会和一些 NIX 的朋友谈谈，下班后给你回复。强化学习

最好的建议是“***”，并获得更复杂的监控工具的试用许可证。顶是好的，但我不确定你会得到太多。强化学习

我的理解是，top 基本上会提供same info as ps。问题是“后台”CPU 负载没有反映在系统使用命令输出中。感谢@Polymath 总结了各种可能性，我将探索其他反映 CPU 模式的指标。