Вопрос или проблема
Я запускаю сервис в контейнере Docker на экземпляре t4g.nano (с 512 МБ ОЗУ). Мои сервисы обычно используют около 65% памяти, и, как правило, они работают нормально, однако время от времени я замечаю всплески использования памяти и процессора. Проверяя через journalctl, я вижу следующее:
23 сен 06:31:10 ip-xxxxx kernel: Состояние задач (значения памяти в страницах):
23 сен 06:31:10 ip-xxxxx kernel: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj имя
23 сен 06:31:10 ip-xxxxx kernel: [ 150] 0 150 12106 928 102400 0 -250 systemd-journal
23 сен 06:31:10 ip-xxxxx kernel: [ 190] 0 190 72415 6464 114688 0 -1000 multipathd
23 сен 06:31:10 ip-xxxxx kernel: [ 193] 0 193 2736 956 65536 0 -1000 systemd-udevd
23 сен 06:31:10 ip-xxxxx kernel: [ 351] 100 351 4102 832 81920 0 0 systemd-network
23 сен 06:31:10 ip-xxxxx kernel: [ 353] 101 353 6307 1616 94208 0 0 systemd-resolve
23 сен 06:31:10 ip-xxxxx kernel: [ 397] 0 397 557 384 40960 0 0 acpid
23 сен 06:31:10 ip-xxxxx kernel: [ 402] 0 402 1727 480 57344 0 0 cron
23 сен 06:31:10 ip-xxxxx kernel: [ 403] 102 403 2214 832 69632 0 -900 dbus-daemon
23 сен 06:31:10 ip-xxxxx kernel: [ 410] 0 410 20520 640 61440 0 0 irqbalance
23 сен 06:31:10 ip-xxxxx kernel: [ 411] 0 411 8238 2816 114688 0 0 networkd-dispat
23 сен 06:31:10 ip-xxxxx kernel: [ 413] 104 413 55505 992 90112 0 0 rsyslogd
23 сен 06:31:10 ip-xxxxx kernel: [ 414] 0 414 457784 2090 200704 0 0 amazon-ssm-agen
23 сен 06:31:10 ip-xxxxx kernel: [ 417] 0 417 348223 3230 262144 0 -900 snapd
23 сен 06:31:10 ip-xxxxx kernel: [ 418] 0 418 3889 800 77824 0 0 systemd-logind
23 сен 06:31:10 ip-xxxxx kernel: [ 448] 0 448 446710 3840 262144 0 -999 containerd
23 сен 06:31:10 ip-xxxxx kernel: [ 454] 0 454 1408 448 49152 0 0 agetty
23 сен 06:31:10 ip-xxxxx kernel: [ 457] 0 457 1397 352 49152 0 0 agetty
23 сен 06:31:10 ip-xxxxx kernel: [ 481] 115 481 5072 1426 73728 0 0 pgbouncer
23 сен 06:31:10 ip-xxxxx kernel: [ 567] 114 567 4654 579 61440 0 0 chronyd
23 сен 06:31:10 ip-xxxxx kernel: [ 585] 114 585 2557 427 61440 0 0 chronyd
23 сен 06:31:10 ip-xxxxx kernel: [ 636] 0 636 27483 2688 122880 0 0 unattended-upgr
23 сен 06:31:10 ip-xxxxx kernel: [ 676] 0 676 58833 1006 98304 0 0 polkitd
23 сен 06:31:10 ip-xxxxx kernel: [ 772] 0 772 489411 6641 348160 0 -500 dockerd
23 сен 06:31:10 ip-xxxxx kernel: [ 807] 0 807 3785 1024 73728 0 -1000 sshd
23 сен 06:31:10 ip-xxxxx kernel: [ 978] 0 978 309497 862 118784 0 -998 containerd-shim
23 сен 06:31:10 ip-xxxxx kernel: [ 998] 65534 998 308899 1608 122880 0 0 pgbouncer_expor
23 сен 06:31:10 ip-xxxxx kernel: [ 1753] 0 1753 74364 1408 176128 0 0 packagekitd
23 сен 06:31:10 ip-xxxxx kernel: [ 3689] 0 3689 576 352 45056 0 0 apt.systemd.dai
23 сен 06:31:10 ip-xxxxx kernel: [ 3693] 0 3693 576 352 45056 0 0 apt.systemd.dai
23 сен 06:31:10 ip-xxxxx kernel: [ 3721] 0 3721 85333 15613 458752 0 0 unattended-upgr
23 сен 06:31:10 ip-xxxxx kernel: [ 3913] 0 3913 102053 31125 479232 0 0 unattended-upgr
23 сен 06:31:10 ip-xxxxx kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=init.scope,mems_allowed=0,global_oom,task_memcg=/system.slice/apt-daily>
23 сен 06:31:10 ip-xxxxx kernel: Нет памяти: Процесс 3913 (unattended-upgr) убит, total-vm:408212kB, anon-rss:121788kB, file-rss:2712kB, shmem-rss:0kB, UID:0 p>
23 сен 06:31:10 ip-xxxxx systemd[1]: apt-daily-upgrade.service: Процесс этого юнита был убит OOM-убийцей.
23 сен 06:31:10 ip-xxxxx systemd[1]: apt-daily-upgrade.service: Главный процесс завершил работу, код=killed, статус=15/TERM
23 сен 06:31:10 ip-xxxxx systemd[1]: apt-daily-upgrade.service: Не удалось завершить с результатом 'oom-kill'
Это не всегда приводит к тому, что экземпляр перестает отвечать, но такое может случиться. Это также иногда может привести к завершению экземпляра и его замене (я использую группу автоматического масштабирования), что плохо для нашего сценария использования.
PS: Пожалуйста, не судите меня слишком строго, я относительно новичок в Linux и управлении серверами.
Ответ или решение
Проблема, с которой вы столкнулись, связана с исчерпанием памяти на вашем экземпляре EC2 (t4g.nano), что приводит к вызову механизма OOM (Out of Memory) и, в некоторых случаях, к аварийной остановке или замене экземпляра в Auto Scaling Group.
Причины проблемы
-
Недостаток ресурсов: t4g.nano имеет всего 512 МБ ОЗУ, что крайне ограничено для работы нескольких сервисов в контейнерах Docker, особенно если их использование памяти иногда достигает 65%. Ваша система может не справляться с пиковыми нагрузками.
-
Служба unattended-upgrades: Из вывода
journalctlвидно, что процессunattended-upgr(автоматические обновления) потребляет значительное количество памяти (up to 121788kB). Когда система сталкивается с нехваткой памяти, OOM Killer завершает этот процесс, чтобы попытаться освободить ресурсы. -
Автоматическое масштабирование: Поскольку ваш экземпляр находится в Auto Scaling Group, его автоматическое восстановление может быть связано с срабатыванием ограничений по ресурсам, что приводит к его замене.
Решения
1. Оптимизация использования ресурсов
- Проверьте контейнеры Docker: Убедитесь, что контейнеры ограничены в использовании памяти. Вы можете задать ограничения на использование памяти для контейнеров Docker, используя параметры
--memoryи--memory-swap. Например:docker run --memory=256m --memory-swap=256m your_image - Мониторинг пиков: Используйте инструменты мониторинга, чтобы отслеживать использование ресурсов в реальном времени и идентифицировать контейнеры или процессы, которые могут потреблять слишком много памяти.
2. Настройка службы автоматических обновлений
- Отключение unattended-upgrades: Если автоматическое обновление не критично для вашей среды, рассмотрите возможность его отключения:
sudo systemctl disable unattended-upgrades - Настройка графика обновлений: Если вы хотите оставить автоматические обновления, рассмотрите возможность настройки времени их выполнения на менее пиковые часы.
3. Увеличение ресурсов экземпляра
- Переход на более мощный экземпляр: Рассмотрите возможность использования экземпляра с большим объемом памяти, например, t4g.micro (1 ГБ ОЗУ) или более мощного экземпляра. Это обеспечит необходимый запас памяти для работы ваших приложений и устранит проблемы с исчерпанием памяти.
4. Настройка параметров Auto Scaling
- Конфигурация политики замещения: Если ваши задачи не требуют постоянных обновлений, вы можете настроить параметры Auto Scaling, чтобы уменьшить частоту замены экземпляров или увеличить время отклика на сбои.
5. Исследование документации и обучение
- Так как вы упомянули, что вы относительно новичок в управлении серверами, рекомендую изучить базовые концепции работы с Linux, Docker и AWS. Это поможет вам лучше понимать и управлять своей инфраструктурой.
Таким образом, подходя к этой проблеме комплексно, вы сможете стабилизировать работу вашего экземпляра EC2 и минимизировать риск непредвиденных остановок и замены экземпляров.