IO Extremamente Lento com PostgreSQL Simples 8.4.4 Consultas no Centos 5.5

Question

O padrão IO estranho e extremamente lento que estou vendo é isso (saída 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

Não sei por que a utilização de disco e o await são tão altos, e as taxas de leitura / gravação são muito baixas. Qual poderia ser a razão disso?

A tabela que está sendo consultada tem apenas várias colunas varchar, uma das quais é last_name, que é indexada (na verdade lower(last_name) está indexada). A consulta em si é simples:

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

Aqui está a saída de explicação:

                                           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)

Observe também que o banco de dados está em auto_vacuum, portanto, nenhum vácuo / análise explícito foi executado.

    

Answer 1

O fato de seu dispositivo ser /dev/xvdb1 implica que você está executando com o Xen. Como o seu armazenamento está configurado? Existe contenção para o dispositivo subjacente e como iostat procura esse ?

A menos que você consiga eliminá-lo como provável, é aí que eu vou apontar o giro rodopiante da má performance.

Basicamente, a abordagem geral para desvendar um problema de desempenho como esse é pensar em todas as camadas em que um gargalo poderia ocorrer e, em seguida, criar testes para eliminar cada um deles até que você isole o problema.

    

Answer 2

Aqui estão algumas sugestões, em ordem mais ou menos aleatória:

1. O Autovacum não está ativado por padrão no CentOS. Existem várias configurações que você precisa definir para ativá-lo. Verifique novamente para que o processo vacum seja realmente executado. É fácil perder uma das configurações necessárias.

2. Observe que você precisa fazer uma segunda etapa de filtro para essa consulta, que pode ser cara dependendo do que você recebe de volta. Eu consideraria um índice como:

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

   Que corresponderá à sua consulta e removerá o Recheck.

3. Além disso, como Matttmm aponta, você não pode confiar em iostat em ambientes virtualizados.

4. Você provavelmente deve verificar o link se tiver problemas de OI em um ambiente XEN. Configurações de elevador podem ter um impacto, mas não tão grande.

5. O disco subjacente está usando instantâneos do LVM? Embora isso seja muito útil de uma perspectiva de gerenciamento, ele pode matar o desempenho de IO. Isto é verdadeiro tanto se o dispositivo de bloco que você está usando é um instantâneo, e se um instantâneo foi tirado do dispositivo de bloco.

Answer 3

Eu duvido que este é um problema com o PostgreSQL, e é mais provável que seja apenas um problema com o IO do disco. Como os comentários de outra resposta mencionam, se for um problema de IO de disco, você realmente deve medir a partir de Dom0 para obter uma imagem de tudo o que está acontecendo.

Eu tive um problema muito semelhante há algum tempo e acabou sendo um problema com o controlador de disco. O acesso muito lento ao disco estava causando gargalos no sistema enquanto aguardava o disco IO (que aparecia como médias de carga e tempos de espera muito altos, mas também fazia com que os processos aguardassem que o disco consumisse mais CPU do que seria de outra forma). não estava reconhecendo o controlador corretamente e estava voltando para o controlador IDE da velha escola em vez de um rápido sata.

A correção foi inicializar com

hda=noprobe hda=none 

no final da string do kernel em /etc/grub.conf. (Claro, adicione todos os discos que você tem, ala: hdc=noprobe, hdc=none, hdd= ...)