当一个未受影响的 unix 服务器开始变得狂暴时，你首先要检查什么？

Question

所以你有这个整齐设置的 unix 服务器，它超级快，运行良好，几个月来一切都很好，突然间，各种奇怪的错误开始出现在各种不同的服务上，而且它们本身都没有多大意义，少在一起。

将 ssh 会话连接到机器后，应该立即检查哪些便宜的东西？

我对突出不明显命令和罕见情况的创伤故事特别感兴趣，但我想明显的因人而异，所以我们可以随意列出它们。

Answer 1

第一秩序：它有反应吗？

如果您无法登录，则会出现更大的问题。这通常有两种情况：硬件故障和软件故障。两者都有潜在的灾难性。为防止 DFA 错误，请先检查一般硬件健康状况 - 通常简单地浏览一下就足够了。

二阶：系统的底层结构是否健康有序？

检查系统的“黄金三角”：

• 足够的 CPU 时间可用于处理
• 足够的磁盘空间可用于存储
• 足够的内存可用于工作负载

在过去的几十年中，三合会扩展为“四合一”，其中包括通信（网络）：

• 连通性是功能性的、反应灵敏的并且具有容量

三阶：问题的严重程度如何？

哪些程序或服务受到影响？按照严重程度递减的顺序，它是系统的（系统范围的）、集群的（一组程序）还是孤立的（特定程序）？程序集群通常会因为特定的底层服务失败或无响应而失败。系统性问题有时与此相关（想想 DNS 或 IP 冲突），但知道在哪里查找通常是关键。

四阶：诊断工具是否提供了与问题相关的有用数据？ 既然您已获得有关系统运行状况（二阶）以及系统的哪些部分遇到问题（三阶）的信息，这应该可以轻松缩小问题所在的范围。

错误消息或日志文件应该是此过程中的常见路径。

CPU问题：

• 负载
• 最佳
• 斯特拉斯

磁盘空间/IO 问题：

• df
• 杜
• lsof
• iostat
• 虚拟机

内存问题：

• 自由

连接问题：

• 平
• 路线（以及 arp 和 rarp 和朋友）
• iptables、ipchains、ipfw（针对那些 BSD 人员）
• traceroute 或 mtr
• 主机、nslookup 或 dig
• 网络统计

最常见的抱怨（我听到的）：

电子邮件发送速度不够快（从发送到收件人收到超过一分钟），或者电子邮件拒绝了我的发送尝试。这通常归结为 Postfix 中的速率限制器在垃圾邮件风暴期间启动，这会影响接受内部交付的能力。

一个真实的例子：

然而，这并非总是如此。有一次，无论服务重启，问题仍然存在；所以3分钟后是时候开始环顾四周了。CPU 很忙，但低于 100%，但在一个只有 2 个内核的盒子上，负载已经飙升到 15，并且有可能会更高。top 命令显示邮件系统和邮件扫描程序都处于超速状态，但没有看到 amavis 子进程。这就是线索——邮件队列命令 (mailq) 显示了大约 150 多封未送达的邮件，其中超过 80% 是垃圾邮件，在最后 20 分钟内。快速调整以降低速率限制器（降低垃圾邮件风暴的摄入率），同时增加子电子邮件扫描程序进程的数量（以帮助处理积压），然后重新启动服务，解决了问题，系统能够以在短时间内完成交付。

问题的原因是 amavis 父进程已经死了，而子进程最终都运行了它们的进程（它们在经过如此多的扫描后自行终止以防止内存泄漏）。因此，postfix 中有 SMTP 进程试图联系...稀薄的空气...进行所需的垃圾邮件/病毒扫描。我使用的发行版有永远不会更新的过时软件包；由于安装将在一年左右的时间内更换，我手动将安装“覆盖”到最新版本，其中包括几个错误修复。从那以后我就没有遇到过同样的问题。

Answer 2

通常“谁”后跟“最后一个”

我多次管理的机器上的一堆问题是因为对“未触及”的定义非常松散 - 通常有人做了一些事情:)