有时似乎无法与该服务器建立连接。后来当可以建立连接时，我看不到导致此行为的任何提示。当我已连接到服务器时，有时我无法执行任何操作，因为它不会做出反应（有时连接会在一段时间后丢失，有时可以保持连接）。似乎与根本无法建立连接的情况相同。
对于连接 ssh，错误消息是：
ssh: connect to host myhost port 22: Connection timed out
根据 CPU/内存情况，服务器在任何时候都不应该太忙。我已经使用 MemTest86+ 检查了内存，没有任何错误。
dmesg 没有列出与此相关的其他消息。
有人知道我应该检查/查找什么吗？
亲切的问候
答案1
我们在高负载条件下或更令人惊讶的是大文件写入条件下都看到了这种行为。您已经排除了高负载。让我解释一下第二种情况。
这是一个真实的场景，就发生在几天前：
假设有大量 RAM，相对于磁盘写入速度（32 GB RAM，100 MB/秒）
一个应用程序导致大约 20 GB 的快速写入，其中数据来自缓存源或生成，这样写入被缓冲到 20 GB 的 RAM 中并在后台写入。
在这 20 GB 写入结束时执行“fsync”。应用程序会阻塞并等待 200 秒以完成写入。
现在到了棘手的部分：
在这 200 秒的 fsync 写入期间，您尝试登录 SSH 甚至（虚拟）控制台。
登录过程尝试同步有关您的登录的日志条目。
本次 fsync 被上一次 fsync 所阻止，最多需要等待 200 秒才能完成。
登录过程超时，您会看到以下消息。
整个时间机器都是可 ping 的。另外，不发出“fsync”的东西通常工作正常。
请注意，这发生在我们的 CentOS 5 服务器上，我读到 Theodore (Ted) Ts'o 对新内核进行了改进，以更好地管理不相关的并发 fsync。