Бесконечно работающие процессы Postgres и низкая производительность после переустановки/восстановления

В попытке обновить наш форум я провел чистую установку VPS и восстановление данных в выходные.

Это должно было решить сразу несколько наших проблем:

  • Обновить устаревший Ubuntu
  • Обновить Discourse
  • Перейти на Postgres 15

В целом всё прошло гладко, но после этого я заметил проблемы: процессы Postgres начали бесконтрольно потреблять 100% одного ядра. Количество процессов при этом варьировалось. Я попробовал несколько решений: от полной пересборки до перезапусков. Сейчас запускаю rake db:validate_indexes, который уже работает несколько часов без какой-либо отдачи. Не уверен, делал ли я это раньше и должно ли это выполняться быстрее.

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

Я почти уверен, что проблемы связаны с базой данных, но мне трудно понять, какие именно.

Скажу сразу: наша база данных довольно огромна — после восстановления и создания индексов её размер составляет около 150 ГБ. Судя по мониторингу процесса восстановления, ошибок не было, и создание индексов, насколько я могу судить, прошло успешно.

Есть ли у кого-то идеи, как с этим справиться? Сейчас запущено 3 процесса Postgres; до перезагрузки, которую я сделал несколько часов назад, их было 6. После восстановления я уже наблюдал использование всех 16 ядер.

РЕДАКТИРОВАНИЕ: Только что заметил, что 3 процесса Sidekiq заняты задачей «indexing categories for search». Не связано ли всё это с перестроением поискового индекса? Если да, можно ли решить это другим способом? При восстановлении на рабочей системе это станет серьёзной проблемой, если производительность будет снижаться в течение нескольких часов или даже дней.

Сейчас выполняется только одна задача Sidekiq с классом «Jobs::BackfillBadge», но 7 процессов PostgreSQL постоянно блокируют 100% процессора. Очень интересно, что там происходит.

После таких действий рекомендуется выполнить vacuum для обновления статистики базы данных.

Сколько у вас оперативной памяти и процессора?

Сколько памяти вы выделяете для PostgreSQL?

Тестовый сервер имеет 32 ГБ ОЗУ и 16 ядер, конфигурация установлена на 64 МБ рабочей памяти.

РЕДАКТИРОВАНИЕ: Общий буфер установлен на 8 ГБ.

В данный момент выполняется вакуумирование, которое, похоже, зависло.

Не уверен, выполняет ли оно какие-либо действия, но оно уже висит более 30 минут.

Я перевел форум в режим только для чтения и перезагрузил виртуальную машину, чтобы завершить 7 процессов Postgres, которые ранее были «зависшими». Сразу после перезапуска два из этих процессов Postgres вернулись и не изменились. В данный момент в Sidekiq ничего не выполняется.

Вам действительно не стоит запускать VACUUM на полностью заполненном хранилище. Чтобы восстановить производительность, достаточно выполнить VACUUM VERBOSE ANALYZE. На работающем сайте запускать FULL нельзя.

Я не эксперт в работе с огромными базами данных, но я бы сделал буферы в два-три раза больше.

Уверен, у вас есть индексы размером 8 ГБ.

:thinking: Postgres рекомендует никогда не устанавливать shared_buffers выше 40% от внутренней памяти?

Тем не менее,

Возможно, ваш сервер недостаточно мощный.

Ага! Разумный совет от эксперта! Так что, возможно, я был прав, что 8 ГБ/25% недостаточно, и хотя 16 ГБ больше 40%, это всё ещё может быть хорошим предложением, потому что . . . .

Ребята, как уже говорилось, это тестовый сервер — на нём нет трафика. Этот сервер определённо не подходит для продакшена, но дело не в этом. Вопрос в том, почему мы видим процессы PostgreSQL, которые висят в таком состоянии (с 100% загрузкой CPU) и сильно замедляют работу. Мы запускали тестовый сервер даже с меньшими ресурсами ещё несколько дней назад — его увеличили только из-за нехватки места на диске для восстановления.

Продакшен-машина работает с 128 ГБ оперативной памяти с теми же настройками Shared Buffers без каких-либо проблем — поэтому я не думаю, что здесь есть общая проблема с этими настройками и размером Shared Buffers, особенно на приватном тестовом сервере без трафика.

В любом случае — я просто повторю восстановление и посмотрю, не произошло ли чего-то не так, поскольку, похоже, нет хорошего объяснения такому поведению.