Надзвичайно повільний IO з простими PostgreSQL 8.4.4 запитами на Centos 5.5

Дивна і надзвичайно повільна модель вводу-виводу, яку я бачу, така (вихід 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

Я не знаю, чому використання та очікування диска настільки велике, а частота читання / запису така низька. Що може бути причиною цього?

Запитувана таблиця містить лише кілька стовпців вархар, один з яких - прізвище, яке індексується (фактично lower(last_name)індексується). Сам запит простий:

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

Ось пояснення результату:

                                           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)

Також зауважте, що база даних знаходиться на auto_vacuum, тому явного вакууму / аналізу не виконували.

Той факт, що ваш пристрій /dev/xvdb1означає, що ви працюєте під Xen. Як налаштовано ваше сховище? Чи є суперечки для базового пристрою, і як це iostatвиглядає на цьому ?

Якщо ви не зможете усунути це, як імовірно, саме там я збираюся вказати на крутящийся спінер з поганої продуктивності.

По суті, загальний підхід до розв’язування такої проблеми продуктивності, як це, полягає в тому, щоб подумати про всі шари, де може виникнути вузьке місце, а потім розробити тести для усунення кожного, поки ви не вирішите проблему.

Ось кілька пропозицій у більш-менш випадковому порядку:

1. Autovacum за замовчуванням не включений у CentOS. Ви можете встановити кілька налаштувань, щоб увімкнути це. Перевірте, щоб процес вакууму насправді запустився. Легко пропустити одне з необхідних налаштувань.

2. Зауважте, що для цього запиту потрібно зробити другий крок фільтра, який може бути дорогим залежно від того, що ви отримаєте назад. Я б розглядав такий індекс, як:

   СТВОРИТИ INDEX споживач_m_lower_last ON споживач_m (нижній (прізвище));

   Який буде відповідати вашому запиту та видалити повторну перевірку.

3. Крім того, як вказує mattdm, ви не можете довіряти йостату у віртуалізованих умовах.

4. Ви, ймовірно, повинні перевірити http://lonesysadmin.net/2008/02/21/elevatornoop/, чи є проблеми з IO у середовищі XEN. Налаштування ліфтів можуть мати вплив, але це не так багато.

5. Чи базовий диск використовує знімки LVM? Незважаючи на те, що це дуже корисно з точки зору управління, воно може вбити продуктивність вводу-виводу. Це справедливо і в тому випадку, якщо блоковий пристрій, на який ви призначаєте, - це знімок, і якщо зроблено знімок блокового пристрою.

Я сумніваюся, що це проблема з PostgreSQL, і швидше за все, це проблема з дисковим IO. Як зазначаються в коментарях з іншої відповіді, якщо мова йде про проблему вводу-виводу диска, ви дійсно повинні вимірювати Dom0, щоб ви отримали уявлення про все, що відбувається.

Я мав дуже схожу проблему назад, і виявилося, що це проблема з дисковим контролером. Дуже повільний доступ до диска змусив систему до вузького місця в очікуванні дискового вводу-виводу (який виявився як дуже високий середній навантаження і час очікування, але також спричинив процеси, що очікують, що диск буде споживати більше процесора, ніж інакше. Виявилося, що ядро не розпізнав контролер належним чином і повертався на старий шкільний контролер IDE замість швидкого sata.

Виправлення полягало в завантаженні

hda=noprobe hda=none 

в кінці рядка ядра в /etc/grub.conf. (Звичайно, додайте всі наявні у вас диски, ала: hdc=noprobe, hdc=none, hdd=...)