Автовакуум PostgreSQL вызывает значительное снижение производительности - PullRequest
Новая
       61

Автовакуум PostgreSQL вызывает значительное снижение производительности

0 голосов
/ 22 февраля 2019

Наша БД Postgres (размещенная на Google Cloud SQL с 1 ЦП, 3,7 ГБ ОЗУ, см. Ниже) состоит в основном из одной большой таблицы размером ~ 90 ГБ и приблизительно 60 миллионов строк.Шаблон использования состоит почти исключительно из добавлений и нескольких индексированных чтений в конце таблицы.Время от времени несколько пользователей удаляются, удаляя небольшой процент строк, разбросанных по всей таблице.

Все это прекрасно работает, но каждые несколько месяцев в этой таблице запускается автоочистка, что значительно влияет на производительность нашего сервиса.в течение ~ 8 часов:

  • Увеличение объема памяти увеличивается на ~ 1 ГБ в течение периода работы автовакуума (несколько часов), а затем медленно возвращается к предыдущему значению (может в конечном итоге упасть ниже его из-за освобождения от автогакуума).страниц)
  • Загрузка ЦП базы данных увеличивается с <10% до ~ 20% </li>
  • Операции чтения / записи на диске увеличиваются с почти нуля до ~ 50 / сек
  • Память базы данных немного увеличивается, но остается ниже 2 ГБ
  • Транзитные / входные и входные / выходные байты также практически не затронуты, как и следовало ожидать

Это приводит к увеличению 95-го процентиля латентности нашего сервиса с ~От 100 мс до ~ 0,5-1 с во время автовакуума, что, в свою очередь, запускает наш мониторинг.Служба обслуживает около десяти запросов в секунду, причем каждый запрос состоит из нескольких простых операций чтения / записи в БД, каждый из которых обычно имеет задержку 2-3 мс.

Вот несколько скриншотов мониторинга, иллюстрирующих проблему:

CPU usage Storage usage Memory usage Read/Write operations Latency

Конфигурация БД довольно ванильна:

DB configuration

Запись в журнале, документирующая этот процесс автоочистки, выглядит следующим образом: 

system usage: CPU 470.10s/358.74u sec elapsed 38004.58 sec
avg read rate: 2.491 MB/s, avg write rate: 2.247 MB/s
buffer usage: 8480213 hits, 12117505 misses, 10930449 dirtied
tuples: 5959839 removed, 57732135 remain, 4574 are dead but not yet removable
pages: 0 removed, 6482261 remain, 0 skipped due to pins, 0 skipped frozen
automatic vacuum of table "XXX": index scans: 1

Какие-нибудь предложения, что мы могли бы настроить, чтобы уменьшить влияние будущих автовакуумов на наш сервис?Или мы что-то не так делаем?

1 Ответ

0 голосов
/ 22 февраля 2019

Если вы можете увеличить autovacuum_vacuum_cost_delay, ваш автовакуум будет работать медленнее и будет менее инвазивным.

Тем не менее, обычно лучшим решением будет сделать его быстрее, установив autovacuum_vacuum_cost_limit в 2000 или около того.Затем он заканчивается быстрее.

Вы также можете попытаться самостоятельно составить расписание VACUUM таблицы, когда это причиняет наименьший вред.

Но, честно говоря, если одного безобидного автовакуума достаточно, чтобы беспокоитьваша операция, вам нужно больше пропускной способности ввода / вывода.

...