LINUX.ORG.RU

Чудеса - увеличение cpu-usage в kernel


0

0

Процесс для обработки запускает (fork + exec) массу различных обработчиков. Время жизни обработчика мало (запустился, сделал что попросили, exit).

Все данные (которые доступны обработчикам и результаты) живут в tmpfs. Запускается тест, который крутит тестовую коллекцию по кругу.

Наблюдаем за этим делом через sar -X pid. Видим, что после запуска дочерние процессы (обработчики) потребляют скажем 20% процессора в режим ядра и 80% в usermode. Смотрим на это дело через три-четыре часа - видим почти обратное соотношение, примерно 80% в режим ядра и 20% в usermode!!!

Состав данных точно не меняется, всё идет по кругу. Система RHEL 5.5 со всеми апдейтами. В обработчиках ничего «волшебного», можно сравнить с tar или unzip.

Аналогичная хрень видна и для родительского процесса (по sar -x pid). Очень не хочется заниматься проктологией через SystemTap...

Какие будут идеи?


Ответ на: комментарий от mv

Re: На другой системе пробовал?

Это стенд (нагрузка, сеть, PAE + RAM*GB, storage), поэтому сложновато найти «другую систему». С другой стороны, зачем дергаться не поняв в чем дело?

Перезапустил subj и понаблюдал еще час. Затраты в kernel-mode начинают понемногу расти с самого начала. При этом из основного процесса вроде-бы ничего не течет.

По-сути кроме открытия/закрытия файлов и сокетов, операций с ними и отображения в память ничего не происходит. Карта маппинга конечно меняется (в том числе из-за mmap/unmap из malloc/free), но какого-либо «разбухания» не видно.

Короче, основной процесс меняется (включая порождение и остановку потоков), но не видно (я не вижу) ничего такого что могло создавать проблемы для fork() и exec().

Все метрики примерно сохраняются, за исключением performace за счет просада в ядре.

:(

ly ()
Ответ на: комментарий от mv

Re: Похоже на memleak в ядре

Н-да, похоже :(

Видимо придется заняться sys-tap-ологией...

ly ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.