一個由INode節點爆滿引起的業務故障

標籤：

一個由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

一個由INode節點爆滿引起的業務故障