我的数据库服务器具有以下数据设备的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瓶颈？
谢谢
svctm衡量存储在命令离开IO调度器后需要多长时间进行响应，而IO不再受内核控制。 你看这里是不到1ms，这是非常好的。
等待是给定IO在整个IO调度器中花费多长时间的度量。 你在这里看到几百毫秒，这是非常糟糕的。 不同的人/供应商对什么是“好”有不同的看法，我认为50ms以下是好的。
如果你的物理存储是缓慢的，你会看到一个大的svctm和一个很大的等待。 如果内核的IO很慢，你会看到一个很大的等待，但小svctm。
你使用什么IO调度程序到这个设备？ 鉴于IO规模较小（8kb），您关心的是请求延迟而不是大容量吞吐量。 你可能最好使用截止date调度程序，而不是默认的cfq调度程序。
这是通过在grub.conf的kernel行上放置电梯=最后期限并重新启动来完成的。
另外，考虑到你在队列中备份了数百个IO（ avgqu-sz ），并且你进入了数千IOPS（ tps ），并且我认为这些数据库IO很可能是直接的他们不能被合并到更大的请求或利用页面caching，你可能只是期望太多的存储子系统。
几乎（:-)）
等待是服务时间和等待时间（等待时间）的组合，您真正关心的是等待时间。 如果你的服务时间大约是10毫秒，那么当等待的时间和服务时间一样大时，情况会变得很慢。
对于Sun磁盘arrays来说，10毫秒是一个很好的服务时间：我不知道什么时候适合您的磁盘，但是我怀疑您看到了I / O瓶颈。
从superjami的评论看来，你有一个“磁盘/arrays之上”的瓶颈。 我会以调度的方式询问postgres社区他们推荐的内容。 在我在Solaris的日子里，我们可以使用主要是数据库引擎的机器的“cray”调度表。
–dave