Процесс Rebol 2 в Linux останавливается на SIGTERM после дня большой нагрузки

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

После нескольких дней работы, когда рабочий процесс Rebol должен завершиться, он начинает потреблять 100% ЦП и «ничего не делает». Я посмотрел на процесс с помощью strace, и когда он загружен 100 процессорами, он никак не вызывает ОС. Я посмотрел рабочий код Cheyenne (если там есть какая-то ошибка), и код выполняет команду Rebol exit. Эта команда делает цикл вечным. То же самое, если я попытаюсь убить процесс с помощью sigterm.

Затем я могу убить его с помощью sigkill. Процесс переходит в это состояние только после нескольких дней большой нагрузки, и мне не удалось воспроизвести его в непроизводственной среде или на локальном компьютере.

Мое наивное мнение состоит в том, что он зацикливается навсегда, пытаясь очистить память перед выходом или, может быть, открытые файлы/сокеты. Я просмотрел процессы до/после с помощью lsof (и подобных), но, поскольку событие нелегко воспроизвести, ничего не понял, да.

Мой вопрос: кто-нибудь видел, как Rebol2 переходит в вечный 100%-й цикл при выходе и при каких обстоятельствах? Кто-нибудь знает, как решить эту проблему?


person middayc    schedule 26.01.2017    source источник
comment
Боюсь, это будет бесполезный комментарий, но вот. Я также использую Cheyenne в Ubuntu 14.04 (если быть точным: 14.04.5 LTS (GNU/Linux 3.13.0-92- generic x86_64) и я никогда не видел этой проблемы. То же самое на Ubuntu 16.04 и Mac OSX 10.9. Следует отметить, что они никогда не подвергались сильной нагрузке, но работают долго (в некоторых случаях 6-9 месяцев без перезагрузки).   -  person draegtun    schedule 30.01.2017


Ответы (1)


Я видел это на наших производственных серверах Cheyenne, когда 100% процессор не отвечал, вероятно, после обслуживания очень длинного файла (много данных в ответе) ... Никогда не удавалось найти время для дополнительной диагностики этой проблемы, заканчивая записью монитор в ходу, который слишком долго убивает 100% процессорный процесс.

https://github.com/Softinnov/bearded-monitor

Вы можете использовать его в контейнере докеров

https://hub.docker.com/r/softinnov/bearded-monitor/< /а>

Надеюсь, поможет.

person Brahim Hamdouni    schedule 03.03.2017