Niezwykle wolne IO z prostymi zapytaniami PostgreSQL 8.4.4 na Centos 5.5

Dziwny i wyjątkowo wolny wzorzec We / Wy, który widzę, jest następujący (wynik 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

Nie wiem, dlaczego wykorzystanie dysku i oczekiwanie jest tak wysokie, a szybkość odczytu / zapisu jest tak niska. Jaki może być tego powód?

Tabela, której dotyczy zapytanie, ma po prostu tylko kilka kolumn varchar, z których jedna to last_name, która jest indeksowana (faktycznie lower(last_name)jest indeksowana). Samo zapytanie jest proste:

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

Oto wynik wyjaśnienia:

                                           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)

Zauważ też, że baza danych jest na auto_vacuum, więc nie przeprowadzono wyraźnej próżni / analizy.

Fakt, że twoje urządzenie /dev/xvdb1sugeruje, że pracujesz pod Xenem. Jak skonfigurowana jest Twoja pamięć? Czy istnieje spór o podstawowe urządzenie i jak iostatna tym wygląda ?

Chyba że możesz wyeliminować to jako prawdopodobne, właśnie tutaj zamierzam wskazać wirujący wirnik złej wydajności.

Zasadniczo ogólnym podejściem do rozwiązania tego problemu jest pomyślenie o wszystkich warstwach, w których może wystąpić wąskie gardło, a następnie opracowanie testów w celu wyeliminowania każdej z nich, dopóki problem nie zostanie odizolowany.

Oto kilka sugestii, w mniej lub bardziej losowej kolejności:

1. Autovacum nie jest domyślnie włączony w CentOS. Aby go włączyć, musisz skonfigurować wiele ustawień. Sprawdź dwa razy, aby proces vacum faktycznie się uruchomił. Łatwo pominąć jedno z wymaganych ustawień.

2. Pamiętaj, że musisz wykonać drugi krok filtrowania dla tego zapytania, co może być kosztowne w zależności od tego, co otrzymasz. Rozważałbym taki indeks jak:

   UTWÓRZ INDEKS Consumer_m_lower_last ON konsument_m (dolna (ostatnia nazwa));

   Który będzie pasował do twojego zapytania i usunie ponowne sprawdzenie.

3. Ponadto, jak zauważa mattdm, nie można ufać iostatowi w środowiskach zwirtualizowanych.

4. Prawdopodobnie powinieneś sprawdzić http://lonesysadmin.net/2008/02/21/elevatornoop/, jeśli masz problemy z IO w środowisku XEN. Ustawienia windy mogą mieć wpływ, ale nie tak duże.

5. Czy dysk bazowy używa migawek LVM? Jest to bardzo przydatne z punktu widzenia zarządzania, ale może zabić wydajność IO. Jest to prawdą zarówno wtedy, gdy urządzenie blokowe, z którego korzystasz, to migawka, jak i jeśli została wykonana migawka urządzenia blokowego.

Wątpię, że jest to problem z PostgreSQL, a bardziej prawdopodobne jest tylko problem z dyskowym We / Wy. Jak wspominają komentarze z innej odpowiedzi, jeśli jest to problem z dyskowym We / Wy, naprawdę powinieneś zmierzyć z Dom0, aby uzyskać obraz wszystkiego, co się dzieje.

Jakiś czas temu miałem bardzo podobny problem i okazało się, że jest to problem ze sterownikiem dysku. Bardzo wolny dostęp do dysku powodował wąskie gardło systemu podczas oczekiwania na IO dysku (co pokazało się jako bardzo wysokie średnie obciążenia i czasy oczekiwania, ale także powodowało, że procesy czekające na dysk zużywały więcej procesora niż w innym przypadku. Okazało się, że jądro nie rozpoznawał poprawnie kontrolera i wracał do oldschoolowego kontrolera IDE zamiast szybkiego sata.

Rozwiązaniem było uruchomienie z

hda=noprobe hda=none 

na końcu łańcucha jądra w /etc/grub.conf. (Oczywiście dodaj wszystkie posiadane dyski, ala: hdc=noprobe, hdc=none, hdd=...)