首页 > 其他分享 >解决服务器I/O过高的问题

解决服务器I/O过高的问题

时间:2022-11-12 10:03:14浏览次数:43  
标签:top 文件系统 过高 jdb2 IO MySQL 解决 服务器 日志

问题缘起: 当我习惯性地用top查看任务运行状态时,发现我运行的100个任务,只有3个在运行,其他都在摸鱼状态。同时发现我的任务进程都是"D"状态(未截图),而不是R(运行)状态。

解决服务器I/O过高的问题_ios

1.top状态

这个时候,我直觉上感觉这是硬盘读写除了问题,于是我开始检索查找相关工具去验证我的猜想

先用的是iostat -x 2 10,如果%util 接近100%说明产生的I/O请求太多,I/O系统满负荷,%idle小于70%,IO压力就很大。

解决服务器I/O过高的问题_文件系统_02

2.iostat 结果

从上图明显发现我的IO压力过大。当然作为科研人员,我们都知道我们需要多个证据才能证实自己的猜想,于是进一步用iotop, 发现有许多进程的IO居然是99%.

解决服务器I/O过高的问题_文件系统_03

3.iotop

既然确定服务器性能下降的原因是IO。那么下一步就是找到导致磁盘压力过大的真凶。用dstat --top-bio-adv找到那个进程占用IO最多, 此处发现是jdb2/sda1-8 的写出数据超多

解决服务器I/O过高的问题_mysql_04

4.dstat --top-bio-adv

利用关键字"jdb2/sda1-8"经过搜索,发现很多人都遇到这种情况,

有些认为是RAID磁盘矩阵导致的问题
有人认为是MySQL的问题。

刚好,我的服务器是RAID,又刚好我今天改动了MySQL。但是直觉告诉我,应该不是这两个问题,因为我虽然改了MySQL的配置文件,但是我基本不用MySQL, 所以排除这个可能。

但是,目前我已经顺利确认就是"jdb2/sdax-y"的问题(x表示是分区),于是我就主要检索了jdb2

jbd2的全称是journaling block driver 。这个进程实现的是文件系统的日志功能,磁盘使用日志功能来保证数据的完整性。这个需要评估一下安全和性能哪个更重要,对于一个应用服务器来说,并不保存重要的用户数据,只是实现业务逻辑。如果是数据库的话,就需要考虑启动磁盘写入的完整性检查。但是现在大部分系统在业务和架构层面已经考虑了业务完整性。所以为性能计,这里并不是非常有必须启动日志功能。

5.网络上的人提供了如下三种解决方案:

升级内核
更改commit的次数, "mount -o remount,commit=60 /dev/sda1"
关闭文件系统日志功能: 操作类似于dumpe2fs 获取文件系统属性信息, tune2fs 调整文件系统属性, 之后e2fsck 检查文件系统(几乎大部分都不推荐这样做)

当然这些方案,我一个都没有采纳,因为我突然想到今天服务器上似乎运行了许多IO操作很频繁的程序,jdb2的特点就是牺牲了性能保证了数据完整性,也就是说是我运行的程序太多让jdb2忙不过来了。

因此我的最终解决方案就是,用kill把所有当前运行的高IO程序都干掉。最后解决了问题。




标签:top,文件系统,过高,jdb2,IO,MySQL,解决,服务器,日志
From: https://blog.51cto.com/u_13753753/5846526

相关文章