Postgres работает медленно после завершения индексирования

Question

Мои postgres работали очень медленно в последнее время, агрегация в течение месяца обычно заканчивалась тем, что занимала более 1 минуты (точнее, последняя заняла 7 минут и 23 секунды).

В прошлую пятницу я воссоздал серверы (мастер и реплика) и реимпортировал базу данных.

Первое, что я заметил, это то, что из 133gb теперь база данных составляет 42 гб (фактические данные составляют около 12 гб, я думаю, что остальные индексы).

Все было быстро, как ад в течение дня, после чего индексация закончена (26gb по индексам), и теперь я вернулся к площади 1.

Отсчет на ~ 5 миллионов строк занимает 3 минуты 42 сек.

Сделано autovacuum более агрессивным, и похоже, что он делает это сейчас, но DB все еще медленно.

Я использую db для API, поэтому он постоянно растет. У Atm у меня 2 таблицы, у которых около 5 мил строк, а остальные 28 мил.

Итак, если у хозяина много активности и, предположим, я ожидаю некоторую потерю производительности, я не ожидаю этого от реплики.

Что такое любопытство в том, что после перезагрузки это очень быстро в течение часа или около того.

Также я заметил, что при каждом запросе IO составляет 100%, а память и процессор почти не используются вообще.

Любая помощь была бы принята с благодарностью.

Update

же база данных на меньшем машине работает как шарм. Те же запросы, те же самые индексы. Единственное различие заключается в трафике, а не в написании или обновлении.

Также я забыл упомянуть об одном, один из моих индексов сгруппирован.

Живая машина представляет собой 5 ячеек с 64 гб и 3 кО. Испытательная машина представляет собой 2 ядра с 4 ГБ и SSD.

Update

Найдено мой вопрос. По-видимому, автовакуум не может получить блокировку, и к тому времени, когда он получит его, увеличились мертвые кортежи.

Сделано autovacuum более агрессивным на данный момент и удалил кучу неиспользуемых индексов.

По-прежнему не знаю, как исправить проблему блокировки tho.

Update

Похоже, что-то растет оценочное количество строк. С момента моего последнего обновления количество строк увеличилось на 2 мили. Я предполагаю, что завтра количество строк будет снова около 12 мил, и счет будет медленным, как черт возьми.

Может ли это быть связано с autovacuum?

Обновление Хорошо найдена моя проблема. Похоже, postgres теряет большую скорость в базе данных с интенсивной записью. Имел столбец, который использовался как флаг и обновлялся много раз в день. Все выглядит очень хорошо после того, как флаг и обновление были удалены.

Любая подсказка о том, как исправить эту проблему на таблице интенсивной записи?

Answer 1

Может быть следующие указатели справки:

• Вы действительно уверены, что хотите сделать 5mil строки Aggregation для API? Каждый раз ? Разве вы не можете разбить данные на куски, так что только небольшое количество кусков фактически получает большинство новых строк (и, следовательно, агрегация всех предыдущих кусков может быть повторно использована для следующего запроса)? Время - одна из таких мер, серийные номера могут быть другими и т. Д. Если это так, разделение данных является очевидным решением, которое вы должны исследовать, у него действительно есть хорошие шансы дать вам временные интервалы запроса (при условии, что вы храните скопления для предыдущих кусков шикарно).

• Удовлетворение этой первой часовой магии заключается в том, что хотя эти данные подходят для ОЗУ, одновременное выполнение запросов выталкивает данные, а затем его чисто дискретный ввод-вывод ... и в этом случае CPU/RAM не работает Не удивительно.

• Наконец, я думаю, что эта настройка требует повторного проектирования, где есть только столько, что вы могли бы сделать с одним SQL, и в ожидании подсекундных запросов времени для данных, которые не находятся в ОЗУ для 5-миллиметровый набор данных, вероятно, слишком оптимистичен!

(Тем не менее, не размещать свои выводы, если это возможно)