LINUX.ORG.RU

Подвисает система Linux

 ,


1

3

Столкнулись с проблемой, что периодически подвисает система Linux.

Есть программа, довольно сложный продукт, которая для своей работы создает порядка 260 «тредов». Во время работы данного софта обнаружили, что он периодически подвисает 3-5 секунд. За 10 минут работы, таких подвисаний может быть 6-8.

Первые предположения были, что подглючивает сама софтина и решили уронить ее в дамп во время подвисания, ну и соответственно далее изучить дамп и все такое... Сделали тулзовину, которая 2 раза в секунду опрашивает данную софтину и если она не отвечает в течении 2 секунд, раняет ее в дамп. Оказалась, что во время подвисания, виснит и сама тестовая тулзовина. Назначали ей RealTime приоритет (политика: SCHED_FIFO, приоритет 50), т.е. приоритет выше чем у внутренних потоков ядра. И все равно тулзовина во время этих 3-5 секундных подвисаний не получает время для работы.

Виснит полностью вся система. Складывается впечатление, что scheduler вообще никому не дает CPU для работы...

Залогировали список системных вызовов которые делает исследуемый софт:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
97.48 56418.270831         117   4993295    147009 futex
  0.77  445.035345    23422913        19        19 rt_sigsuspend
  0.76  439.691892         665    661688           select
 0.43  247.266351       62710      3943           recvfrom
  0.42  243.651252       45466      5359           recv
  0.04   22.876741        8295      2758        15 ioctl
  0.04   20.691496       32432       638           fsync
  0.02   14.450080      578003        25        25 rt_sigreturn
  0.02   11.988313           4   2950716           gettimeofday
  0.01    4.325112          21    201386           clock_gettime
  0.00    2.811146           4    680297           read
  0.00    2.694780          42     64393           write
  0.00    0.409938       14641        28           creat
  0.00    0.358971       16317        22           statfs
  0.00    0.305992          78      3943           sendto
  0.00    0.126784          23      5411           send
  0.00    0.121982      121982         1           mlockall
  0.00    0.061515           1     55759       154 open
  0.00    0.043443           1     55633           close
  0.00    0.030690          55       558           mmap2
  0.00    0.030086         971        31           unlink
...
видно, что львиное время работы уходит на вызов 'futex'.

Может кто сталкивался с подобной проблемой? Поскажите, куда следует начинать копать?

p.s. kernel: vanilla linux-2.6.33.7 + patch-2.6.33.7-rt29


система Linux
подвисает система Linux
программа, довольно сложный продукт
продукт, которая для своей работы создает порядка 260 «тредов»

Тести на 128-ядерном проце.
А потом на винфак, они-то знают чего делать.

amorpher ★★★★★
()

не слушай местных троллей :)

у меня такое предложение - если подозрения на ядро Linux, то попробуйте собрать самое распоследнее ядро

просто тупо берите Linux 3.8.3 с kernel.org без патчей, соберите его и запустите программу с таким новым ядром

я бы пробовал менять условия эксперимента, для начала ядро

I-Love-Microsoft ★★★★★
()

ну эта. таймер тиклесс или статический? ну и увеличить частоту поболее 1к никто не запрещает 😉

darkenshvein ★★★★★
()

купи или попроси лицензию на simics и посмотри что творится))

dimon555 ★★★★★
()

p.s. qemu тоже может сгодится и даже виртуалбокс плюс дебаггер конечно

dimon555 ★★★★★
()

Да, на счёт «программистов» — передай, что заеду и они там больше программировать не будутю(тчк)

amorpher ★★★★★
()

многообещающее название.

anonymous
()
Ответ на: комментарий от darkenshvein

я предлагаю проверить без rt-патчей чтобы сузить зону поиска проблемы

I-Love-Microsoft ★★★★★
()

Поскажите, куда следует начинать копать?

man limits.conf

как вариант

anonymous
()
Ответ на: комментарий от I-Love-Microsoft

просто тупо берите Linux 3.8.3 с kernel.org без патчей, соберите его и запустите программу с таким новым ядром

Тут не все так просто, дело в том что в текущем ядре пропатчены несколько драйверов, точнее 4 драйвера. Добавлено ряд фич (новые режимы, новые ioctl, и все такое...) для поддержки собственных железок, которые активно использует софтина. И переход на новое ядро потянет за собой перенос этих патчей, а это не так быстро...

Сейчас остановились на следующем, по максимуму собрать всю информацию о работе системы из user-space, это: 1) для тредов и процесса контейнера: utime, stime, cutime, cstime и т.п. 2) для системы в целом '/proc/stat': cpu, context switcher и т.п. и проанализировать эти данные. Может во время подвисаний там будет что то интересное от чего можно будет уже отталкиваться.

ну эта. таймер тиклесс или статический? ну и увеличить частоту поболее 1к никто не запрещает

что такое 'таймер тиклесс'? Если это 'CONFIG_HZ', то он настроен на 1000 Hz.

p.s. qemu тоже может сгодится и даже виртуалбокс плюс дебаггер конечно

Хм..., как из VirtualBox-a можно задебажить работу ядра?

Ser01x
() автор топика
Ответ на: комментарий от Ser01x

Хм..., как из VirtualBox-a можно задебажить работу ядра?

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

Если очень нужно, думаю можно найти всю информацию и примеры как что делать, разобраться...

Есть еще возможность по сети делать отладку ядра, тоже полно мануалов. Можно на виртуальной если воспроизводится, можно на реальной - как по serial-кабелю так и по сети.

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

Изобразить виртуальный последовательный порт для виртуальной машины

там должен быть built-in vm debugger или ещё какая возможность внешнего дебага, в этом как бы и смысл, чтобы операционная система не видела дебаггер, так-то проще второй комп подключить и дебажить первый.

