Самопроизвольный Logout при стресс тесте

Посмотрите системные логи - там должна быть соответствующая «ругань». Это в папке /var/log. В первую очередь гляньте daemon.log и syslog. Ну и можно глянуть auth.log и messages.

Да, смотрел. Написано что сервисы перезапускаются... Но как это отменить. А те сервисы которые перезапускаются, я пытался перезапустить в ручную, надеясь на то что при перезапуске того сервиса, произойдёт подобный эффект, но все сервисы которые промелькнули в логе, которые я перезапустил, эффекта этого не дали.

Вот лог Apr 17 21:54:20 srvlex systemd[1]: systemd-journald.service: Main process exited, code=killed, status=9/KILL Apr 17 21:54:20 srvlex systemd[1]: systemd-journald.service: Unit entered failed state. Apr 17 21:54:20 srvlex systemd[1]: Starting Flush Journal to Persistent Storage... Apr 17 21:54:20 srvlex systemd[1]: Started Flush Journal to Persistent Storage. Apr 17 21:54:20 srvlex systemd[1]: systemd-logind.service: Service hold-off time over, scheduling restart. Apr 17 21:54:20 srvlex systemd[1]: Stopped Login Service. Apr 17 21:54:20 srvlex systemd[1]: Starting Login Service... Apr 17 21:54:24 srvlex systemd[1]: dbus.service: Main process exited, code=killed, status=9/KILL Apr 17 21:54:24 srvlex systemd[1]: dbus.service: Unit entered failed state. Apr 17 21:54:24 srvlex systemd[1]: dbus.service: Failed with result 'signal'. Apr 17 21:54:24 srvlex systemd[1]: systemd-timesyncd.service: Main process exited, code=killed, status=9/KILL Apr 17 21:54:24 srvlex systemd[1]: systemd-timesyncd.service: Unit entered failed state. Apr 17 21:54:24 srvlex systemd[1]: systemd-timesyncd.service: Failed with result 'signal'. Apr 17 21:54:24 srvlex systemd[1]: systemd-udevd.service: Main process exited, code=killed, status=9/KILL Apr 17 21:54:24 srvlex systemd[1]: systemd-udevd.service: Unit entered failed state. Apr 17 21:54:24 srvlex systemd[1]: systemd-udevd.service: Failed with result 'signal'. Apr 17 21:54:24 srvlex systemd[1]: systemd-timesyncd.service: Service has no hold-off time, scheduling restart. Apr 17 21:54:24 srvlex systemd[1]: Started D-Bus System Message Bus. Apr 17 21:54:24 srvlex systemd[1]: Failed to subscribe to NameOwnerChanged signal for 'org.freedesktop.login1': Device or resource busy Apr 17 21:54:24 srvlex systemd[1]: Stopped Network Time Synchronization. Apr 17 21:54:24 srvlex systemd[1]: Starting Network Time Synchronization... Apr 17 21:54:24 srvlex systemd[1]: Starting User Manager for UID 0... Apr 17 21:54:24 srvlex systemd[1]: Started Login Service. Apr 17 21:54:24 srvlex systemd[12497]: Reached target Paths. Apr 17 21:54:24 srvlex systemd[12497]: Listening on GnuPG cryptographic agent and passphrase cache (restricted). Apr 17 21:54:24 srvlex systemd[12497]: Reached target Timers. Apr 17 21:54:24 srvlex systemd[12497]: Listening on GnuPG cryptographic agent and passphrase cache. Apr 17 21:54:24 srvlex systemd[12497]: Listening on GnuPG cryptographic agent (ssh-agent emulation). Apr 17 21:54:24 srvlex systemd[12497]: Listening on GnuPG cryptographic agent (access for web browsers). Apr 17 21:54:24 srvlex systemd[12497]: Reached target Sockets. Apr 17 21:54:24 srvlex systemd[12497]: Reached target Basic System. Apr 17 21:54:24 srvlex systemd[12497]: Reached target Default. Apr 17 21:54:24 srvlex systemd[12497]: Startup finished in 7ms. Apr 17 21:54:24 srvlex systemd[1]: Started User Manager for UID 0. Apr 17 21:54:24 srvlex systemd[1]: Stopping User Manager for UID 0... Apr 17 21:54:24 srvlex systemd[12497]: Stopped target Default. Apr 17 21:54:24 srvlex systemd[12497]: Stopped target Basic System. Apr 17 21:54:24 srvlex systemd[12497]: Stopped target Sockets. Apr 17 21:54:24 srvlex systemd[12497]: Closed GnuPG cryptographic agent (access for web browsers). Apr 17 21:54:24 srvlex systemd[12497]: Closed GnuPG cryptographic agent (ssh-agent emulation). Apr 17 21:54:24 srvlex systemd[12497]: Stopped target Timers. Apr 17 21:54:24 srvlex systemd[12497]: Stopped target Paths. Apr 17 21:54:24 srvlex systemd[12497]: Closed GnuPG cryptographic agent and passphrase cache (restricted). Apr 17 21:54:24 srvlex systemd[12497]: Closed GnuPG cryptographic agent and passphrase cache. Apr 17 21:54:24 srvlex systemd[12497]: Reached target Shutdown. Apr 17 21:54:24 srvlex systemd[12497]: Starting Exit the Session... Apr 17 21:54:24 srvlex systemd[12497]: Received SIGRTMIN+24 from PID 12501 (kill). Apr 17 21:54:24 srvlex systemd[1]: Stopped User Manager for UID 0. Apr 17 21:54:24 srvlex systemd[1]: Removed slice User Slice of root. Apr 17 21:54:24 srvlex systemd[1]: Started Network Time Synchronization. Apr 17 21:54:29 srvlex systemd[1]: systemd-udevd.service: Service hold-off time over, scheduling restart. Apr 17 21:54:29 srvlex systemd[1]: Stopped udev Kernel Device Manager. Apr 17 21:54:29 srvlex systemd[1]: Starting udev Kernel Device Manager... Apr 17 21:54:29 srvlex systemd[1]: Started udev Kernel Device Manager. Apr 17 21:56:20 srvlex systemd[1]: Created slice User Slice of root. Apr 17 21:56:20 srvlex systemd[1]: Starting User Manager for UID 0... Apr 17 21:56:20 srvlex systemd[1]: Started Session 9 of user root. Apr 17 21:56:20 srvlex systemd[12516]: Listening on GnuPG cryptographic agent (ssh-agent emulation). Apr 17 21:56:20 srvlex systemd[12516]: Listening on GnuPG cryptographic agent and passphrase cache. Apr 17 21:56:20 srvlex systemd[12516]: Listening on GnuPG cryptographic agent (access for web browsers). Apr 17 21:56:20 srvlex systemd[12516]: Reached target Paths. Apr 17 21:56:20 srvlex systemd[12516]: Reached target Timers. Apr 17 21:56:20 srvlex systemd[12516]: Listening on GnuPG cryptographic agent and passphrase cache (restricted). Apr 17 21:56:20 srvlex systemd[12516]: Reached target Sockets. Apr 17 21:56:20 srvlex systemd[12516]: Reached target Basic System. Apr 17 21:56:20 srvlex systemd[12516]: Reached target Default. Apr 17 21:56:20 srvlex systemd[12516]: Startup finished in 9ms. Apr 17 21:56:20 srvlex systemd[1]: Started User Manager for UID 0.

