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