近一段时间，某台服务器的磁盘空间使用不太正常，与其他的服务器相比，严重超出磁盘空间使用
使用 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 服务后，服务器在真实的删除这个早就删除的文件吧。
等磁盘负载下降到正常水平，再通过上述命令查看，磁盘使用情况总算正常了，特留此文章已被纪念缅怀。。。