У меня уже было 4 сбоя серверов AWS ERP из-за того, что память, по-видимому, была переполнена, и система фактически умирала с 100% загрузкой ЦП и [небольшим] количеством доступной оперативной памяти.
Ubuntu 18.04.5 LTS (GNU/Linux 5.4.0-1060-aws x86_64) (AWS AMI)
Три раза это происходило в середине действия GitHub. Действие выполняло импорт базы данных, а затем уведомление Slack. Таким образом, можно было бы подумать, что один из этих шагов вызвал проблему, но, как ни странно, все шаги были выполнены нормально. С базой данных все было в порядке, и уведомление Slack было отправлено.
Сам GitHub потерял соединение с бегуном, и виртуальная память взлетела до небес даже после завершения действия.
В четвертый раз это произошло, когда НИЧЕГО не работало. Сервер фактически простаивал, и ничего не происходило. У меня нет никаких логов или "топовых" скриншотов ЭТОГО, однако, но я поймал это на месте преступления один раз:
Итак, система представляет собой виртуальную машину AWS с 4 ГБ оперативной памяти. Обратите внимание, что я считаю, что SI, который настраивал эту систему, настроил ее без пространства подкачки. Это, пожалуй, правильно [очень даже спорно] для сервера, в том смысле, что если есть утечка памяти, вы хотите, чтобы система сообщила о нехватке памяти и предприняла корректирующие действия, поскольку при утечке памяти вы в любом случае в конечном итоге умрете.
В краткосрочной перспективе меня попросили просто удвоить ОЗУ. Это несколько излишне, поскольку это очень слабо загруженная система (обычно работает всего с 2 ГБ ОЗУ при выполнении тяжелой пакетной работы), и, честно говоря, если GitHub Runner.Worker использует максимум 7 ГБ ОЗУ на системе 4 ГБ, почему бы ему не использовать максимум 16 ГБ ОЗУ на виртуальной машине 8 ГБ, но посмотрим, не рухнет ли она снова. Я не против изменения конфигурации подкачки TFG, но не уверен, что это исправит ситуацию
Я сообщил об этом на GitHub, но после более чем 3 недель бездействия решил проверить здесь и посмотреть, есть ли у кого-нибудь идеи или решения.
Спасибо,
== Джон ==