- Иногда база данных падает из-за некоторых запросов, и нам сказали, что нужно оптимизировать PostgreSQL. Есть идеи, как этого добиться?
На изображении ниже показаны ресурсы нашей БД:- CPU: 4 vCPU
- Память: 22 ГБ
Всем привет, я работаю над этим вместе с @Abdelrahman_MoHamed. Недавно мы мигрировали на Discourse сайт, содержащий примерно 500 тысяч тем и 3,5 миллиона пользователей. Мы размещаемся самостоятельно на GCP. В ходе этого процесса наш партнёр, который помогал с миграцией, отметил, что, возможно, стоит оптимизировать Postgres для обеспечения должной производительности базы данных. Мы предполагали, что база данных будет оптимизирована для Discourse «из коробки» (может быть, так и есть?). Однако, учитывая их предложение, мы хотели бы уточнить это здесь.
Если коротко: являются ли это распространёнными способами оптимизации Postgres для базы данных с такими показателями?
Заранее спасибо за помощь!
У вас есть более подробные доказательства того, что СУБД является узким местом или причиной высокой нагрузки на процессор? Например, вывод команд ps или top.
Если проблема в СУБД, полагаю, существует способ узнать, над какими запросами она работает в данный момент.
Такие детали могли бы быть полезны.
Спасибо, @Ed_S. Мы скоро добавим здесь больше данных. Пока просто отслеживаем ситуацию. Благодарим за ответ.
Это действительно кажется странным сочетанием… 22 ГБ памяти, но всего 4 vCPU? Избыток памяти, но, возможно, слишком мало ядер.
Обычно на сервере гораздо больше vCPU на гигабайт памяти.
Это связано с тем, что веб-сервинг очень параллелен, и для каждого процесса Unicorn требуется всего около 1 ГБ.
Кажется, каждый Unicorn может работать на отдельном ядре.
Возможно, именно поэтому у вас так легко достигается 100% загрузка процессора.
Я бы рекомендовал рассмотреть возможность перехода на конфигурацию 16/16 или даже 8/8 и посмотреть, улучшится ли ситуация.
Разрешены ли небольшие отклонения? Похожи ли единороги на рабочих PHP? В некоторых документах пытались объяснить, что единороги — это на самом деле HTTP-серверы со своими собственными рабочими, которые передают запросы Ruby, и поэтому они совершенно другие. Но и те, и другие обрабатывают HTTP-запросы, позволяя обслуживать больше одновременных запросов; следовательно, больше рабочих PHP и больше единорогов требуют больше оперативной памяти — и для меня эти две вещи во многом одинаковы.
Правильно или ужасно неверно? Я хотел бы понять принцип сейчас, потому что я знаю, почему, когда и как настраивать рабочих PHP, но единороги для меня — просто мистические и магические существа.
Да, я думаю, это справедливое сравнение.
Связанное: Как администратор может узнать, слишком ли мало или слишком много у него «единорогов» для его веб-трафика?
Связанное: Как администратор может узнать, есть ли у него значительно больше оперативной памяти, чем необходимо?
Мое понимание таково, что количество «единорогов» обычно масштабируется в соответствии с количеством процессоров, но это не обязательно должно быть так — например, если конфигурация хоста изменилась с момента настройки.
Объем оперативной памяти должен масштабироваться в зависимости от потребностей. Я не знаю, обязательно ли огромный импорт множества постов и пользователей требует больше оперативной памяти — вопрос в том, какая часть базы данных используется для обработки каждого веб-запроса или каждой обычной задачи?
Для меня 10-минутный всплеск максимальной загрузки процессора на фоне очень низкой общей нагрузки не указывает на проблему. (Это было бы проблемой, если бы это означало, что очень активный и критичный по времени форум, например, спортивный или игровой, испытывал задержки в отдаче страниц в периоды пикового интереса. Но мой форум не является критичным по времени или производительности.)
Я не знаю, как можно свести в таблицу диапазон последних времен отклика, но это может быть хорошим показателем для анализа. Либо со стороны веб-сервера, либо со стороны базы данных.