df与du查看磁盘空间使用不一致的解决方法

近一段时间，某台服务器的磁盘空间使用不太正常，与其他的服务器相比，严重超出磁盘空间使用

使用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服务后，服务器在真实的删除这个早就删除的文件吧。

等磁盘负载下降到正常水平，再通过上述命令查看，磁盘使用情况总算正常了，特留此文章已被纪念缅怀。。。