IO estremamente lento con semplici query PostgreSQL 8.4.4 su Centos 5.5

Lo strano ed estremamente lento pattern IO che sto vedendo è questo (output di 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

Non so perché l'utilizzo del disco e l'attesa siano così alti e le velocità di lettura / scrittura sono così basse. Quale potrebbe essere la ragione di ciò?

La tabella da interrogare ha semplicemente diverse colonne varchar, una delle quali è last_name, che è indicizzata (in realtà lower(last_name)è indicizzata). La query stessa è semplice:

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

Ecco l'output esplicativo:

                                           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)

Si noti inoltre che il database è su auto_vacuum, quindi non è stato eseguito alcun vuoto / analisi espliciti.

Il fatto che il tuo dispositivo sia /dev/xvdb1implica che stai funzionando con Xen. Come viene configurato il tuo spazio di archiviazione? C'è lizza per il dispositivo sottostante, e come iostatsguardo sul che ?

A meno che tu non riesca ad eliminarlo come probabile, è qui che indicherò il vorticoso filatore di scarsa colpa delle prestazioni.

Fondamentalmente, l'approccio generale per districare un problema di prestazioni come questo è quello di pensare a tutti i livelli in cui potrebbe verificarsi un collo di bottiglia, e quindi escogitare test per eliminarli tutti fino a quando non si isola il problema.

Ecco alcuni suggerimenti, in ordine più o meno casuale:

1. Autovacum non è attivato per impostazione predefinita in CentOS. Ci sono più impostazioni che devi configurare per abilitarlo. Ricontrolla in modo che il processo vacum venga effettivamente eseguito. È facile perdere una delle impostazioni richieste.

2. Si noti che è necessario eseguire un secondo passaggio del filtro per quella query, che può essere costoso a seconda di ciò che si ottiene. Vorrei prendere in considerazione un indice come:

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

   Che corrisponderà alla tua query e rimuoverà il controllo.

3. Inoltre, come sottolinea mattdm, non puoi fidarti di iostat in ambienti virtualizzati.

4. Probabilmente dovresti controllare http://lonesysadmin.net/2008/02/21/elevatornoop/ se hai problemi di I / O in un ambiente XEN. Le impostazioni dell'ascensore possono avere un impatto, ma non così grande.

5. Il disco sottostante utilizza snapshot LVM? Mentre questo è molto utile dal punto di vista gestionale, può uccidere le prestazioni di IO. Questo vale sia se il dispositivo a blocchi che stai utilizzando è un'istantanea, sia se è stata presa un'istantanea del dispositivo a blocchi.

Dubito che questo sia un problema con PostgreSQL ed è più probabile che sia solo un problema con Disk IO. Come menzionano i commenti di un'altra risposta, se si tratta di un problema di I / O su disco, dovresti davvero misurare da Dom0 in modo da ottenere un'immagine di tutto ciò che sta accadendo.

Ho avuto un problema molto simile qualche tempo fa e si è rivelato essere un problema con il controller del disco. L'accesso al disco molto lento stava causando il collo di bottiglia del sistema in attesa di IO del disco (che si presentava come medie di carico e tempi di attesa molto elevati, ma causava anche processi in attesa che il disco consumasse più CPU di quanto avrebbero altrimenti. non riconosceva correttamente il controller e ricadeva sul controller IDE della vecchia scuola anziché su un veloce sata.

La correzione era l'avvio

hda=noprobe hda=none 

alla fine della stringa del kernel in /etc/grub.conf. (Naturalmente, aggiungi tutti i dischi che hai, ala: hdc=noprobe, hdc=none, hdd=...)