36 ответов в этой теме

[axelf]

Добрый день!

 

Меня зовут Алексей, являюсь лицензионным пользователем DrWeb.

 

Система - Ubuntu 16.04.01 LTS, десктоп. На ней работает DrWeb для Linux. 8 Гб ОЗУ, процессор - Core i3.

 

Проблема в следующем - периодически вылетает виртуальная машина. Как это связано с ДрВеб? Насколько я понял из нижеприведенного лога, машина вылетает по причине того, что заканчивается память и система завершает наиболее потребляющиее ее процессы. Симптомы - компьютер начинает крайне медленно работать перед этим. Причем, примерно за 5 минут до завершения процесса Vbox, ДрВеб начинает делать записи в лог. После вылета Vbox система завершает и процессы ДрВеб (в логе), получается что они также много памяти потребляют.

 

Вывод команды journalctl -p 0..3 -b 0 приложен в файле.

 

Вопрос в следующем - что это и как с этим бороться?

 

 

 

 

 

 

Прикрепленные файлы:

•  jornal.txt   4,78К   10 Скачано раз

[axelf]

Да, виртуалке выделено 1.6 Гб памяти.

[axelf]

В списке процессов в разное время висит от 4-х до 7-ми экземпяров drweb-se.real, потребляющих около 60 Мб каждый. Расход 300-400 Мб памяти слишком велик.

[dbanschikov]

В списке процессов в разное время висит от 4-х до 7-ми экземпяров drweb-se.real, потребляющих около 60 Мб каждый. Расход 300-400 Мб памяти слишком велик.

 

Добрый день.

 

По порядку:

 

ноя 27 14:21:38 AX drweb-se[1622]: Fork 7055: watchdog alarm

ноя 27 14:21:38 AX drweb-se[1622]: Fork 7033: watchdog alarm

ноя 27 14:21:38 AX drweb-se[1622]: Fork 7021: watchdog alarm

ноя 27 14:21:38 AX drweb-se[1622]: Fork 7023: watchdog alarm

ноя 27 14:21:38 AX drweb-se[1622]: Fork 7049: watchdog alarm

ноя 27 14:21:38 AX drweb-se[1622]: Fork 7047: watchdog alarm

ноя 27 14:21:38 AX drweb-se[1622]: Fork 7051: watchdog alarm

ноя 27 14:21:38 AX drweb-se[1622]: Fork 7053: watchdog alarm

 

 

 

Похоже есть проблема с зависанием движка.

Нужно попробовать установить параметр ScanEngine.MaxForksPerFile в 1(если его значение отличается от 1):

sudo drweb-ctl cfset ScanEngine.MaxForksPerFile 1

И понаблюдать за появлением ошибок.

Так же было бы очень здорово если бы у вас были core файлы процессов drweb-se.

Возможно, core файлы позволили бы ответить и на вопрос об чрезмерном потреблении памяти.

 

Что касается вопрос о периодически вылетаниях виртуалки - то нужно описать проблему как-то технически. Не понятно о чем идет речь.

[axelf]

Добрый день.  Спасибо за ответ!

 

Что вы написали попробую, core файл - не знаю что такое, погуглю.

 

Насчет виртуалки - проще говоря, виртуалка вылетает потому что память кончается. Ситсема сама начинает убивать ресурсоемкие процессы когда у нее заканчивается память. Раздел подкачки у меня всего 2 Гб.

 

Насчет памяти - на данный момент (до внесения изменений согласно вашим рекомендациям) творится вот такое - во вложении скриншот atop.  Висит порядка 7 процессов drweb-se, каждый из которых отъедает по 200 Мб, итого 1.5 Гб

Прикрепленные файлы:

•  Снимок экрана от 2016-11-28 11-24-03.png   552,97К   0 Скачано раз

[axelf]

Выполнил sudo drweb-ctl cfset ScanEngine.MaxForksPerFile 1. Ранее значение ScanEngine.MaxForksPerFile было равно 4.

Сообщение было изменено axelf: 28 Ноябрь 2016 - 12:00

[axelf]

