服务器宕机处理方法，服务器宕机多久恢复
chanong
|很多用户会在文章中听到或者提到电脑宕机或者服务器宕机，但是很多用户并不理解宕机的含义。那么服务器宕机是什么意思呢？下面小e就分享一下电脑宕机的读音和含义。你怎么读“停工”？我想有很多人不知道“旦”字怎么读，也不知道它的意思。 “停机”的拼音发音是“dng ji”。服务器停机是什么意思？ 停机是一个计算机术语，表示计算机或服务器无法正常工作。在口语中，停止的机器简称为“down machine”，翻译成汉字就变成了“down machine”，但一般来说，它被称为“crash”或“crash”，虽然它不是标准化，很常见。我就是。
当服务器发生故障时，问题的原因很少是立即显而易见的。基本上从以下步骤开始：
1. 尝试尽可能多地了解问题的原因和影响。不要一下子跳到服务器前面。首先，您需要了解您对服务器以及具体故障情况的了解程度。否则，你可能瞄准了错误的目标。需要澄清以下几点：失败的症状是什么？没有反应？您想报告错误吗？何时发现故障？故障是否可重现？是否有规律的模式（例如每小时一次）？整个平台（代码、服务器等）的最后更新特定用户是什么受故障影响的组（登录、注销、特定区域等）？能否找到基础设施（物理、逻辑）的文档以及可用的监控平台（例如Munin）？是否可能（我可以使用Zabbix， Nagios、New Relic.等等）查看日志？（Loggly、Airbrake、Graylog.等）最后两个是最有用的信息来源，但请不要使用。不要期望太多。基本不能用。我们能做的就是不断探索。
2、谁在$w$last 12?用这两个命令可以查看谁在线，哪些用户访问过。尽管这不是关键步骤，但我们建议您不要在其他用户正在使用系统时调试系统。有句话说，一山难藏二虎。 （只要在厨房做饭就足够了。）
3. 检查服务器上之前运行的$history 1 命令。您可以随时查看。添加有关先前登录的人员的信息非常有用。此外，管理员必须小心，不要利用自己的权力侵犯他人的隐私。请注意，您稍后可能需要更新HISTTIMEFORMAT 环境变量才能查看这些命令的运行时间。否则，看到如此多的命令而您不知道何时运行它们可能会很疯狂。
4. 当前正在运行哪些进程？ $ pstree -a $ ps aux12 检查现有进程。 ps aux 的结果相对复杂，而pstree -a 的结果相对简单明了，可以让您看到正在运行的进程和关联的用户。
5. 要监视的网络服务$ netstat -ntlp $ netstat -nulp $ netstat -nxlp123 通常，您会单独运行这三个命令，但您不希望一次列出太多服务。您还可以使用Netstat -nalp。但我从不使用数字选项（依我看来，IP 地址更有用）。查找所有正在运行的服务并检查它们是否正在运行。显示每个监听端口。 netstat显示的服务列表中的PID与ps aux进程列表中的PID相同。当多个Java 或Erlang 进程同时在服务器上运行时，能够通过PID 单独查找每个进程非常重要。一般来说，我们建议在每台服务器上运行较少的服务，并根据需要添加更多服务器。如果您发现您的服务器上打开了30或40个监听端口，我们建议您记录下来并在以后有时间时进行清理并重新整理您的服务器。
6. CPU 和内存$ free -m $ uptime $ top $ htop1234 请注意以下问题： 是否有空闲内存？服务器是否在内存和硬盘之间交换？是否有剩余CPU？有多少个核心？有服务器有内存吗？有空闲内存吗？CPU核心超载。服务器的最大负载从何而来？平均负载是多少？
7. 硬件$ lspci $ dmidecode $ ethtool123 仍然有很多裸机服务器。找到RAID 卡（带或不带BBU 备用电池）、CPU 和可用内存插槽。根据这些情况，您可以大致了解是什么原因导致硬件问题以及如何提高性能。您的网卡配置是否正确？是否以半双工运行？速度是否为10MBps？是否有任何发送/接收错误？
8. IO 性能$ iostat -kx 2 $ vmstat 2 10 $ mpstat 2 10 $ dstat --top-io --top-bio1234 这些命令对于调试后端性能非常有用。检查磁盘使用情况：服务器硬盘是否已满？交换模式（si/so）是否开启？谁占用了CPU：系统进程、用户进程、虚拟机、dstat 是我最喜欢的。这使您可以看到谁在执行IO。是MySQL 还是PHP 进程消耗了所有系统资源？
9、挂载点和文件系统$ mount $ cat /etc/fstab $ vgs $ pvs $ lvs $ df -h $ lsof +D//* 注意不要杀掉盒子*/1234567 总共有多少个文件系统某个特定的服务（例如MySQL）没有专用的文件系统。什么是文件系统挂载选项： noatime 默认值。文件系统是否以只读模式重新挂载？是否还有剩余磁盘空间？是否有已删除但未清除的大文件？如果磁盘空间有问题，是否还有空间可以扩展分区？有吗？
$ sysctl -a | grep . $ cat /proc/interrupts $ cat /proc/net/ip_conntrack /* 在繁忙的服务器上可能需要很长时间*/$ netstat $ ss -s12345 中断请求在CPU 进程之间发送。分布均匀吗？或者某些CPU核心是否因大量网络中断请求或RAID请求而过载？SWAP交换的设置是什么？将swappinness 设置为60 对于工作站来说很好，但对于服务器来说就太糟糕了。最好不要让服务器执行SWAP 交换。否则，SWAP进程将被锁定对磁盘的读写。 conntrack_max 是否设置得足够大以处理服务器的流量？各种状态下的TCP 连接时间设置是多少（TIME_WAIT 等）？我想查看所有现有连接如果是这样，netstat 会很慢，所以可以先使用ss检查整个情况。您还可以阅读Linux TCP 调优来了解有关网络性能调优的要点。
10. 查看系统日志和内核消息$ dmesg $less /var/log/messages $less /var/log/secure $less /var/log/auth1234 错误和警告消息。例如，检查是否有太多连接。导致？检查硬件或文件系统错误并分析这些错误事件是否可以与之前发现的可疑事件进行比较。
11. 计划任务$ ls /etc/cron* + cat $ for user in $(cat /etc/passwd | Cut -f1 -d:); do crontab -l -u $user; did12 运行计划任务有任务吗？它们是否发生得太频繁？用户是否提交了隐藏的计划任务？发生故障时备份任务是否正在运行？
12.你的应用系统日志中有很多东西需要分析，但作为运维人员，你可能没有时间仔细考虑。留意典型LAMP（Linux+Apache+Mysql+Perl）应用环境中的： Apache Nginx等明显问题，查找访问和错误日志，直接查找5xx错误，检查是否有limit_zone错误即可。 MySQL；在mysql.log 中查找错误消息，查看是否存在结构损坏的表、innodb 修复进程是否正在运行，或者是否存在任何磁盘/索引/查询问题。直接查找错误信息（php、mysql、memcache，）。如果未设置，请立即设置。 Varnish；使用varnishlog 和varnishstat 检查命中/未命中率。配置中是否缺少任何允许最终用户直接攻击后端的规则？HA-Proxy；后端的状态如何？健康检查是否成功？前端或后端队列大小是否已达到最大值？
结论经过这五分钟，您应该对以下内容有更清晰的了解：服务器上正在运行什么？此故障似乎与IO/硬件/网络或系统配置（有问题的代码、系统内核调整等）有关。该故障是否有您熟悉的特征，例如数据库索引使用不当或Apache后台进程过多等。您甚至可以找到问题的真正原因。即使您还没有找到它，考虑到上述情况，您现在已经准备好深入挖掘了。继续努力吧！