性能常识 磁盘满导致的 cpu 飙升案例

会飞的猪 · 2019年12月02日 · 最后由 会飞的猪 回复于 2020年04月23日 · 4048 次阅读

事件描述
公司监控系统事件报警某个应用的磁盘满了。通过后端执行命令发现 CPU 占用 200%。此应用的配置信息为:2C8G 磁盘为:40G
如下图所示

通过图上的标红的几个指标可以看到:1)CPU 使用率很高 2)CPUload 都三位数了。😜 3)si 占用 10% 左右。

当然这个问题我比较清楚是磁盘的原因。
采取措施
删除大文件文件。
然而删除大文件后发现磁盘空间并未释放,是因为文件删除了但是对应的进程没杀掉,但是磁盘空间还未释放。也找不到大文件了。CPU 使用仍然超高。
然后用 jvm 自带的工具查看,进一步确认是文件的读写导致的 CPU 使用率高。

最后进行了杀掉进程才发现磁盘被释放,重启应用系统恢复正常。所以这个性能问题给我们一个提示:有时候你看到的性能表象不一定真正是问题的原因。CPU 很高不一定是 CPU 的核数不够,有可能是磁盘或者内存的问题导致的 CPU 飙升,所以要透过问题看本质,才能真正的解决性能问题。

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 8 条回复 时间 点赞

然而删除大文件后发现磁盘空间并未释放,是因为文件删除了但是对应的进程没杀掉,但是磁盘空间还未释放。

有点不理解,麻烦解释一下哈。磁盘空间满了,导致 IO 堵塞可以理解,为什么应用的进程没杀掉会导致磁盘空间不释放?磁盘空间的管理不是 linux 内核吗?为什么应用会干扰到这个行为呢?

Karaser 回复

一般说来不会出现删除文件后空间不释放的情况,但是也存在例外,比如文件被进程锁定,或者有进程一直在向这个文件写数据等等,要理解这个问题,就需要知道 Linux 下文件的存储机制和存储结构。

一个文件在文件系统中的存放分为两个部分:数据部分和指针部分,指针位于文件系统的 meta-data 中,数据被删除后,这个指针就从 meta-data 中清除了,而数据部分存储在磁盘中,数据对应的指针从 meta-data 中清除后,文件数据部分占用的空间就可以被覆盖并写入新的内容,之所以出现删除文件后,空间还没释放,就是因为进程还在一直向这个文件写入内容,导致虽然删除了文件,但文件对应的指针部分由于进程锁定,并未从 meta-data 中清除,而由于指针并未被删除,那么系统内核就认为文件并未被删除,因此通过 df 命令查询空间并未释放也就不足为奇了。 不知道这个解释你是否明白。

会飞的猪 回复

👍
所以是不是体现了 finally 关闭文件流的重要性😂

Karaser 回复

其实事实是这样的,程序里是关闭文件流了,但是磁盘不足,导致一直在写文件并且没有😀 写完。

5楼 已删除

没看懂,怎么就能知道是磁盘满了啊,top 哪些属性不是系统内容和系统负载么

王_test 回复

公司监控系统事件报警某个应用的磁盘满了,我对此应用配置了监控报警

仅楼主可见
仅楼主可见
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册