我的数据库服务器具有以下数据设备的 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 瓶颈?
谢谢
答案1
韓國是衡量命令离开 IO 调度程序后存储响应时间的指标,IO 不再受内核控制。您在这里看到的响应时间不到 1 毫秒,这非常好。
等待是衡量给定 IO 在整个 IO 调度程序中所花费时间的指标。您在这里看到的是数百毫秒,这非常糟糕。不同的人/供应商对什么是“好”有不同的看法,我认为低于 50 毫秒是好的。
如果物理存储速度较慢,您会看到较大的 svctm 和较大的 await。如果内核的 IO 速度较慢,您会看到较大的 await 但较小的 svctm。
您对此设备使用哪种 IO 调度程序?鉴于 IO 大小较小(8kb),您更关心请求的延迟而不是批量吞吐量。与默认的 cfq 调度程序相比,您最好使用 deadline 调度程序。
这是通过放置电梯=最后期限在 grub.conf 中的内核行上并重新启动。
此外,考虑到队列中有数百个 IO 备份(平均曲),并且你将获得数千 IOPS(每秒),我认为这些是数据库 IO,很可能是 directio,因此它们不能合并到更大的请求中或利用页面缓存,您可能对存储子系统期望太高。
答案2
几乎 (:-))
await 是服务时间和等待时间(延迟)的组合,您真正关心的是等待时间。如果您的服务时间约为 10 毫秒,那么当等待时间与服务时间一样长时,事情就会变得缓慢。
对于 Sun 磁盘阵列来说,10 毫秒是一个很好的服务时间:我不知道您的磁盘的最佳服务时间是多少,但我有点怀疑您看到了 I/O 瓶颈。
答案3
从 superjami 的评论来看,似乎磁盘/阵列“上方”存在瓶颈。我会向 postgres 社区询问他们推荐的调度方式。在我使用 Solaris 的那段时间里,我们会对主要用作数据库引擎的机器使用“cray”调度程序表...
--戴夫