一个由INode节点爆满引起的业务故障

Posted 2020-06-20 技术为王

一个由INode节点爆满引起的业务故障

http://2358205.blog.51cto.com/2348205/1747951

 

好久没有写博文了，今天周六，分享一下刚刚处理完的一个小故障

 

现象描述：

运营妹纸那边反应运营后台报错，具体如下：

 

 

一开始以为是tmp的目录没有权限写入，查看目录权限，777，不是这个问题；

 

查看nginx的错误日志，部分错误信息如下，500错误:

113.xx.xx.48 - - [05/Mar/2016:19:33:09 +0800] "POST /index.php?r=site/login HTTP/1.1" 500 112266 "http://xxx.xxx.com/index.php?r=site/login" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (Khtml, like Gecko) Chrome/48.0.2564.116 Safari/537.36"

14.xx.xx.67 - - [05/Mar/2016:19:33:14 +0800] "GET /index.php?r=site/login HTTP/1.1" 500 120922 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.122 Safari/537.36 SE 2.X MetaSr 1.0"

 

 

查看mysql的错误日志，日志如下，但是查看了较早以前，也有以下报错，之前不出现问题，为什么偏偏这时候报错，应该不是这个问题引起的，继续查...

 

登陆进数据库，查看数据库表，可以select表数据，但是desc结构的时候，连续desc了几张表，结果都一样，报以下错误：

 

难道是表损坏了?屁颠屁颠执行表修复命令，命令如下：

/usr/local/mysql/bin/mysqlcheck --all-databases -uUSERNAME -pPASSWORD -r

 

部分表修复过程如下：

 

 

修复完成之后，妈蛋，还是一样的报错信息，

 

 

仔细看看，妈蛋，这是写不了临时文件的意思吗？但是为什么desc会涉及创建临时文件的问题呢？有待深究！！

ERROR 1 (HY000):Can‘t create/write to file ‘/tmp/#sql_3b25_0.MYI‘ (Errcode:28)

 

 

 

是不是磁盘空间满了？没收到报警信息啊。。。抱着疑惑的心态查看了下磁盘空间，具体如下：

[[email protected] ~]# df -h

Filesystem      Size  Used Avail Use% Mounted on

/dev/xx1       20G  6.9G   12G  37% /

tmpfs           3.9G     0  3.9G   0% /dev/shm

/dev/xxx        63G   26G   34G  44% /mnt

 

没满啊。。。奇怪。。看下my.cnf文件是不是有什么改动。

 

vim的时候报了一个错误。如下：

E303:Unable to open swap file for "my.cnf",recovery impossible

 

一开始没留意，继续编辑，看了下文件里面的内容，没改动啊，权限和属主也是正常的，那就奇怪了。。

 

然后vim一下其他文件，也是有提示错误。。。。无法创建交换文件。。

 

 

于是我试试touch一下，哎呀，创建不了新文件，mkdir呢，也是一样。。提示没有磁盘空间。。。

touch: cannot touch `e‘: No space left on device

 

刚刚df -h不是很明显还有空间么。难道是文件的节点数满了？果断df -i一下。。。

[[email protected] ~]# df -i

Filesystem      Inodes  IUsed   IFree IUse% Mounted on

/dev/xxx     1310720 171826 1138894   100% /

tmpfs          1007261      1 1007260    1% /dev/shm

/dev/xxx      4194304 463685 3730619   12% /mnt

 

 

果然，/目录的节点数使用了100%，于是，问题找到了，那再查查到底是什么文件占用了这么多的文件节点.

 

最后定位到/var/spool/clientmqueue下面有很多的小文件。

说明：系统中cron执行的程序有输出内容，输出内容会以邮件形式发给cron的用户，而sendmail没有启动所以就产生了这些文件；

 

 

既然知道这个文件产生的原因，删除掉呗，当前保证业务能正常运行最重要。

 

cd到/var/spool/clientmqueue这个目录下，使用rm -rf ./*  ，哎呀，不给删？报错:

/bin/rm: argument list too long

最后使用ls |xargs rm -rf 删除。。。。

说明：使用rm默认接收的参数是有限的，使用此命令可以将文件名输出并且分组删除。。

 

使用df -i再次查看，/目录的节点数也释放了一些。再次访问业务，搞定！！

[[email protected] clientmqueue]# df -i

Filesystem      Inodes  IUsed   IFree IUse% Mounted on

/dev/xxx     1310720 171826 1138894   14% /

tmpfs          1007261      1 1007260    1% /dev/shm

/dev/xxx      4194304 463685 3730619   12% /mnt

 

 

说明：inode译成中文就是索引节点，每个存储设备（例如硬盘）或存储设备的分区被格式化为文件系统后，应该有两部份，一部份是inode，另一部份是Block，Block是用来存储数据用的。而inode呢，就是用来存储这些数据的信息，这些信息包括文件大小、属主、归属的用户组、读写权限等。inode为每个文件进行信息索引，所以就有了inode的数值。操作系统根据指令，能通过inode值最快的找到相对应的文件。

 

 

监控系统里除了剩余磁盘容量监控，应该把剩余inode数量监控也要加上~
df.bytes.free.percent; df.inodes.free.percent

---

 

 /var/spool/clientmqueue/目录下存在大量文件的原因及解决方法 2
 http://blog.itpub.net/22036495/viewspace-1056821/

 

问题现象：linux操作系统中的/var/spool/clientmqueue/目录下存在大量文件。

原因分析：

　　系统中有用户开启了cron，而cron中执行的程序有输出内容，输出内容会以邮件形式发给cron的用户，而sendmail没有启动所以就产生了这些文件；

　　解决办法:
　　1、 将crontab里面的命令后面加上> /dev/null 2>&1