工作散记 二
1、记一次因inode耗尽，而引发的灾难性事故
事件描述：
星期六早上10点，接到DNSPod的告警：nginx.xxx.com无法访问。
赶紧上前端web服务器查看，发现服务器5分钟负载为400多（超高）。
因为这是前端web服务器，现在负载这么高，导致所有的网站都打不开了。
事故排查：
（1）查看CPU、内存、IO、服务
- 查CPU使用情况，发现 %idle 为50% ，还算正常，不是CPU被耗尽导致的负载升高。
# iostat -c 2 5
- 查内存使用情况，还有一半可用内存，不是内存耗尽问题。
# free -g
- 前端web服务器上，仅有Nginx、php-fpm服务。将Nginx服务停止，负载没有降。将php-fpm服务停止，负载立马降下来。
也可能是php出现了bug。查php的错误日志，没有明显的报错，没有头绪。
- 查看IO情况，%util 经常接近 100%，awati > 10ms ，明显是IO出现了问题。
# iostat -dxk 2 5
（2）排查IO问题
进一步用 iotop 命令查看：
两个推测：
1）、jbd2/sda4-8 进程占IO 95% 以上。jdb2 是ext4系统的日志功能，可能是对文件系统的操作太过频繁，而导致IO压力过大。
查看 /var/log/messages 日志，没发现任何内核出错信息。
网上查得，2013年时有反馈说ext4系统存在bug，会出现 jbd2/sda4-8进程IO使用率大。官方在之后的版本修复了这个bug。可以更新内核并重启服务器使其生效：yun update kernel
但由于重启服务器是个很危险的操作，因而推后该解决方案的优先级，继续排查另外的方向，实在没办法了，再考虑这个解决方案。
2）、写频繁，但速度很慢，怀疑是磁盘出现了坏道或者硬件故障。
想用df 命令查看磁盘挂载情况，但执行后，一直卡着，没有任何信息，更怀疑是磁盘的问题了。
因机房离公司近，特意去机房看，发现磁盘指示灯没有变红，那就不是磁盘出现坏道了。（这一项排查，耗费时间长而且麻烦，不推荐直接去机房，可以通过dd来测试磁盘速度，大致推断磁盘的健康状态。）
（3）进一步排查磁盘的问题。（假设没有去机房看磁盘灯来判断磁盘是否正常，以此情况继续排查）
综合上边分析，目前不清楚是磁盘出问题或者php-fpm服务有bug。
该服务器只有一个磁盘，分为三个分区，挂载点分别为：/ 、/boot 、/home 。
先用dd测试磁盘写的速度：
# time dd if=/dev/zero of=/home/www/test.dbf bs=8k count=300000 oflag=direct
报错，提示没有空间创建新文件。开始以为是磁盘空间被占满了，用 df 命令查看，被卡着，没有消息。只好跑去看监控记录，发现三个挂载点的空间都是够用的。
尝试手动去/home目录下创建文件，也是无法创建，提示不能打开一个只读文件。什么鬼？难道是磁盘被设为了只读？
再在另外两个挂载点目录下创建文件，能成功创建，那就应该是 /home 挂载点有问题。
磁盘空间够用，但却无法创建新文件，会不会是iNode耗尽了？
# df -i
果然，磁盘的iNode被耗光了，准确说是/home挂载的分区的iNode耗光了。
（4）排查/home目录下，耗费iNode最多的子目录
iNode是随磁盘分区格式化时，根据磁盘空间的大小而计算出来的，所以是不能通过修改系统配置来改变的，只能通过删除文件来空出iNode。
统计指定目录下的子目录的iNode总数：
# for i in /home/*; do echo $i; find $i | wc -l; done
经过漫长的等待（当文件多的时候，该命令耗费时间会很长，请灵活使用），发现/home/ww/php-session目录下，消耗最多iNode。
解决：
跟开发沟通过，可以直接删除该session目录里的文件，会自动生成新的。
时间紧急，session目录中文件众多，不适合使用du命令统计其占用或者find命令查找文件并删除。直接使用rm -rf 命令删除 php-session目录。再重新生成新的php-session目录（里边是二级session目录，子目录需要手动生成。）
之后，重启Nginx服务和php-fpm服务，网站恢复正常。
补充：
利用 rm 命令删除 php-session 目录，当文件量很大的时候（超过千万文件），非常占用IO资源，甚至导致负载飙升，服务不可用。
因而，要用nice命令，调低进程优先级，不能影响业务的正常运行：
# nice -n 19 rm -rf php-session
2、因nfs服务端挂掉，而造成的挂载端负载飙升的问题。
问题描述：
收到告警，一台前端web服务器上，负载飙到300，严重影响业务。
事故排查：
(1) 查CPU、内存、磁盘、IO，都没有问题，查不出明显过分占用资源的进程。还有什么因素会导致负载升高呢？
(2) 怀疑可能涉及到设备故障或者系统级的bug。
利用 dmesg 命令，查看相关的系统信息，发现了踪迹：（大量出现以下记录）
nfs: server 133.111.124.138 not responding, timed out nfs: server 133.111.124.138 not responding, timed out nfs: server 133.111.124.138 not responding, timed out
查系统日志/var/log/messages，也频繁出现以下记录：
Mar 29 22:00:05 web2 kernel: nfs: server 133.111.124.138 not responding, timed out
(3) 检查发现，133.111.124.138端提供的nfs服务，已经不能正常使用，client还在不断发送请求而自动没有放弃。
解决方法：
(1)、用umount卸载该nfs，提示设备 is busy ... 。umount -f 强制卸载，也不管用。
(2)、为了能卸载nfs，需要查找出当前访问该nfs的进程：
# fuser -m -v 挂载点目录
得知，是Nginx和php-fpm进程在访问。
(3)、停止Nginx和php-fpm的服务。
也可以使用 fuser 杀掉相关进程：
# fuser -km 挂载点目录
(4)、重新umount，成功了。
(5)、重启相关服务，负载恢复正常。
