Centos 5.5上使用简单PostgreSQL 8.4.4查询的IO极慢

我看到的奇怪且极其缓慢的IO模式是（输出iostat -dxk 1 /dev/xvdb1）：

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.99  0.99     7.92     3.96    12.00     1.96 2206.00 502.00  99.41

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     1.00    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     1.00    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.99  0.00     3.96     0.00     8.00     0.99 2220.00 1004.00  99.41

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     1.00    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.99  0.99  0.00     7.92     0.00    16.00     1.14 2148.00 1004.00  99.41

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  0.00  0.00     0.00     0.00     0.00     2.01    0.00   0.00 100.40

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdb1             0.00     0.00  1.00  1.00     4.00     8.00    12.00     2.01 1874.00 502.00 100.40

我不知道为什么磁盘利用率和等待率如此之高，而读/写率却如此之低。这可能是什么原因？

要查询的表仅包含几个varchar列，其中之一是last_name，该索引已建立索引（实际上lower(last_name)已建立索引）。查询本身很简单：

SELECT * FROM consumer_m WHERE lower(last_name) = 'hoque';

这是说明输出：

                                           QUERY PLAN                                            
-------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on consumer_m  (cost=2243.90..274163.41 rows=113152 width=164)
   Recheck Cond: (lower((last_name)::text) = 'hoque'::text)
   ->  Bitmap Index Scan on consumer_m_last_name_index  (cost=0.00..2215.61 rows=113152 width=0)
         Index Cond: (lower((last_name)::text) = 'hoque'::text)

另请注意，数据库位于auto_vacuum上，因此未执行明确的清理/分析。

设备的事实/dev/xvdb1表明您正在Xen下运行。如何配置您的存储？是否有潜在的设备争，以及如何做iostat上看是？

除非您能尽可能消除这种情况，否则我将指出糟糕的性能归咎于旋转陀螺。

基本上，解决此类性能问题的总体方法是考虑可能发生瓶颈的所有层，然后设计测试以消除每一层，直到您找出问题所在。

以下是一些建议，或多或少是随机的：

1. 默认情况下，CentOS中不启用自动真空。您必须设置多个设置才能启用它。仔细检查，以便真空程序真正运行。容易错过所需的设置之一。

2. 请注意，您必须为该查询执行第二个过滤步骤，根据返回的内容，该步骤可能会很昂贵。我会考虑一个索引，例如：

   CREATE INDEX Consumer_m_lower_last ON Consumer_m（lower（last_name））;

   它将与您的查询匹配并删除重新检查。

3. 而且，正如mattdm指出的那样，您不能在虚拟化环境中信任iostat。

4. 如果您在XEN环境中遇到IO问题，则可能应该检查http://lonesysadmin.net/2008/02/21/elevatornoop/。电梯设置可能会产生影响，但影响并不大。

5. 基础磁盘是否使用LVM快照？尽管从管理角度来看这非常有用，但它可能会破坏IO性能。如果您使用的块设备是快照，以及已经为该块设备拍摄了快照，则都是如此。

我怀疑这是PostgreSQL的问题，很可能只是磁盘IO的问题。正如另一个答案中提到的那样，如果这是磁盘IO问题，那么您实际上应该从Dom0进行测量，以便获得所有正在发生的情况的图片。

不久前，我遇到了一个非常类似的问题，事实证明这是磁盘控制器的问题。磁盘访问速度非常慢，导致系统在等待磁盘IO时遇到瓶颈（这显示出很高的平均负载和等待时间，而且还导致等待磁盘的进程比其他方式消耗更多的CPU。事实证明，内核无法正确识别控制器，而是退回到旧式的IDE控制器上，而不是快速安装的控制器。

解决方法是使用

hda=noprobe hda=none 

在/etc/grub.conf中内核字符串的末尾。（当然，添加您拥有的所有磁盘，ala：hdc=noprobe, hdc=none, hdd=...）