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