我们使用 munin 和 monit 来跟踪我们的 vps 的一般统计数据，在过去的几周里，我们遇到了随机 IO 等待峰值的问题降低我们的服务器性能。
从那时起，我们一直在检查 cron 以寻找可能的可疑点，但尚未发现符合峰值模式的可疑点。准时到达以检查是否ps aux有过时的进程并不总是可行的，即使在事件期间，结果也可能有所不同。
所以我想知道是否有更好的方法来设置被动监控，最好通过 munin/monit，跟踪经历/导致 IO 等待最多的进程？
（PS：我已经使用了部分建议在此问答中，但还不能确定原因。）
答案1
您可能想要使用 Linux 进程记账。如果它包含在您的内核中（我不确定当前状态），您可以使用 启用它accton。该命令sa将报告每个进程的以下数据：
cpu - sum of system and user time in cpu seconds
re - "real time" in cpu seconds
k - cpu-time averaged core usage, in 1k units
avio - average number of I/O operations per execution
tio - total number of I/O operations
k*sec - cpu storage integral (kilo-core seconds)
u - user cpu time in cpu seconds
s - system time in cpu seconds
您可能对流程avio和价值感兴趣。tio
这GNU 会计实用程序手册以及在 Linux 上启用进程记帐的方法提供了更多细节。
答案2
可能没有过程导致这种情况的原因。更可能是 I/O 子系统或资源争用问题。我不会寻找导致这种情况的单个进程或进程组。我会注意它发生的条件。
您是否有服务器的完整规格，包括磁盘设置的详细信息？请将它们与操作系统版本/内核一起发布 -uname -a
编辑-
我猜这是 VPS。致电或发送电子邮件给您的提供商支持人员。向他们展示图表并解释您的情况。
答案3
您可能超出了 vps 限制：
即使您捕获了具有高 io 值的进程，它也可能是通用的 apache-php 或其他网站相关进程。但这还不够，您需要它背后的实际 url。当您找到 url 时，它不会是 io 问题的原因，而是它的受害者。大多数 cms 需要大约 1000 个文件才能运行，并且硬盘或缓存中的任何问题都会导致它们出现巨大的 io 峰值。io 的实际原因可能是其他 vps 帐户，或者您达到了 vps 限制。超出 vps 限制确实会导致 io 峰值及其所设的限制。
占用 VPS 的其他帐户或机器进程：
您可以考虑更换您的提供商！
我遇到过类似的问题，花了数周时间试图诊断，然后与聋哑支持机构进行交流，最后忍无可忍，换了另一台主机。现在一切突然都好了，而且已经好一年了！发生了什么？同样的 vps 大小，同样的代码，即使是速度较慢的机器，即使是更繁忙的网站，一切都很顺利。
我当时的猜测是，某个占用硬盘的其他帐户，每天都有大量论坛备份，通过 Google 发现了这个问题。我的另一个猜测是某个效率低下的服务器备份软件。不知道。与您的情况相似之处在于，它始于某个日期，并且周期性很强，我的 vps 代码或负载本身几乎没有变化。您无法使用仅限于 vps 墙的监控软件来捕捉或证明这一点。
那是一年前的事了。如今又出现了一些新的麻烦。
核心转储：这是现在的新潮流，核心转储而不是错误日志。服务器歇斯底里。当出现问题时，服务器开始核心转储一个 200M 文件，这会使 io 保持较高水平，因此其他事情会连锁出错，并且在一天中最繁忙的时间保存 3-5 个 200M 文件，导致硬盘停滞。
imagick图像处理器：由于某种原因，imagick 开始处理 1G-50G 的临时文件。如果发生这种情况，它会使硬盘停止运行。我怀疑 Imagick 被 munin 使用，真是讽刺。
另一个实用建议：在您处理其他事情时，请让 munin 在窗口中打开。它每 5 分钟自动刷新一次。这样您就可以捕捉到峰值。我以前就是这样捕捉 io 峰值的。您的峰值持续 30 分钟左右。您可以轻松捕捉到它。然后您可以执行 ps aux 等。