Ubuntu 18.04 lsb，我正在尝试找出诊断 Amazon Ec2 实例（免费套餐）挂起时发生的情况的最佳方法。
正在运行实验性服务，可能存在内存泄漏。
为了提高生活质量，我使用了一个叫做航航帮助我浏览系统日志。我还安装了一个名为monitorix直观地看到正在发生的事情。
我能否/如何从系统日志中识别导致问题的特定进程？哪些日志可能对我有帮助？（/var/log/syslog 没有帮助）
这些图表显示，与系统交换空间消耗相关的高 CPU 负载直到发生灾难性故障。
但是这并没有告诉我具体的过程。我该如何通过终端做到这一点？
我可以配置其他一些流程监控吗？
任何帮助均感激不尽...
编辑：感谢@Rinzwind 的提示，sar现在已安装，cron 每 2 分钟运行一次...但它没有提供进程级别信息。因此，借助其他回答：
pidstat 5 > pidhist.log通过管道传输到文本文件，并在持久会话中运行它将有助于在事件再次发生时进行诊断。
@heynnema 建议iotop
运行iotop -P -a文件topI/O 的累加器。它表明实验进程（单声道服务）是使用 SWAPIN 消耗交换空间最多的进程
****
更明显的是top
我们可以看到可以看到相同的消耗模式，然后在重新启动进程后从 monitorix 恢复正常~20％。
在这些随机事件之间，系统连续数周保持稳定。证据iotop证明根本问题出在实验过程中！
然而，这仍然是一个运行时诊断。有没有办法根据现有日志确定事后哪个进程出现了问题？在没有预先监控和日志记录的情况下做到这一点。
找出问题所在才是亟待解决的关键问题。如果没有启用日志记录，我们怎样才能做到这一点而不等待它重新发生？内核日志???
谢谢你的帮助。
答案1
来自评论...
free -h我们查看了和sysctl vm.swappiness以及的输出cat /etc/fstab，并安装iotop以确定为什么 swap 使用如此频繁。
该系统存在以下几个原因鞭笞。
你没有足够的 RAM
你没有足够的交换空间
vm.swappiness 被错误修改
修复...
添加更多 RAM
增加/swapfile 空间
将 vm.swappiness 设置为 60-90 (默认值为 60)
答案2
我们不会添加 RAM 来解决这个问题。
识别导致内存泄漏的进程与系统配置无关。
iotop -P -a帮助识别事件再次发生时消耗交换空间的进程。
数字取证日志调查的步骤将是一个更好的解决方案。