dimon555 ★★★★★
()
Ответ на: комментарий от dimon555

Ну, ТС найдет всё что надо в мануалах, и kernel debugging и прочие вещи.

I-Love-Microsoft ★★★★★
()

только вот автору придётся пару виртуальных устройств разработать под которые писаны дополнительные драйверы, кстати, это, возможно, источник проблем.

впрочем, если это pci устройства, то он может попробовать pci-passthrou

dimon555 ★★★★★
()
Последнее исправление: dimon555 (всего исправлений: 1)

Может система в своп залезла? :)

true_admin ★★★★★
()
Ответ на: комментарий от Ser01x

дело в том что в текущем ядре пропатчены несколько драйверов, точнее 4 драйвера. Добавлено ряд фич (новые режимы, новые ioctl, и все такое...)

А виновато конечно же ядро, несомненно.

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

А виновато конечно же ядро, несомненно.

В чем смысл подобных комментариев?

Поясню что автор темы ищет ошибку у себя, и пытается найти участки кода, которые приводят к проблеме. Если его же драйверы приводят к фризам внутри ядра, то это проблема внутри ядра но вызвана ошибками в ЕГО драйвере.

Воздержитесь от трактовок школьного уровня.

Добавил в игнорлист.

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от ttnl

Вряд ли, при throttling-е ведь все равно будут процессы работать и получать время на исполнение...

Пусть проверит на другом железе...

I-Love-Microsoft ★★★★★
()

Виснит полностью вся система.

Судя по патчу -rt, этот ваш «довольно сложный продукт» - какая-то программа реального времени. В таком случае это не система виснет, а «довольно сложный продукт».

Складывается впечатление, что scheduler вообще никому не дает CPU для работы...

При работе программ реального времени это штатное поведение.

tailgunner ★★★★★
()
Ответ на: комментарий от pulo

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Вряд ли, при throttling-е ведь все равно будут процессы работать и получать время на исполнение...

Будут не только работать, но и подвисать по истечению своего rt_runtime

ttnl ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Никак. Единожды об этом оповещают через сообщение о throttling.

ttnl ★★★★★
()
Ответ на: комментарий от ttnl

В dmesg, конечно же, есть сообщения о throttling, угадал?

Да, есть такое. Надо бы попробовать отключить его.

Первая версия софта была написана еще под DOS и при переносе ее под Linux, для совместного доступа к общим ресурсам треды использовали следующий алгоритм: Повышали свой RealTime приоритет до максимума, работали с общими ресурсами, после чего обратно понижали свой приоритет. В принципе такая схема работала нормально на одноядерных CPU.

При переходе на ядро 2.6.33.7 софтина стала падать время от времени. Получалось, что тред пытался получить максимальный RT-приоритет, но обнаруживал что кто то уже работает с таким приоритетом и соответственно ронял весь процесс в корку.

Стали разбираться почему тред с максимальным приоритетом вытесняется. Оказалось, что при пиковых нагрузках включался тротлинг ‘sched: RT throttling activated’ и MAX-RT поток вытеснялся, ну и все падало... Проблему решили отключением тротлинга ‘echo -1 > /proc/sys/kernel/sched_rt_period_us’, после этого MAX-RT тред уже не вытиснялся. И все работало нормально.

Будут не только работать, но и подвисать по истечению своего rt_runtime

Я как понял, если RT процесс или тред начинает слишком долго занимать CPU, то включается тротлинг (т.е. алгоритм так называемого мягкого планирование). Этот алгоритм принудительно выгружает долговыполняющейся RT процесс, и отдает CPU голодающим процессам/тредам. Но при этом система то не должна подвисать? Или может я чего не понимаю...

Ser01x
() автор топика
Ответ на: комментарий от Ser01x

Повышали свой RealTime приоритет до максимума

Неудивительно, что тулзовина с «политика: SCHED_FIFO, приоритет 50» не получала времени для работы.

tailgunner ★★★★★
()
Ответ на: комментарий от Ser01x

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

Если не секрет, что за софт и что он делает?

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от tailgunner

Неудивительно, что тулзовина с «политика: SCHED_FIFO, приоритет 50» не получала времени для работы.

Блин, не тупи. Это я написал про первую версию. В текущей версии все переделали и разгроничили общие ресурсы с помощью mutex-ов. Смотри первый пост таблицу syscall-ов...

Ser01x
() автор топика
Ответ на: комментарий от Ser01x

Блин, не тупи.

Туплю не я.

В текущей версии все переделали

В какой из текущих версий? Напомню:

Ser01x> Проблему решили отключением тротлинга ‘echo -1 > /proc/sys/kernel/sched_rt_period_us’, после этого MAX-RT тред уже не вытиснялся

Что такое MAX-RT?

В текущей версии все переделали и разгроничили общие ресурсы с помощью mutex-ов.

Даже сейчас ты не сказал, с каким приоритетом выполняются задачи РВ внутри вашего софта.

tailgunner ★★★★★
()
Ответ на: комментарий от Ser01x

Проблему решили отключением тротлинга ‘echo -1 > /proc/sys/kernel/sched_rt_period_us’, после этого MAX-RT тред уже не вытиснялся.

Сомневаюсь, что это отключило trottling. Скорее, наоборот, запретило RT. Реально надо выключать так:

cat /proc/sys/kernel/sched_rt_period_us > /proc/sys/kernel/sched_rt_runtime_us

Но при этом система то не должна подвисать?

Если fair задачи не получают процессы, в этом ничего страшного до тех пор, пока среди них нет ядерных, от которых твоя задача косвенно получает ресурсы. Тебе надо понять, есть ли такие или нет.

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