Насколько я понял, core файлы - это по сути дампы процессов. Снял просто - с помощью gcore, процессы на паузу не ставил - хз, правильно или нет. Несколько разных, одновременно висящих, около 500 Мб.

https://cloud.mail.ru/public/GWHB/9tRQZEgTD

[dbanschikov]

Нене, просто coredump рабочего процесса не интересует.

Когда процесс завершается в результате получения сигнала(SIGSEGV, SIGBUS, SIGILL etc.) то может быть сгенерирована corefile для этого процесса.

Обычно по-умолчанию создание core-файлов выключено.

Нужно включить создание core файлов для процессов завершающихся по сигналу.

Обычно это делается правкой sysctl параметра kernel.core_pattern. В случае использования systemd - man systemd-coredump.

Далее, когда настроете запись core файлов, то для записей из лог файлов касательно срабатывания watchdog таймеров должны быть сгенерированы core-файлы.

Вот эти core файлы и интересуют.

 

Что касается потребления памяти - в действительности с виртуальной памяти все сложнее чем кажется.

Данные что atop, что ps, что top в качестве параметра rss показывают не совсем те что интересны и правдивы(ps -o rss,vsz).

Большая часть RSS памяти fork'ов сканирования drweb-se шарится между всеми форками.

Таким образом, совсем грубо говоря, нужно взять не средний RSS и умножить на количество fork'ов сканирования, а просто взять один RSS.

Более подробно детали можно поглядеть в /proc//smaps.

Например если смотреть на heap fork'ов:

 

ef205000-f1c00000 rwxp 00000000 00:00 0

Size:              42988 kB

Rss:               42988 kB

Pss:                2528 kB

Shared_Clean:          0 kB

Shared_Dirty:      42988 kB

Private_Clean:         0 kB

Private_Dirty:         0 kB

Referenced:         4928 kB

Anonymous:         42988 kB

AnonHugePages:     34816 kB

Shared_Hugetlb:        0 kB

Private_Hugetlb:       0 kB

Swap:                  0 kB

SwapPss:               0 kB

KernelPageSize:        4 kB

MMUPageSize:           4 kB

Locked:                0 kB

VmFlags: rd wr ex mr mw me ac sd

 

 

 

Видно что замапленный кусок памяти около 42МБ в действительности шариться между процессами(Shared Dirty) и правильный размер потребляемой памяти этим куском в пересчете на количество шарящих его процессов - около 2.5МБ.

 

Другими словами - процессы drweb-se потребляют значительно меньше памяти через среднее RSS по fork'ам сканирования умноженное на их количество.

 

Что же касается советов как можно повлиять на работу OOM-киллера:

 

1. Настроить приоритеты для OOM-киллера

2. Понизить количество сканирующих процессов drweb-se(изменить параметр ScanEngine.MaxForks, по-умолчанию значение 2 * hw.ncpu). Попробуйте поставить половину от текущего значения и понаблюдать.

Сообщение было изменено dbanschikov: 28 Ноябрь 2016 - 13:19

[axelf]

Параметр ScanEngine.MaxForksPerFile 1 на текущее потребление памяти не повлиял (делал перезагрузку), картина та же, что и на скриншоте выше.

[dbanschikov]

Параметр ScanEngine.MaxForksPerFile 1 на текущее потребление памяти не повлиял (делал перезагрузку), картина та же, что и на скриншоте выше.

 

Этот параметр должен повлиять не на потребление памяти, а на наличие/отсутствие ошибок watchdog alarm в логах.

Сообщение было изменено dbanschikov: 28 Ноябрь 2016 - 13:19

[GEV]

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

Прикольно, столкнулся на днях с похожей проблемой, но с firefox, его процесс выжрал всю память (8gb) и засвопил на диск, думал что в 50 версии что-то накосячили, а теперь я в сомнениях.... (16.04 LTS), drweb не установлен.

[Afalin]

Обычно это делается правкой sysctl параметра kernel.core_pattern. В случае использования systemd - man systemd-coredump.