Если причина в тормозах работы сервисов, - что приводит к их перезагрузке, - то можно увеличить таймауты проверки активности сервисов в их настройках в папке /lib/systemd/system. К примеру, для systemd-journald.service можно побольше сделать параметр WatchdogSec.

Ну или уменьшить время стресс-теста.

А у какого сервиса надо изменить данный параметр? Можно ли вообще отключить Watchdog?

Ну, совсем отключать не надо - увеличить можно. Какой сервис подконфигурить - это зависит от того, с чего всё рушиться начинает. Приведенный фрагмент лога ни о чем особо не говорит кроме того, что происходит перезагрузка.

На самом деле причина ведь может быть совсем в другом. Я бы начал с того, что начал уменьшать время стресс тестирования и выяснил, на каком интервале все начинает грохаться. Ну и стресс-тест лучше запускать через обычную консоль.

Вообще пугает не то что Logout происходит, а то что я не могу понять почему он происходит и как это предотвратить. Сейчас сервера стоят дома, но когда они будут в датацентре и активно использоваться, я уже так спокойно не покопаюсь. Да и боюсь что в ответственный момент они будут так чудить и перезапускать сервисы когда будет нагрузка на БД

Я запускал с таким параметрами: stress-ng --class memory --sequential 12 --timeout 60s --metrics-brief

Количество ядер 12

... systemd-конфигурации всех сервисов (демонов), как я уже говорил, лежат в папке /lib/systemd/system - для каждого сервиса свой отдельный service-файл. Но менять параметры в этих файлах нужно осмысленно (если вообще в этом есть реальная необходимость). Так что, лучше сначала man-страницы почитать, относящиеся к systemd.

"... Да и боюсь что в ответственный момент они будут так чудить и перезапускать сервисы когда будет нагрузка на БД"

Debian - надёжная вещь. Если речь идет о сервере, то тестировать все нужно, естественно, без всяких десктопов. Ну и надо внимательно просмотреть /var/log/syslog и /var/log/daemon.log.

