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

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


现象描述:node

运营妹纸那边反应运营后台报错,具体以下:mysql

wKioL1ba6RyAMcIEAADNML8EkwI987.png



一开始觉得是tmp的目录没有权限写入,查看目录权限,777,不是这个问题;nginx


查看nginx的错误日志,部分错误信息以下,500错误:sql

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"vim



查看mysql的错误日志,日志以下,可是查看了较早之前,也有如下报错,以前不出现问题,为何恰恰这时候报错,应该不是这个问题引发的,继续查...ide

wKioL1ba6qfgqeMuAAApwuNVerw958.png


登录进数据库,查看数据库表,能够select表数据,可是desc结构的时候,连续desc了几张表,结果都同样,报如下错误:url

spacer.gifwKiom1ba7VmD_p_GAAAPHRiR09M895.png


难道是表损坏了?屁颠屁颠执行表修复命令,命令以下:spa

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


部分表修复过程以下:

wKiom1ba7fryyMTbAAAvR5lTx8o949.png



修复完成以后,妈蛋,仍是同样的报错信息,



仔细看看,妈蛋,这是写不了临时文件的意思吗?可是为何desc会涉及建立临时文件的问题呢?有待深究!!

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




是否是磁盘空间满了?没收到报警信息啊。。。抱着疑惑的心态查看了下磁盘空间,具体以下:

[root@xxxxxx ~]# 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一下。。。

[root@xxxx ~]# 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再次查看,/目录的节点数也释放了一些。再次访问业务,搞定!!

[root@xxxx 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值最快的找到相对应的文件。

相关文章
相关标签/搜索