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