Что касается надежной работы БД, то тут очень важно иметь достаточный объем оперативной памяти и правильные БД-шные настройки - из расчета максимального количества параллельно обрабатываемых запросов.

... еще для высоконагруженных серверов может потребоваться ручная подстройка параметров в конфигурационных файлах: /etc/sysctl.conf /etc/security/limits.conf

а так... я запустил у себя на виртуальной машине вашу stress-ng команду - никаких проблем. Может дело в том, что у вас сервак достаточно мощный, и stress-ng выскакивает за какие-то дефолтные лимиты потребления системных ресурсов, что приводит к завершению сеанса работы пользователя.

Это может быть проявлением перегрева с соответствующим паником. Насколько одинаковы оба сервера по нагрузочной способности и вообще по железу? Убедитесь, что вы не стараетесь нагрузить что-то непосильное для конкретных экземпляров

man oom killer

Если грешить на oom-killer (кто-то же грохает сервисы - code=killed, status=9/KILL), то имеет смысл поискать строчки «Out of memory» и «Killed process» в /var/log/syslog и глянуть вывод в окрестности этих строчек. Ну и тогда нужно обратить внимание на размер и статистику использования swap-области.

Хотя в реальной жизни доводить сервер до такого стрессового состояния по памяти нельзя - нужно ручками конфигурить прикладные сервисы (СУБД и прочее) исходя из имеющейся оперативной памяти - лучше уж обламывать или тормозить внешние прикладные запросы к серверу, если нагрузка превышает его возможности.

Вы знаете, что самое интересное, но в Syslog таких строк нет, но при стресс тесте данные строки выводится и убиваются процессы stress-ng. Пишет Out of memory

У меня вот возникает вопрос, по какой причине вообще может возникать Out of memory? Ведь stress-ng тестирует память и он не должен брать больше чем есть. И как этого избежать? Что у меня не так?

И в любом случае спасибо всем кто принял участие. Может мы не решим конкретно данную проблему, но вы мне помогли больше понять что происходит за кулисами.

Как посмотреть на размер и статистику swap области? И какой размер должен быть?

Чтобы понадежнее просканировать логи на предмет убиения процессов, можно выполнить в консоли:

cd /var/log

grep -i kill *

Мониторить использование swap можно с помощью утилиты sar (статистика накапливается в текстовых файлах) или просто запустив на время теста в отдельном консольном окошке утилиту top. Можно еще vmstat покрутить. Текущее использование swap можно посмотреть с помощью free.

Что касается размера swap-а, то это зависит от конкретного использования компа. Поскольку у вас собственный сервер, который будет постоянно крутиться в дата-центре (гибернация не предполагается и за дисковое пространство вы, вроде как, не платите), то при выборе размера swap-а можно исходить из следующих соображений:

1) В обычном штатном режиме работы сервера грамотные настройки прикладных сервисов и ядра Linux не должны допускать интенсивного своппинга — в swap в основном могут выбрасываться какие-то реально не используемые фрагменты памяти (может набежать мегов 200).

2) Реальное задействование swap-а может возникнуть из-за каких-то утечек памяти, из-за ошибок и недоработок в настройке и администрировании сервера, а также при выполнении каких-то достаточно редких, эпизодических работ и заданий, которые могут затребовать существенный объем оперативной памяти.

Сответственно, размер swap-раздела определяется исходя из потребностей, относящихся к пункту 2). На вскидку — гига 2-3. Можно чуть больше для перестраховки, если не жалко. Более точно это зависит от того, чего вам может приспичить запустить на сервере.

Но это моя субъективная точка зрения. На эту тему еще погуглите самостоятельно. Начните, к примеру:

https://habrahabr.ru/company/flant/blog/348324/

https://help.ubuntu.com/community/SwapFaq

Кроме того, при выполнении стресс-тестирования вы можете поиграться с параметрами ядра, относящимися к использованию swap, oom-killer и файловому кэшу (vm.swappiness и пр.).

Ради любопытства попробовал у себя «замордовать» Linux — довести до вызова OOM-киллера. Получилось только при vm.swappiness=0 и запуске большого числа тестовых процессов — так, чтобы выйти за пределы доступной оперативной памяти. Вот тут действительно OOM-киллер стал убивать существенные сервисы (NGINX, PHP-FPM и пр.). При ненулевом значении vm.swappiness возникал только жуткий своппинг.

Собственно, именно такие ситуации и были зафиксированы в своё время на СУБД-шных серверах при переходе на более свежую версию ядра Linux, когда поменялась семантика нулевого значения vm.swappiness — неожиданно стали убиваться СУБД-шные процессы.

Не забывайте - у тс логаут. Довести систему до логаута - совсем не то, что до прибиения отдельных пузатых процессов.