Чрезвычайно медленный ввод-вывод с простыми запросами 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

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

Запрашиваемая таблица просто имеет несколько столбцов varchar, один из которых - last_name, который индексируется (фактически 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. Автовакуум не включен по умолчанию в CentOS. Есть несколько настроек, которые вы должны установить, чтобы включить его. Дважды проверьте, чтобы процесс вакуума действительно выполнялся. Легко пропустить одну из необходимых настроек.

2. Обратите внимание, что вы должны выполнить второй шаг фильтра для этого запроса, который может быть дорогостоящим в зависимости от того, что вы получите. Я хотел бы рассмотреть такой индекс, как:

   CREATE INDEX потребитель_m_lower_last ON потребитель_m (нижний (фамилия));

   Который будет соответствовать вашему запросу и убрать перепроверку.

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

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

5. Использует ли базовый диск снимки LVM? Хотя это очень полезно с точки зрения управления, оно может снизить производительность ввода-вывода. Это верно как в том случае, если используемое вами блочное устройство является моментальным снимком, так и в том случае, если был сделан моментальный снимок блочного устройства.

Я сомневаюсь, что это проблема PostgreSQL, и, скорее всего, проблема только с дисковым вводом-выводом. Как отмечается в комментариях к другому ответу, если речь идет о проблеме с дисковым вводом-выводом, вам действительно следует измерить Dom0, чтобы получить представление обо всем, что происходит.

Некоторое время назад у меня была очень похожая проблема, и это оказалось проблемой с контроллером диска. Очень медленный доступ к диску приводил к возникновению узкого места в системе во время ожидания дискового ввода-вывода (что проявлялось в очень высокой средней нагрузке и времени ожидания, но также приводило к тому, что процессы, ожидающие, что диск потребляет больше ресурсов ЦП, чем в противном случае. Оказалось, что ядро не распознавал контроллер должным образом и возвращался к старому школьному IDE-контроллеру вместо быстрого sata.

Исправление состояло в том, чтобы загрузить с

hda=noprobe hda=none 

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