IO extremadamente lento con consultas simples de PostgreSQL 8.4.4 en Centos 5.5

El extraño y extremadamente lento patrón IO que estoy viendo es este (salida de 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

No sé por qué la utilización del disco y la espera es tan alta, y las tasas de lectura / escritura son tan bajas. ¿Cuál podría ser la razón de esto?

La tabla que se consulta simplemente tiene varias columnas varchar, una de las cuales es last_name, que está indexada (en realidad lower(last_name)está indexada). La consulta en sí es simple:

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

Aquí está la salida de explicación:

                                           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)

También tenga en cuenta que la base de datos está en auto_vacuum, por lo que no se realizó un vacío / análisis explícito.

El hecho de que su dispositivo sea /dev/xvdb1implica que está ejecutando bajo Xen. ¿Cómo se configura su almacenamiento? ¿Existe contención para el dispositivo subyacente, y cómo se iostatve en eso ?

A menos que pueda eliminar eso lo más probable, ahí es donde voy a señalar la rueda giratoria de la culpa del bajo rendimiento.

Básicamente, el enfoque general para desenredar un problema de rendimiento como este es pensar en todas las capas donde podría ocurrir un cuello de botella, y luego idear pruebas para eliminar cada una hasta que se aísle el problema.

Aquí hay algunas sugerencias, en orden más o menos aleatorio:

1. Autovacum no está activado de forma predeterminada en CentOS. Hay varias configuraciones que debe configurar para habilitarlo. Verifique dos veces para que el proceso de vacío realmente se ejecute. Es fácil pasar por alto una de las configuraciones requeridas.

2. Tenga en cuenta que debe realizar un segundo paso de filtro para esa consulta, que puede ser costoso dependiendo de lo que obtenga. Consideraría un índice como:

   CREATE INDEX consumer_m_lower_last ON consumer_m (lower (last_name));

   Lo cual coincidirá con su consulta y eliminará el Recheck.

3. Además, como señala mattdm, no puede confiar en iostat en entornos virtualizados.

4. Probablemente debería consultar http://lonesysadmin.net/2008/02/21/elevatornoop/ si tiene problemas de E / S en un entorno XEN. La configuración del elevador puede tener un impacto, pero no tan grande.

5. ¿El disco subyacente utiliza instantáneas LVM? Si bien esto es muy útil desde una perspectiva de gestión, puede asesinar el rendimiento de IO. Esto es cierto tanto si el dispositivo de bloque que está utilizando es una instantánea como si se ha tomado una instantánea del dispositivo de bloque.

Dudo que esto sea un problema con PostgreSQL, y es más probable que sea solo un problema con Disk IO. Como mencionan los comentarios de otra respuesta, si se trata de un problema de E / S de disco, realmente debe medir desde Dom0 para obtener una imagen de todo lo que está sucediendo.

Tuve un problema muy similar hace un tiempo y resultó ser un problema con el controlador de disco. El acceso muy lento al disco estaba causando el cuello de botella del sistema mientras esperaba el disco IO (que se mostró como promedios de carga muy altos y tiempos de espera, pero también causó que los procesos que esperaban al disco consumieran más CPU de lo que lo harían de otra manera. Resultó que el núcleo no estaba reconociendo el controlador correctamente y estaba volviendo a caer en el controlador IDE de la vieja escuela en lugar de uno rápido sata.

La solución fue arrancar con

hda=noprobe hda=none 

al final de la cadena del núcleo en /etc/grub.conf. (Por supuesto, agregue todos los discos que tenga, ala: hdc=noprobe, hdc=none, hdd=...)