我有一个 Godaddy 服务器，它定期变得无响应。很难排除故障，因为当它无响应时我无法 ssh 进入。我通过添加一个 cron 作业来弄清楚发生了什么，该作业每 5 分钟将输出从“top”传送到日志文件。下次我在它无响应后重新启动它时，我检查了这些日志，发现 ram 已用完，但交换大部分未使用。
我正在努力减少那台机器上两个应用程序服务器的 ram 使用量（事实证明打开的连接太多了。每个连接都用了 30m，所以在打开 40 之后，服务器用完了 ram），但是我' d 真的很想知道如何确保我可以 ssh 进入机器。
如果交换文件未满，那么我认为服务器会有足够的空间来响应，即使它响应很慢。有什么办法可以保留一点内存，以便我始终可以通过 ssh 进入机器？
以下是服务器正常运行时的外观示例：
top - 15:13:21 up 3:12, 2 users, load average: 0.15, 0.30, 0.33
Tasks: 127 total, 1 running, 126 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.4%us, 1.8%sy, 0.0%ni, 95.7%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 2064980k total, 1611252k used, 453728k free, 45852k buffers
Swap: 2096472k total, 0k used, 2096472k free, 790212k cached
这是在服务器停止运行之前记录的最后一个顶级日志：
top - 14:45:08 up 15:20, 0 users, load average: 0.27, 0.16, 0.10
Tasks: 141 total, 2 running, 139 sleeping, 0 stopped, 0 zombie
Cpu(s): 2.7%us, 1.9%sy, 0.0%ni, 95.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 2064980k total, 2007652k used, 57328k free, 60496k buffers
Swap: 2096472k total, 100k used, 2096372k free, 689584k cached
请注意，当服务器用完 ram 时，记录“top”输出的 cron 作业也会停止运行，因此整个服务器显然会停止运行。
我以前也遇到过类似的问题，追踪这些问题可能会很麻烦。由于您提供了很多信息，我必须阐明一些需要检查的内容以及我的问题是什么。
首先，检查您的日志。在这种情况下，最值得注意的是 dmesg 的输出（这是内核环形缓冲区，它转储日志数据）。这会定期刷新到 /var/log 中的文件中，但具体位置取决于您的操作系统。例如，Red Hat 有一个 /var/log/dmesg 文件。您正在寻找任何看起来不寻常的东西，尤其是与OOM 杀手进程相关的东西。当 RAM 开始变满时，这会结束程序，以保持服务器正常运行并做出响应。sshd 应该不受此限制，但这是特定于发行版的设置方式。指定 OOM 豁免的现代形式是给 sshd 一个分数，告诉内核它对整个服务器的重要性（如果发生严重的 RAM 情况，这应该将其放在要终止的进程列表中很靠后的位置）。您的发行版应该已正确设置此项。
另一件需要检查的事情是您的服务器是否有足够的熵，如下所示：
cat /proc/sys/kernel/random/entropy_avail
正常值大约在 1000-1500 以上。下面，您的电量即将耗尽。在我的机器上，它实际上只上升到大约 4000-5000（这些基于我对服务器的观察）。
我在登录服务器时遇到了问题，这些服务器的熵非常低（并且生成速度很慢），以至于应用程序会挂起，等待更多的熵可用。有一个臭名昭著的 Debian Exim bug 凸显了这一点。Exim 在 Debian 上使用 GNU TLS，仅使用 /dev/random 并为每个连接使用大量熵。看这里。当熵耗尽时，Exim 就会挂起。它还会导致其他依赖熵的程序也开始拒绝连接。
由于每次会话都会生成会话密钥，因此 sshd 需要良好的随机数来源。虽然如果 /dev/random 阻塞，它应该使用 /dev/urandom 来收集伪随机数，但我不确定 sshd 是否会这样做。
这个问题在虚拟系统上可能非常严重，因为许多随机数源没有传递到虚拟机。熵的主要来源是磁盘 I/O，但这通常不会传递到虚拟机中。可能嵌入物理机芯片组/CPU 中的硬件随机数生成器也不太可能传递到虚拟机中。
这是一篇关于这个问题的很好的文章。
我rngd在服务器后台运行，向 /dev/random 提供来自 /dev/urandom 的数据：
rngd -r /dev/urandom -o /dev/random
这不是一个很好的解决方案，但却是一个有用的技巧，可以在您寻找更好的随机数源时将事物保持在一起。我正在考虑使用rngd来自不同来源的数据，但还没有太多机会这样做。