事件描述
公司监控系统事件报警某个应用的磁盘满了。通过后端执行命令发现 CPU 占用 200%。此应用的配置信息为：2C8G 磁盘为：40G
如下图所示
通过图上的标红的几个指标可以看到：1）CPU 使用率很高 2）CPUload 都三位数了。
3）si 占用 10% 左右。
当然这个问题我比较清楚是磁盘的原因。
采取措施
删除大文件文件。
然而删除大文件后发现磁盘空间并未释放，是因为文件删除了但是对应的进程没杀掉，但是磁盘空间还未释放。也找不到大文件了。CPU 使用仍然超高。
然后用 jvm 自带的工具查看，进一步确认是文件的读写导致的 CPU 使用率高。
最后进行了杀掉进程才发现磁盘被释放，重启应用系统恢复正常。所以这个性能问题给我们一个提示：有时候你看到的性能表象不一定真正是问题的原因。CPU 很高不一定是 CPU 的核数不够，有可能是磁盘或者内存的问题导致的 CPU 飙升，所以要透过问题看本质，才能真正的解决性能问题。
没看懂，怎么就能知道是磁盘满了啊，top 哪些属性不是系统内容和系统负载么
写完。
Karaser
回复
一般说来不会出现删除文件后空间不释放的情况，但是也存在例外，比如文件被进程锁定，或者有进程一直在向这个文件写数据等等，要理解这个问题，就需要知道 Linux 下文件的存储机制和存储结构。
一个文件在文件系统中的存放分为两个部分：数据部分和指针部分，指针位于文件系统的 meta-data 中，数据被删除后，这个指针就从 meta-data 中清除了，而数据部分存储在磁盘中，数据对应的指针从 meta-data 中清除后，文件数据部分占用的空间就可以被覆盖并写入新的内容，之所以出现删除文件后，空间还没释放，就是因为进程还在一直向这个文件写入内容，导致虽然删除了文件，但文件对应的指针部分由于进程锁定，并未从 meta-data 中清除，而由于指针并未被删除，那么系统内核就认为文件并未被删除，因此通过 df 命令查询空间并未释放也就不足为奇了。 不知道这个解释你是否明白。
然而删除大文件后发现磁盘空间并未释放，是因为文件删除了但是对应的进程没杀掉，但是磁盘空间还未释放。
有点不理解，麻烦解释一下哈。磁盘空间满了，导致 IO 堵塞可以理解，为什么应用的进程没杀掉会导致磁盘空间不释放？磁盘空间的管理不是 linux 内核吗？为什么应用会干扰到这个行为呢？