一旦你的ssh会话进入机器,你应该检查哪些便宜的东西？
我特别感兴趣的是创伤故事,突出非显而易见的命令和罕见的情况,但我想明显的是因人而异,所以我们可以自由地列出它们.
如果您无法登录,则会出现更大的问题.这通常有两种形式：硬件故障和软件故障.两者都可能是灾难性的.要防止DFA错误,请首先检查一般硬件健康状况 – 通常只需简单的一瞥即可.
二阶：系统的基础结构是否健康有序？
检查系统的“黄金三联”：
>足够的cpu时间可供处理
>足够的磁盘空间可供存储
>工作负载可以免费获得足够的内存
在过去的几十年里,三合会已经扩展到一个“四边形”,其中包括通信(网络)：
>连接功能,响应能力和容量
第三顺序：问题的严重性是什么？
哪些计划或服务受到影响？按严重程度递减顺序,是系统性(系统范围),聚类(一组程序)还是孤立(特定程序)？程序集群通常会绊倒,因为特定的底层服务已经失败或没有响应.系统性问题有时与此相关(想想DNS或IP冲突),但知道在哪里寻找通常是关键.
第四顺序：诊断工具是否提供与该问题相关的有用数据？
现在您已经了解了系统的健康状况(第二顺序)以及它遇到问题的部分(第三顺序),这样可以轻松缩小问题所在.
cpu问题：
> loadav
>顶部
> strace
磁盘空间/ I-O问题：
> df
>杜
> lsof
> iostat
> vmstat
内存问题：
>免费
连接问题：
> ping
>路线(和arp和rarp以及朋友)
> iptables,ipchains,ipfw(对于那些BSD人员)
> traceroute或mtr
> hosts,nslookup或dig
> netstat
最常见的抱怨(我听到)：
电子邮件的传送速度不够快(从发送到收件人的收据超过一分钟),或者电子邮件拒绝我的发送尝试.这通常归结为Postfix在垃圾邮件风暴期间的速率限制,这会影响接受内部传递的能力.
一个真实的例子：
然而,这并非总是如此.有一次,无论服务重启如何,问题仍然存在;所以在3分钟后,是时候开始环顾四周了. cpu很忙,但是在100％以下,然而在一个只有2个核心的盒子上,负载已经飙升至15,并且威胁要更高. top命令显示邮件系统与邮件扫描程序一起处于超速状态,但没有看到amavis子进程.这就是线索 – 邮件队列命令(mailq)在过去20分钟内显示了大约150封未传送的邮件,其中80％以上是垃圾邮件.快速调整以降低速率限制器(降低垃圾邮件风暴的摄入率),同时增加子电子邮件扫描程序进程的数量(以帮助处理积压),然后重新启动服务,解决了问题,系统能够在短时间内完成交付.
问题的原因是amavis父进程已经过时了,并且子进程最终都已经完成了它们的运行(它们在经过如此多次扫描后自行终止以防止内存泄漏).因此,postfix中的SMTP进程试图联系……稀薄的空气……进行所需的垃圾邮件/病毒扫描.我使用的发行版有过时的软件包,永远不会更新;由于安装将在一年左右的时间内被更换,我手动将“安装”更新到最新版本,其中包括几个错误修复.从那以后我没有遇到过同样的问题.
