Technologique
OOMd - user space daemon for killing processes by out of memory exception raises. И в дополнение к предыдущей статье, а также серии статей, опубликованных мной ещё в январе месяце, написанных во время активной фазы работ над оптимизацией датацентров, сервисов…
Daemonization for JVM
Есть ещё одна неприятная известная проблема с Java приложениями которая требует освещения.
На Java невозможно написать нормальное резидентное stateless приложение демона, коими являются любые сетевые демоны, обеспечивающие работу сетевых протоколов, да и вообще любые приложения относящиеся к server-side cloud infrastructure software.
То есть написать возможно, но чтобы сохранялось нормальное состояние работы и отказоустойчивость пориложения при его сбоях в run-time и/или перезагрузках системы - это сложно в реализации.
На скриптовых языках такое написать более возможно поэтому они широко используется как системные демоны для управления различными подсистемами в Linux (пример - OpenStack, комплексная система автоматизации управления облачными инфраструктурами) и используются в мультиконтейнерных приложениях и микро/нано сервисных серверных инфраструктурах для украшения ими.
На нативно статически компилируемых языках такие приложения писать возможно и более того - это единственный правильный корректный способ написания и реализации таких резидентных приложений.
В общем, стояла недавно такая задача...
Управлять стартом/рестартом Java приложений после их краха, убийства процесса приложения ядром при переполнении памяти (по out of memory exception) при помощи системы инициализации (Upstart в Ubuntu LTS, systemd на Debian) в Линуксе внутри контейнера или без контейнера в самой системе (для старых монолитных систем).
Сделать это непросто, т.к. Java машина, особенно если на ней исполняется сервер приложений с несколькими сервлет-контейнерами, имеет множество системных потоков (тред-пулов, spawned fork-join thread-pools) и может ответвлять отдельные процессы (fork-join process pools) для запуска сторонних приложений (например инициировать запуск sms демона для обслуживания SMS шлюза).
Состояние и PID (process id) процессов при этом отслеживать системой инициализации демонов в Linux очень сложно технически и не представляется возможным, т.к. система инициализации умеет отслеживать либо один форк процесса (expect fork stanza), либо двойной форк процесса (expect daemon stanza) при запуске и работе управления приложением, его автоматическим запуском и перезапуском, но не процесс пулы, где сложно отследить корневое приложение иницирующее ветвления, форки процессов в пуле.
Для этого приходится писать обёртки (wrappers), чаще на скриптовых языках или использовать готовые типа start-stop-daemon, для демонизации Java приложений и ортогонального управления ими.
Благо по системам инициализации есть прекрасная документация.
http://upstart.ubuntu.com/cookbook/#stanzas-by-category
http://upstart.ubuntu.com/cookbook/#initctl-commands-summary
http://upstart.ubuntu.com/cookbook/#expect
http://upstart.ubuntu.com/cookbook/#run-a-java-application
http://upstart.ubuntu.com/cookbook/#alternative-method
https://wiki.ubuntu.com/Upstart
https://www.freedesktop.org/software/systemd/man/systemd.exec.html
И пара классных статей от Digital Ocean по различиям систем инициализации и управления процессами в Linux системах.
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-2-reference
#Linux
#Ubuntu
#Upstart
#systemd
Есть ещё одна неприятная известная проблема с Java приложениями которая требует освещения.
На Java невозможно написать нормальное резидентное stateless приложение демона, коими являются любые сетевые демоны, обеспечивающие работу сетевых протоколов, да и вообще любые приложения относящиеся к server-side cloud infrastructure software.
То есть написать возможно, но чтобы сохранялось нормальное состояние работы и отказоустойчивость пориложения при его сбоях в run-time и/или перезагрузках системы - это сложно в реализации.
На скриптовых языках такое написать более возможно поэтому они широко используется как системные демоны для управления различными подсистемами в Linux (пример - OpenStack, комплексная система автоматизации управления облачными инфраструктурами) и используются в мультиконтейнерных приложениях и микро/нано сервисных серверных инфраструктурах для украшения ими.
На нативно статически компилируемых языках такие приложения писать возможно и более того - это единственный правильный корректный способ написания и реализации таких резидентных приложений.
В общем, стояла недавно такая задача...
Управлять стартом/рестартом Java приложений после их краха, убийства процесса приложения ядром при переполнении памяти (по out of memory exception) при помощи системы инициализации (Upstart в Ubuntu LTS, systemd на Debian) в Линуксе внутри контейнера или без контейнера в самой системе (для старых монолитных систем).
Сделать это непросто, т.к. Java машина, особенно если на ней исполняется сервер приложений с несколькими сервлет-контейнерами, имеет множество системных потоков (тред-пулов, spawned fork-join thread-pools) и может ответвлять отдельные процессы (fork-join process pools) для запуска сторонних приложений (например инициировать запуск sms демона для обслуживания SMS шлюза).
Состояние и PID (process id) процессов при этом отслеживать системой инициализации демонов в Linux очень сложно технически и не представляется возможным, т.к. система инициализации умеет отслеживать либо один форк процесса (expect fork stanza), либо двойной форк процесса (expect daemon stanza) при запуске и работе управления приложением, его автоматическим запуском и перезапуском, но не процесс пулы, где сложно отследить корневое приложение иницирующее ветвления, форки процессов в пуле.
Для этого приходится писать обёртки (wrappers), чаще на скриптовых языках или использовать готовые типа start-stop-daemon, для демонизации Java приложений и ортогонального управления ими.
Благо по системам инициализации есть прекрасная документация.
http://upstart.ubuntu.com/cookbook/#stanzas-by-category
http://upstart.ubuntu.com/cookbook/#initctl-commands-summary
http://upstart.ubuntu.com/cookbook/#expect
http://upstart.ubuntu.com/cookbook/#run-a-java-application
http://upstart.ubuntu.com/cookbook/#alternative-method
https://wiki.ubuntu.com/Upstart
https://www.freedesktop.org/software/systemd/man/systemd.exec.html
И пара классных статей от Digital Ocean по различиям систем инициализации и управления процессами в Linux системах.
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples
https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-2-reference
#Linux
#Ubuntu
#Upstart
#systemd