近一段時間，某台服務器的磁盤空間使用不太正常，與其他的服務器相比，嚴重超出磁盤空間使用
使用df與du相關命令查看，具體結果如下：
du -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 50G 42G 5.5G 89% /
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 48K 1.9G 1% /dev/shm
tmpfs 1.9G 613M 1.3G 33% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
tmpfs 380M 0 380M 0% /run/user/1003
tmpfs 380M 0 380M 0% /run/user/0
du --max-depth=1 -h
0 ./proc
0 ./sys
12K ./opt
34M ./etc
16K ./lost+found
611M ./run
4.0K ./media
1.9G ./data
4.0K ./mnt
532M ./var
5.7G ./usr
200K ./home
4.0K ./srv
792K ./tmp
16M ./root
0 ./dev
216M ./boot
8.9G .
把比較大的日志文件刪除或者清空后仍不見好轉
后來，在網上查找相關原因，得到的結論如下：
在Linux中，當我們使用rm在linux上刪除了大文件，但是如果有進程打開了這個大文件，卻沒有關閉這個文件的句柄，那么linux內核還是不會釋放這個文件的磁盤空間，最后造成磁盤空間占用100%，整個系統無法正常運行。這種情況下，通過df和du命令查找的磁盤空間，兩者是無法匹配的，可能df顯示磁盤100%，而du查找目錄的磁盤容量占用卻很小。
於是使用如下命令：lsof -n | grep deleted ，找出那些文件已經被刪除，但是還有進程在訪問這些文件的進程，經過查詢可知，是mysql的鍋，果斷重啟mysql服務。
重啟mysql的過程心驚膽戰的，總擔心起不來，因為之前遇到過mysql服務重啟起不來的情況，不過幸好，服務重啟竟然起來了。
然后就是服務器卡的要死，通過使用top命令查看，發現磁盤負載很高，細心觀察，負載在逐漸下降，這個就應該是重啟mysql服務后，服務器在真實的刪除這個早就刪除的文件吧。
等磁盤負載下降到正常水平，再通過上述命令查看，磁盤使用情況總算正常了，特留此文章已被紀念緬懷。。。