Linux Troubleshooting Disk Analysis

关于磁盘的使用,实际生产中以下问题会较为常见:

  • No space left on device - 空间不足
  • Disk utilization 100% - 磁盘I/O过载
  • Too many open files - 文件句柄过多
  • Input/output error - 读写错误

而掌握常见的分析套路会事半功倍。

Disk usage

第一时间明确磁盘容量及使用情况总是没错的,这时候df -h 命令就比较方便:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev             48G  4.0K   48G   1% /dev
tmpfs           9.5G  8.55G  9.5G   90% /run
/dev/sda1       275G  234G   28G  90% /
/dev/sdd1       2.7T  1.6T  1.2T  57% /disk3
/dev/sdc1       3.6T  2.6T  1.1T  72% /disk1
/dev/sdb1       3.6T  4.2G  3.6T   1% /disk2

Use% 这个指标就比较清晰展示目标磁盘已经使用多少了。

注意,第三行的tmpfs文件系统比较特殊,其数据实际是存储在内存中而非磁盘。

Inode usage

有时候我们会发现明明磁盘有容量,但是程序仍然报No space left on device,这是因为什么呢?

答案大概率是Inode耗尽了。这时候可以通过df -i 来确认,比如:

$ df -i
Filesystem        Inodes   IUsed     IFree IUse% Mounted on
udev            12370103     518  12369585    1% /dev
tmpfs           12372788     611  12372177    1% /run
/dev/sda1       18317312 1941821  16375491   11% /
/dev/sdd1      183148544   181317058 1831468  99% /disk3
/dev/sdc1      244195328  153483 244041845    1% /disk1
/dev/sdb1      244195328    7496 244187832    1% /disk2

可以看到/disk3对应的目录其Inode已经使用99%,很快就会耗尽。Inode代表的是文件的metadata信息,若inode使用过多,通常意味着目录里小文件太多了。

PS: 不规范的容器化姿势比较容易出现这个问题,比如Pod一直在产生日志,且使用的是系统盘又不定期回收。

Disk utilization high

磁盘使用率高,一般是已经知道是哪个盘了,但如果不知道,使用iostat -x 1也能较清晰的查看到:

$ iostat -x 1
Linux 3.19.0-80-generic  	2022年05月12日 	_x86_64_	(24 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.85    0.00    3.60    4.83    0.00   85.72

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00   237.00  441.00   48.00 56448.00  1388.00   236.55     0.97    1.98    1.02   10.83   1.00  48.80
sdb               0.00    26.00    2.00  186.00     8.00 93876.00   998.77    44.51  348.13  466.00  346.86   5.32 100.00
sdc               0.00     0.00  155.00    7.00 18132.00    16.00   224.05     6.62   47.95   46.71   75.43   4.02  65.20
sdd               0.00    30.00    8.00    8.00   900.00   212.00   139.00     0.10    6.25    3.50    9.00   6.00   9.60

PS: iostat -xd <device> 1 可以只查看某个设备。

可以看到sdb这块盘,其%util指标已经100%。

但要注意,%util高并不严格意味着磁盘已经过载了,因为现代硬盘设备都有并行处理多个I/O请求的能力。要关注磁盘利用率,还需要关注await(再具体就是读r_await和写w_await指标),这个指标大致等于单个I/O所需的平均时间,所以如果它也很大,那磁盘一定是很繁忙了。

Which processes are using the specific disk?

实际场景中,面对磁盘负载高,我们通常需要做的是找到"罪魁祸首",判断其行为是否符合预期。

粗略的可以通过 iotop -oP 直接查看当前正在读写的进程。一般机器上有哪些程序,我们应该比较清楚,所以这时候可以大致判断出来:

$ iotop -oP
Total DISK READ :     173.26 M/s | Total DISK WRITE :     177.38 M/s
Actual DISK READ:     175.77 M/s | Actual DISK WRITE:      85.50 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 6929 be/4 root      168.67 M/s  168.57 M/s  0.00 % 76.51 % dd if=/dev/sda bs=4M count=100000 of=mbr.img
  379 be/3 root        0.00 B/s   15.61 K/s  0.00 %  2.01 % [jbd2/sda1-8]

当然这种方式也存在一个问题,你是看不出目标进程具体使用哪块磁盘的。那怎么办呢?可以借助lsof +D <目录>命令,通过正在打开的文件句柄来识别进程:

$ lsof +D /disk2
COMMAND     PID       USER   FD   TYPE DEVICE    SIZE/OFF      NODE NAME
prometheu  1705       root  mem    REG   8,17    72567556 234356807 /disk2/prometheus_dir/data/01G2J2YMJPY9HXMP5KSPW30MM1/chunks/000001
prometheu  1705       root  mem    REG   8,17    73620431 234356815 /disk2/prometheus_dir/data/01G19H692F7JN796CBQDSFVV1W/chunks/000001
prometheu  1705       root  mem    REG   8,17    73173252 234356814 /disk2/prometheus_dir/data/01G13QSNA21PYK2R6SC0BFYZYM/chunks/000001

然后通过pidstat -d 进一步分析这些进程的读写情况 :

$ pidstat -d
Linux 3.19.0-80-generic 	2022年05月15日 	_x86_64_(24 CPU)
16时21分37秒   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
16时21分59秒     0      1705     64.00     67.19      0.00  prometheus

kB_rd/s和 kB_wr/s 这两个指标,能基本代表进程读写磁盘的速度。

Too many open files

相信后端同学大多都遇到过Too may open files的错误,因为高并发场景下,服务会建立很多连接,这时候就会很容易遇到这个错误。

可以通过ls -1 /proc/<pid>/fd | wc -l命令来查看当前进程已经打开了多少个文件:

$ ls -1 /proc/1705/fd | wc -l
1258

而若想查看某进程具体的句柄限制,可以通过命令cat /proc/<pid>/limits:

$ cat /proc/1705/limits
Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            8388608              unlimited            bytes
Max core file size        0                    unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             386565               386565               processes
Max open files            20240                20240                files

而若要调整这个限制,可以通过ulimit命令或修改系统文件/etc/security/limits.conf.

EIO (input/output error)

遇到这个错误,一般是物理磁盘坏了。可能是整个盘坏了不能读写,也有可能是某个block有问题。这时候通过dmesg -T查看内核日志,通常会有相应的error信息。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
故障排除IP路由协议是指确定和解决网络中出现的IP路由问题。以下是解决此类问题的常见步骤: 1. 检查网络拓扑:了解网络中所有的路由器和交换机的位置和连接方式,确保没有物理连接问题或链路故障。 2. 检查配置文件:审查路由器和交换机的配置文件,以确保IP路由协议正确配置。确认路由表中的条目是否准确,是否存在任何问题或错误。 3. 检查邻居关系:检查邻居关系表,确保路由器与其相邻的路由器建立了正确的邻居关系。如果邻居关系失败,可能会导致路由信息无法正确传递。 4. 检查接口状态:确保所有接口都正常工作,没有接口错误或故障。检查接口状态、速率和双工模式等参数。 5. 检查路由协议状态:查看路由协议的状态和邻居表。确认协议是否正在运行,是否能够与其他路由器正常通信。 6. 检查路由信息:使用show command或debug命令查看路由表并验证路由信息是否正确。检查有关特定目的地的路由是否存在或是否显示其他不正确的路由。 7. 跟踪路由:使用traceroute命令跟踪数据包的路径,确定数据包在网络中的跳数和延迟。这可以帮助确定是否存在路由回路或错误的路由路径。 8. 日志和故障报告:检查设备的日志和故障报告,查找有关路由问题的任何错误消息或警告。这些信息可以提供更多关于故障原因的线索。 通过以上步骤,可以逐步确定IP路由协议中的故障,并采取相应的措施来解决问题,以确保网络正常运行。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

扶朕去网吧

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值