Ну как, в core_pattern путь к коре, и он обычно вроде всё-таки не пустой, а "core". Что тоже неудобно, потому что cwd неизвестна в общем случае, как минимум. ulimit -c должен быть выставлен. Ещё встречалось, то ли на OpenVZ, то ли на чём-то подобном, уже не помню, вообще в ядре отломано было создание корок. Ну и CONFIG_COREDUMP может быть отключен, хотя на практике пока не попадалось. А, и ещё, если процесс suid'ный, есть же /proc/sys/fs/suid_dumpable и связаные с этим тонкости.

[axelf]

Попробовал настроить создание core файлов, но, как говорится, ай нид хелп

 

На просторах инета нагуглилось несколько статей, по ним сделал следующее (Убунта все та же, 16.04):

 

1. Выключил Apport. В файле /etc/default/apport значение enabled=1 заменил на 0.

2. В /etc/sysctl.conf дописал строчки:
kernel.core_pattern=/tmp/core-%e-%p-%s
fs.suid_dumpable = 2

3. Команду sudo sysctl --system (но это я так понимаю, чтобы не перезагружать, но и перезагрузку делал). Пробовал и sysctl -p.

4. Дописал в файл /etc/security/limits.conf   строчку * hard core unlimited.

5. После загрузки делаю sudo -s, потом ulimit -c unlimited.

 

Однако core файлы не создаются (виртуалка вылетала и процессы drweb-se).

Вопрос - что я делаю не так?

[amorozov]

Дополнительно сделайте следующее. Создайте директорию /etc/systemd/system/drweb-configd.service.d с файлом override.conf и пропишите в нём:

[Service]
LimitCORE=infinity

После этого:

sudo systemctl daemon-reload
sudo systemctl restart drweb-configd

[axelf]

amorozov, спасибо, сделал. Прав 644 (они по умолчанию) на этот файлик думаю достаточно?

 

Будем ждать падения процессов....

[dbanschikov]

Можно проверить правильно все сделали или нет - послать SIGABRT в сторону fork'а SE.

Если все правильно - должна появиться корка.

Сообщение было изменено dbanschikov: 02 Декабрь 2016 - 17:41

[axelf]

Можно проверить правильно все сделали или нет - послать SIGABRT в сторону fork'а SE.

Если все правильно - должна появиться корка.

 

Спасибо! Они сами немного напАдали, последняя рекомендация с override.conf помогла. Вот собственно https://cloud.mail.ru/public/FyCc/YcJiop5FK

 

Только я параметр с 1 вернул к 4 - чтобы падало чаще

Сообщение было изменено axelf: 03 Декабрь 2016 - 00:27

[dbanschikov]

Да, об этой проблеме известно, в ближайщем релизе она будет исправлена.

[axelf]

Спасибо за помощь! Но хотелось бы уточнить - это какая-то утечка памяти, что приводит к тому, что система съедает всю оперативу, или просто в условиях малых объемов памяти ДрВеб падает, то есть причиной потребления всех 8 Гб ОЗУ является ДрВеб, который поправят, или у меня что-то другое все съедает, а ДрВеб просто не выдерживает такого скромного пайка по ресурсам?

[dbanschikov]

Спасибо за помощь! Но хотелось бы уточнить - это какая-то утечка памяти, что приводит к тому, что система съедает всю оперативу, или просто в условиях малых объемов памяти ДрВеб падает, то есть причиной потребления всех 8 Гб ОЗУ является ДрВеб, который поправят, или у меня что-то другое все съедает, а ДрВеб просто не выдерживает такого скромного пайка по ресурсам?

 

 

Падения fork'ов сканирования никак не связаны с нехваткой ресурсов.

Что касается потребления памяти - то как я уже говорил, умножать RSS одного форка сканирования на количество форков сканирования некорректно - в действительности fork'ами сканирования, да и всем DrWeb, памяти потребляется значительно меньше.

 

Что касается нехватки памяти в виртуалке - давайте начнем сначала с того, что вы покажете логи работы OOM killer'а. Что-то вроде:

grep -E 'oom|total_vm' /var/log/kern.log

или куда у вас логи ядерные пишутся.