Linux Большой softirq при приличной сетевой нагрузке.

> А если все же там то хочется понять как разнести разбор очереди по 
> разным процессорам

это происходит автоматически

> 193: 22 131508 0 1893886 IO-APIC-level eth0 

все CPU задействованы в большей или меньшей степени

> По мониторингу я так понимаю что очередь пакетов разбарается 1 процессором(softriq) что наверно не очень хорошо, но c другой стороны на этом процессоре еще %idle 17,82 получается, и возмножно затык не в этом. А если все же там то хочется понять как разнести разбор очереди по разным процессорам, если такое возможно. В общем складывается такое впечатление что можно что-то поднакрутить, без жеских патчей в ядре.

Неправильно. Обработчик irq при определённых обстоятельствах может мигрировать с cpu на cpu, но выполняться параллельно на нескольких - никогда.

Обработка прерываний - довольно дорогостоящая операция, поэтому во freebsd (по-моему) можно включить режим программного poll'инга, что снижает нагрузку на проц.

> На нагрузочной машине показывает ~15085.8 fetches/sec > На nginx 2.6.18-53.1.19.el5_PAE ядро. 2x"Intel(R) Xeon(TM) CPU 3.06GHz", Intel e1000-NAPI > P.P.S.Еще заметил на 2.6.25 ядре обрабатывается в 2 раза меньше запросов.

Последние ванильные ядра вообще опасно ставить на сервера, куча регрессий. Вместо этого лучше обновись до 5.2 (5.1.z всё равно после выхода 5.2 закрыли), там для e1000 много обновлений из апстрима. И поставь 64-битную систему, оно работает, в целом, шустрее 32-битной за счёт дополнительных регистров, адресации относительно RIP, более быстрого call'а и много чего ещё. Плюс расширение PAE хоть и даёт адресовать больше памяти, но существенно замедляет работу с ней из-за переключения банков.

> И поставь 64-битную систему, оно работает, в целом, шустрее 32-битной Я бы рад поставить, но есть еще самописный софт который там не работает. > Плюс расширение PAE хоть и даёт адресовать больше памяти, но существенно замедляет работу с ней из-за переключения банков. Точно не знаю как происходит переключение банков но на первый взгляд памяти занато немного.

> это происходит автоматически Или как в моем случае не происходит? :-) Как уже выше говорил система без диска может работать быстрее - это скоорее всего говорит что в железе _нет_ узких мест, и автоматика получается работает неочень, в моем случае.

> все CPU задействованы в большей или меньшей степени Если смотреть чем нибуть наподобе watch -n 1 'cat /proc/interrupts' то видно что тикает только один процессор по сетке.

> Если смотреть чем нибуть наподобе watch -n 1 'cat /proc/interrupts' то > видно что тикает только один процессор.

снимок /proc/interrupts утверждает, что 3 ;)

осуществить равномерную диспетчеризацию прерываний на все CPU невозможно (т. к состояние IF для конкретного CPU недетерминировано)

Там еще тасклеты есть которые вроде как на нескольких процессорах одновременно работать могут. Хотя пишут что на нагрузках лучьше использовать _простые_ softirq.

>Значение TASKLET_STATE_SCHED указывает на то, что тасклет запланирован >на выполнение, а значение TASLET_STATE_RUN — что тасклет выполняется. >Для оптимизации значение TASLET_STATE RUN может использоваться только >на многопроцессорной машине, так как на однопроцессорной машине и без >этого точно известно, выполняется ли тасклет (действительно, ведь код, >который выполняется, либо принадлежит тасклету, либо нет).

> которые вроде как на нескольких процессорах одновременно работать 
> могут

экземпляр тасклета не может выполняться параллельно на более чем одном CPU

> Два различных тасклета могут выполняться параллельно на разных процессорах, но при этом два тасклета одного типа не могут выполняться одновременно.

Эхх, а как бы было хорошо... :-) Спасибо всем кто откликнулся!

Можно наверно немного прибавить производительности оставив taskset'ом загруженный процессор _только_ на обработку этой задачи. Но выигрыш там не очень большой похоже будет.

В общем удалось накрутить прирост еще +20%, а с отключеными логами получается ~+65%. Не плохо :-)

а чтой-то у тебя nginx от рута работает? И скока чайлдов ты поставил? Надо не менее чем по одному на проц и потом увеличивать пока не получится пик быстродействия.