Мы проводим нагрузочное тестирование приложения, обращающегося к базе данных Postgres.
Во время теста мы внезапно получаем увеличение частоты ошибок. Проанализировав поведение платформы и приложения, мы замечаем, что:
- Загрузка процессора Postgres RDS составляет 100%
- Освобождаемая память падает на этом же сервере
А в логах postgres мы видим:
2018-08-21 08:19:48 UTC::@:[XXXXX]:LOG: серверный процесс (PID XXXX) был завершен сигналом 9: Killed
После изучения и прочтения документации выяснилось, что одной из возможных причин является работающий Linux Oomkiller, который завершил процесс.
Но поскольку мы используем RDS, мы не можем получить доступ к системным журналам /var/log messages для подтверждения.
Так может ли кто-то:
- подтвердить, что oom killer действительно работает на AWS RDS для Postgres
- дайте нам способ это проверить?
- дайте нам способ вычислить максимальный объем памяти, используемый Postgres, на основе количества соединений?
Я не нашел ответа здесь:
решение1
Даже если OOM killer не сработал (а он, скорее всего, сработал), постоянная 100% загрузка ЦП и очень низкий уровень свободной памяти негативно сказываются на производительности.
Используйте больший размер экземпляра и посмотрите, исчезнет ли проблема. Протестируйте меньший размер на Postgres без RDS, который вы контролируете, и посмотрите, разозлится ли OOM killer.
Количество соединений не обязательно является доминирующим фактором в потреблении памяти: общая память используется для других целей, и не каждый запрос использует большой кусок памяти. См. также этот разговор:PostgreSQL выделяет память для каждого соединения.
Дополнительные советы отЛучшие практики для Amazon RDS
Рекомендации по оперативной памяти экземпляра БД
Лучшая практика производительности Amazon RDS — выделить достаточно оперативной памяти, чтобы ваш рабочий набор почти полностью находился в памяти. Чтобы узнать, находится ли ваш рабочий набор почти полностью в памяти, проверьте метрику ReadIOPS (с помощью Amazon CloudWatch), пока экземпляр БД находится под нагрузкой. Значение ReadIOPS должно быть небольшим и стабильным. Если масштабирование класса экземпляра БД — до класса с большим объемом оперативной памяти — приводит к резкому падению ReadIOPS, ваш рабочий набор не был почти полностью в памяти. Продолжайте масштабирование до тех пор, пока ReadIOPS не перестанет резко падать после операции масштабирования или ReadIOPS не уменьшится до очень небольшого значения.
Оценка показателей производительности
Освобождаемая память – объем оперативной памяти, доступной на экземпляре БД, в мегабайтах. Красная линия в метриках вкладки «Мониторинг» отмечена на уровне 75% для показателей ЦП, памяти и хранилища. Если потребление памяти экземпляра часто пересекает эту линию, это означает, что вам следует проверить рабочую нагрузку или обновить экземпляр.
решение2
У меня нет большого опыта работы с Postgres, но в той же ситуации я обнаружил, что экземпляр RDS MySql склонен полностью перезагружаться. Даже если у вас нет доступа к базовым системам, вы должны иметь возможность получить логи postgres через веб-консоль. Ищите перезагрузку, демон должен показывать, что он закрывается и запускается.
В любом случае, если вы работаете в опасной зоне, то мало что можно сделать. Вам следует перейти на экземпляр с большим объемом оперативной памяти / процессора.