在 sar 中等待

Question

我的数据库服务器具有以下数据设备的 sar 输出：

[postgres@dbsrv07 ~]$ LC_ALL=POSIX sar -d  |egrep "await|dev253-2"

00:00:01          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util

00:10:01     dev253-2   2721.27  18357.23  20291.52     14.20    613.68    225.51     0.15     40.60

00:20:01     dev253-2   1345.04    574.92  10685.38      8.37    290.65    215.99      0.06      8.61

00:30:01     dev253-2    801.39    193.53   6364.92      8.18     87.49    109.34      0.07      5.95

00:40:01     dev253-2    832.95    195.70   6617.82      8.18     89.30    107.20      0.07      5.87

00:50:01     dev253-2    835.58    162.90   6644.64      8.15     85.35    102.14      0.06      5.24

01:00:01     dev253-2    847.99    232.36   6722.90      8.20     89.91    106.03      0.07      5.64

01:10:01     dev253-2   2240.78   2295.28  17543.52      8.85    163.37     72.91      0.10     23.06

01:20:01     dev253-2   2706.18   1358.97  21482.68      8.44    175.98     65.00      0.08     20.73

01:30:01     dev253-2   5839.31   3292.69  45960.39      8.43    520.98     89.19      0.07     42.24

01:40:01     dev253-2   5221.88   1945.32  41384.97      8.30    553.92    106.05      0.06     33.85

高等待持续一整天。

我是否正确地假设这表明存在 I/O 瓶颈？

谢谢

Answer 1

svctm是衡量在命令离开 IO 调度程序并且 IO 不再受内核控制后存储响应的时间。您在这里看到的时间不到 1 毫秒，这非常好。

await是衡量给定 IO 在整个 IO 调度程序中花费的时间。你在这里看到数百毫秒，这是非常糟糕的。不同的人/供应商对什么是“好”有不同的看法，我认为 50 毫秒以下是好的。

如果您的物理存储速度很慢，您会看到一个大的 svctm 和一个大的等待。如果内核的 IO 很慢，你会看到一个很大的 await 但很小的 svctm。

你对这个设备使用什么 IO 调度程序？鉴于小 IO 大小 (8kb)，您更关心请求的延迟而不是批量吞吐量。您最好使用截止日期调度程序，而不是默认的 cfq 调度程序。

这是通过在 grub.conf 中的内核行上放置电梯 = 截止日期并重新启动来完成的。

另外，鉴于您在队列中备份了数百个 IO ( avgqu-sz )，并且您正在进入数千个 IOPS ( tps )，我假设这些是数据库 IO，可能是直接的，所以它们无法合并到更大的请求中或利用页面缓存，您可能只是对存储子系统期望过高。