У меня есть виртуальная машина на GCE, на которой я запускаю собственный образ Docker. Я установил его на COS (cos-stable-74-11895-125-0) на экземпляр g1-small (1 виртуальный ЦП, 1,7 ГБ памяти).
Это Elasticsearch с заблокированными настройками памяти. Он потребляет ровно 1 ГБ оперативной памяти.
Установка работала безупречно почти год, но внезапно перестала работать из-за нехватки памяти.
На последовательной консоли он регистрирует, что был вызван oom-killer, и выбирает java-процесс для уничтожения. После быстрого перезапуска он работает отлично, но примерно через день или два он выходит из строя с той же ошибкой нехватки памяти.
Оказалось, что GCE устанавливает и запускает Stackdriver Logging Agent параллельно с моим контейнером. Согласно журналу oom-killer, родственный Рубин процесс потребляет кучу оперативной памяти. После перезагрузки он использует 50 МБ ОЗУ и за несколько часов наращивает до 300 МБ. На мой взгляд, это утечка памяти.
Чтобы было ясно: сервер ES не получает никакой нагрузки, просто периодическая проверка работоспособности делает запросы примерно каждые 5 минут. В результате нет большого количества логов, только несколько строк в час. Целый год журналов не займет 300 МБ хранилища или памяти.
Я попытался исследовать объем памяти, используя пс и верхняя команды, но результаты были совершенно неправдоподобными. Согласно системе, Рубин задача использует 1–10 ГБ физической памяти (RSS) и до 70 ГБ виртуальной памяти (VSZ). (Замена памяти отключена в соответствии с свободно команды.) Эти цифры не могут быть правдой, поскольку виртуальная машина не имеет такого количества ОЗУ.
Пытался обновить ОС до более свежей версии (cos-81-12871-119-0). Это определенно помогло, поскольку ES работал без проблем более 5 дней. Но Рубин потребление памяти процессом вызывает беспокойство. Согласно пс и верхняя команд, он использует 70–300 МБ физической памяти (RSS) и до 7 ГБ виртуальной памяти (VSZ).
Я обнаружил, что Рубин процесс является частью свободно инструмент, у которого была аналогичная проблема с памятью согласно их GitHub. Поскольку конфигурация и установка выполняются автоматически GCE, я не нашел способа изменить его настройки.
Самым простым решением было бы отключить установку агента ведения журнала, изменив метаданные виртуальной машины. (google-logging-enabled = false). Но я хотел бы выяснить причину, по которой это происходит, и как я могу это решить.
Мне действительно любопытно, была ли у кого-нибудь подобная проблема и каково было ее решение.
Образ Docker для агента ведения журнала Stackdriver: gcr.io/stackdriver-agents/stackdriver-logging-agent:0.2-1.5.33-1-1
Ошибка может быть воспроизведена. У меня есть среда разработки и производственная среда в отдельных проектах GCP. Ошибка возникла на обоих примерно одновременно. (~ 2020. 28 мая.) В соответствии с этим, я думаю, что это вызвано изменением в Stackdriver, но я не нашел никаких доказательств в журналах. (Оба экземпляра VM находятся в регионе eu-west3, в зоне c.)
Буду признателен за любую помощь или совет. Спасибо!