OOMd - user space daemon for killing processes by out of memory exception raises.
И в дополнение к предыдущей статье, а также серии статей, опубликованных мной ещё в январе месяце, написанных во время активной фазы работ над оптимизацией датацентров, сервисов и сети доставки контента.
Буквально на днях коллеги из группы Facebook Open Source Team опубликовали исходники демона oomd работающего в пространстве привилегий пользователя для завершения процессов при срабатывании исключения out of memory (OOM), при чрезмерном расходе памяти приложениями и сервисами.
https://code.fb.com/production-engineering/open-sourcing-oomd-a-new-approach-to-handling-ooms/
https://github.com/facebookincubator/oomd
Также для более раннего обнаружения (до срабатывания исключения OOM Killer в ядре) паразитических процессов и нагрузки создаваемой ими и чтобы не потерять контроль над уже нестабильной системой (а также для повышения стабильности и отзывчивости системы) в момент срабатывания OOM Killer механизма ядра, для включения в ядро был предложен механизм Pressure Stall Information — pressure metrics, метрики, подобные load average, по таймфреймам, для создания и определения модели нагрузки и определения livelocks состояний (взаимоблокировки процессов при попытке завладения доступом к ограниченным ресурсам) по подсистемам cpu, memory и io, и по отдельным процессам, как для отслеживания "качества жизни" отдельных процессов и их окружений cgroups, так и нагрузки по подсистемам ресурсов в целом — для предоставления информации ядру и для более раннего обнаружения процессов слишком активно требующих выделения ресурсов системы и потребляющих их:
https://lkml.org/lkml/2018/7/12/661
Данный механизм ядра совместно с демоном oomd позволяет более точно отслеживать состояние процессов и выделение ресурсов в системе, более точно локализовать проблемные места (bottle-necks) для дальнейшей оптимизации сервисов по потреблению ресурсов, а также повысить отзывчивость (время реакции, задержки, latency), стабильность и надёжность (fault tolerance) работы системы, особенно в условиях мультиконтейнерных stateless окружений микро и нано сервисов, повысить эффективность утилизации ресурсов кластерных систем и масштабируемость приложений при миграции процессов в пределах кластерной системы.
Следующий большой шаг, над которым ведётся работа - разработка и интеграция новых решений для систем инициации (systemd, а также upstart и sysVinit для более старых систем) по отслеживанию состояний потребления ресурсов процессами резидентных приложений (демонов), с высоким постоянным невыгружаемым пулом памяти (memory footprint).
Существующие механизмы в текущих системах инициализации в ОС GNU/Linux не дают необходимой гибкости управления процессами, особенно у условиях состояний ограниченных или исчерпывающихся ресурсов в системе.
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#OOMScoreAdjust=
http://upstart.ubuntu.com/cookbook/#oom-score
http://upstart.ubuntu.com/cookbook/#respawn
http://upstart.ubuntu.com/cookbook/#respawn-limit
Хочу выразить благодарность Артёму, автору канала @SysadminNotes, за публикацию данной информации (https://t.me/SysadminNotes/877) и за прекрасный и очень интересный канал (подписывайтесь, читайте - рекомендую! 😉)
PS: На самом деле очень приятно видеть, когда то, над чем работали для конторы уходит в open source - труды не пропадают даром и подобные проекты будут полезны всему сообществу. Жаль что не столь оперативно происходит открытие исходников подобных интересных проектов.
Материалы по теме:
https://t.me/technologique/1253
https://t.me/technologique/1254 - в данной статье я упоминал также про подобное уже существовавшее на тот момент решение проблемы ранней упреждающей обработки OOM исключений в user space, EarlyOOM (https://github.com/rfjakob/earlyoom)
https://t.me/technologique/1255
https://t.me/technologique/1256
https://t.me/technologique/1258
И в дополнение к предыдущей статье, а также серии статей, опубликованных мной ещё в январе месяце, написанных во время активной фазы работ над оптимизацией датацентров, сервисов и сети доставки контента.
Буквально на днях коллеги из группы Facebook Open Source Team опубликовали исходники демона oomd работающего в пространстве привилегий пользователя для завершения процессов при срабатывании исключения out of memory (OOM), при чрезмерном расходе памяти приложениями и сервисами.
https://code.fb.com/production-engineering/open-sourcing-oomd-a-new-approach-to-handling-ooms/
https://github.com/facebookincubator/oomd
Также для более раннего обнаружения (до срабатывания исключения OOM Killer в ядре) паразитических процессов и нагрузки создаваемой ими и чтобы не потерять контроль над уже нестабильной системой (а также для повышения стабильности и отзывчивости системы) в момент срабатывания OOM Killer механизма ядра, для включения в ядро был предложен механизм Pressure Stall Information — pressure metrics, метрики, подобные load average, по таймфреймам, для создания и определения модели нагрузки и определения livelocks состояний (взаимоблокировки процессов при попытке завладения доступом к ограниченным ресурсам) по подсистемам cpu, memory и io, и по отдельным процессам, как для отслеживания "качества жизни" отдельных процессов и их окружений cgroups, так и нагрузки по подсистемам ресурсов в целом — для предоставления информации ядру и для более раннего обнаружения процессов слишком активно требующих выделения ресурсов системы и потребляющих их:
https://lkml.org/lkml/2018/7/12/661
Данный механизм ядра совместно с демоном oomd позволяет более точно отслеживать состояние процессов и выделение ресурсов в системе, более точно локализовать проблемные места (bottle-necks) для дальнейшей оптимизации сервисов по потреблению ресурсов, а также повысить отзывчивость (время реакции, задержки, latency), стабильность и надёжность (fault tolerance) работы системы, особенно в условиях мультиконтейнерных stateless окружений микро и нано сервисов, повысить эффективность утилизации ресурсов кластерных систем и масштабируемость приложений при миграции процессов в пределах кластерной системы.
Следующий большой шаг, над которым ведётся работа - разработка и интеграция новых решений для систем инициации (systemd, а также upstart и sysVinit для более старых систем) по отслеживанию состояний потребления ресурсов процессами резидентных приложений (демонов), с высоким постоянным невыгружаемым пулом памяти (memory footprint).
Существующие механизмы в текущих системах инициализации в ОС GNU/Linux не дают необходимой гибкости управления процессами, особенно у условиях состояний ограниченных или исчерпывающихся ресурсов в системе.
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#OOMScoreAdjust=
http://upstart.ubuntu.com/cookbook/#oom-score
http://upstart.ubuntu.com/cookbook/#respawn
http://upstart.ubuntu.com/cookbook/#respawn-limit
Хочу выразить благодарность Артёму, автору канала @SysadminNotes, за публикацию данной информации (https://t.me/SysadminNotes/877) и за прекрасный и очень интересный канал (подписывайтесь, читайте - рекомендую! 😉)
PS: На самом деле очень приятно видеть, когда то, над чем работали для конторы уходит в open source - труды не пропадают даром и подобные проекты будут полезны всему сообществу. Жаль что не столь оперативно происходит открытие исходников подобных интересных проектов.
Материалы по теме:
https://t.me/technologique/1253
https://t.me/technologique/1254 - в данной статье я упоминал также про подобное уже существовавшее на тот момент решение проблемы ранней упреждающей обработки OOM исключений в user space, EarlyOOM (https://github.com/rfjakob/earlyoom)
https://t.me/technologique/1255
https://t.me/technologique/1256
https://t.me/technologique/1258