E / S extremamente lenta com consultas simples do PostgreSQL 8.4.4 no Centos 5.5

O estranho e extremamente lento padrão de E / S que estou vendo é este (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 e a espera do disco são tão altas e as taxas de leitura / gravação são tão baixas. Qual poderia ser o motivo disso?

A tabela que está sendo consultada simplesmente possui várias colunas varchar, uma das quais é last_name, que é indexada (na verdade, lower(last_name)é 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, nenhuma análise / vácuo explícito foi executada.

— ehsanul
fonte

Você personalizou o seu postgresql.conf? Se o CentOS tiver os mesmos padrões que o RHEL 5.x, você terá pouca memória para o postgres, o que pode forçar muita IO do disco. Qual o tamanho das linhas nesta tabela?

— Thiago Figueiro

A tabela cabe na memória, assim como obviamente o índice; foi particionado dessa maneira. E o postgresql.conf foi adequadamente customizado (shared_buffers, effective_cache_size etc). Mesmo que não fosse esse o caso, eu não esperaria um desempenho tão degenerado.

— ehsanul

Respostas:

O fato de o seu dispositivo estar /dev/xvdb1implica que você está executando o Xen. Como o seu armazenamento está configurado? Existe disputa para o dispositivo subjacente, e como o iostatolhar no que ?

A menos que você possa eliminar isso como provável, é aí que eu vou apontar o girador giratório da culpa pelo mau desempenho.

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 uma delas até você isolar o problema.

— mattdm
fonte

Sem contenda. Embora você esteja certo de que este é um servidor virtual, o disco rígido foi totalmente dedicado a esse servidor e só estou executando uma consulta ao banco de dados por vez, sem outras operações intensivas do servidor. O armazenamento é apenas um único disco SATA giratório. Observe que eu tenho alguns outros servidores / bancos de dados (separados) com praticamente a mesma configuração, mas que funcionam rapidamente com baixo IO, como esperado, com consultas / indexação semelhantes.

— ehsanul

Você pode executar iostatno disco a partir do dom0 apenas para ver se a imagem é semelhante? Você pode fazer outros benchmarks básicos de disco de ambos os níveis? Isso pelo menos ajudará a diminuir para onde procurar a seguir.

— amigos estão dizendo sobre mattdm

Certo. Por que você espera uma discrepância com base em sua iostatorigem? Isso deveria importar? Na verdade, não tenho acesso direto ao dom0 agora, embora eu possa obtê-lo. fioEnquanto isso, tentarei fazer comparações.

— ehsanul

por uma coisa: instantâneos pode criar tal situação

— Hubert Kario

Você estava certo no mattdm, houve disputa, aparecendo no dom0. Era um problema de comunicação, meu chefe havia entregue parte do disco rígido a outro servidor sob o gerenciamento de outra pessoa, sem o meu conhecimento. Fiquei com a impressão de que era dedicado, porque é assim que sempre o configuramos. Eu acho que é por isso que é sempre importante checar suas suposições. Obrigado!

— ehsanul

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

O Autovacum não está ativado por padrão no CentOS. Você deve definir várias configurações para habilitá-lo. Verifique novamente para que o processo vacum realmente seja executado. É fácil perder uma das configurações necessárias.
Observe que você precisa executar 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 (mais baixo (last_name));

O que corresponderá à sua consulta e removerá a verificação novamente.
Além disso, como aponta o mattdm, você não pode confiar no iostat em ambientes virtualizados.
Você provavelmente deve verificar http://lonesysadmin.net/2008/02/21/elevatornoop/ se tiver problemas de E / S em um ambiente XEN. As configurações do elevador podem ter um impacto, mas não tão grande.
O disco subjacente está usando instantâneos do LVM? Embora isso seja muito útil do ponto de vista de gerenciamento, ele pode prejudicar o desempenho de E / S. Isso ocorre tanto se o dispositivo de bloco que você está usando for um instantâneo quanto se um instantâneo tiver sido obtido do dispositivo de bloco.

— pehrs
fonte

Obrigado pelas sugestões. O índice está realmente em baixo (last_name), embora eu tenha deixado de fora "lower" do nome do índice. Então, eu não sei por que há uma verificação novamente lá. De fato, o disco montado /está usando instantâneos do LVM, mas não aquele em que o banco de dados está armazenado. Então eu não acho que é isso. Vou analisar suas outras sugestões!

— ehsanul

Duvido que este seja um problema com o PostgreSQL e, provavelmente, apenas um problema com o Disk IO. Como os comentários de outra resposta mencionam, se for um problema de E / S de disco, você realmente deve medir no Dom0 para obter uma imagem de tudo o que está acontecendo.

Eu tive um problema muito semelhante há um tempo e acabou sendo um problema com o controlador de disco. O acesso muito lento ao disco estava causando gargalos no sistema enquanto aguardava a E / S do disco (que mostrava médias de carga e tempos de espera muito altos, mas também fazia com que os processos que aguardavam o disco consumissem mais CPU do que de outra forma. não estava reconhecendo o controlador corretamente e estava voltando ao controlador IDE da velha escola em vez de um sata rápido.

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=...)

— Jed Daniels
fonte

Obrigado, mas acontece que era algo muito mais tolo nesse caso. Vote de qualquer maneira.

— ehsanul