Чрезвычайно медленный ввод-вывод с простыми запросами 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, поэтому явный вакуум / анализ не выполнялся.
3 ответа
Тот факт, что ваше устройство /dev/xvdb1 подразумевает, что вы работаете под Xen. Как настроено ваше хранилище? Есть ли спор за базовое устройство, и как iostat смотреть на это?
Если вы не можете устранить это как можно скорее, именно здесь я собираюсь указать на вращающуюся вращающуюся вину за низкую производительность.
По сути, общий подход к решению проблемы производительности, подобной этой, состоит в том, чтобы продумать все уровни, где может возникнуть узкое место, а затем разработать тесты для устранения каждого из них, пока вы не изолируете проблему.
Вот несколько предложений в более или менее случайном порядке:
Автовакуум по умолчанию не включен в CentOS. Есть несколько настроек, которые вы должны установить, чтобы включить его. Дважды проверьте, чтобы процесс вакуума действительно выполнялся. Легко пропустить одну из необходимых настроек.
Обратите внимание, что вы должны выполнить второй шаг фильтра для этого запроса, который может быть дорогостоящим в зависимости от того, что вы получите. Я хотел бы рассмотреть такой индекс, как:
CREATE INDEX потребитель_m_lower_last ON потребитель_m (нижний (фамилия));
Который будет соответствовать вашему запросу и убрать перепроверку.
Кроме того, как указывает mattdm, вы не можете доверять iostat в виртуализированных средах.
Вам, вероятно, следует проверить http://lonesysadmin.net/2008/02/21/elevatornoop/ если у вас есть проблемы с IO в среде XEN. Настройки лифта могут оказать влияние, но не настолько большое.
Использует ли базовый диск снимки LVM? Хотя это очень полезно с точки зрения управления, оно может убить производительность ввода-вывода. Это верно как в том случае, если используемое вами блочное устройство является моментальным снимком, так и в том случае, если был сделан моментальный снимок блочного устройства.
Я сомневаюсь, что это проблема PostgreSQL, и, скорее всего, проблема только с дисковым вводом-выводом. Как отмечается в комментариях к другому ответу, если речь идет о проблеме с дисковым вводом-выводом, вам действительно следует измерить Dom0, чтобы получить представление обо всем, что происходит.
Некоторое время назад у меня была очень похожая проблема, и это оказалось проблемой с контроллером диска. Очень медленный доступ к диску приводил к возникновению узкого места в системе во время ожидания дискового ввода-вывода (который проявлялся как очень высокая средняя нагрузка и время ожидания, но также приводил к тому, что процессы, ожидающие, что диск потребляет больше ресурсов ЦП, чем в противном случае. не распознавал контроллер должным образом и возвращался к старому школьному IDE-контроллеру вместо быстрого sata.
Исправление состояло в том, чтобы загрузить с
hda=noprobe hda=none
в конце строки ядра в /etc/grub.conf. (Конечно, добавьте все диски, которые у вас есть, аля: hdc=noprobe, hdc=none, hdd=...)