Перейти к содержимому
Калькуляторы

Всем доброе время суток.

 

Я прочел множество статей о kosftirqd, драйверах NAPI для e100, e1000, как они работают и много всякой другой теории об этих связках, но вы сами понимаете, что теория, это только теория.

 

Недавно наткнулся на тему про softrouter на FreeBSD ( тут же ) и увидел там, что хендлеры для rx/tx операций заводят как треды на разные процессоры, используя драйвера от Яндекс, таким образом выполняя, как бы sharing soft irq. Я попытался погуглить по данной теме что для Linux, но нашел только теорию. На практике есть какие-то самописные непроверенные патчи к 2.6 ядрам. Но как я понял эта штука называется Scaling I/O и по заявлению некоторых товарищей ( http://www.linux.org.ru/view-message.jsp?msgid=2182914 ) она уже давно применяется в Linux и якобы назвается sotirq-net-tx/rx.

 

При обычной загрузке машины - прерывания распределяются по процессорам примерно равномерно. Но при перегрузке от количества пакетов в top начинает выступать один ksoftirqd, который занимает только один процессор, ну и естественно, устраивает капец сетевому трафику, хотя другие процессоры занимаются user-level операциями и в принципе свободны.

 

Ситуация стандартная, но вопросы таковы:

1. Есть ли какие-то методы распределения софт прерываний на несколько процессоров, для их более быстрой обработки?

2. Можно ли как-то управлять поллингом для драйвера e1000? Потому как, судя по документации, поллинг начинает работать только, когда количество пакетов превышает количество возможных прерываний в системе

3. Можно ли как-то просматривать статистику драйвера? ( сколько пакетов в буфере сетевой карты, шедулятся ли пакеты на soft_irq, может еще что-то )

4. Можно ли как-то просмотреть что именно делает ksoftirq во время работы?

5. В каком ядре ( 2.4 / 2.6 ) по-вашему лучше реализована работа этого всего механизма?

 

Можно, так же ответить на вопрос, который, я думаю, заинтересует не только меня: это кто еще как решал вопрос при перегрузке сетевого интерфейса/интерфейсов от количества пакетов, но все же интересуют именно заданные выше вопросы.

 

Все заранее спасибо за ваши ответы.

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

>1. Есть ли какие-то методы распределения софт прерываний на несколько процессоров, для их более быстрой обработки?

 

сервер ксеон 4 ядра. линукс. 4 гигабитные сетевухи.

vmlinuz-2.6.26.5-e1000e

Все параметры ядра по умолчанию + e1000e драйвер.

 

Смотрите как равномерно распределены прерывания по ядрам:

 

cat /proc/interrupts | grep eth

1261: 1127602476 1127685973 1127530955 1127464435 PCI-MSI-edge eth3

1262: 1151096626 1151292994 1151015951 1151011638 PCI-MSI-edge eth2

1263: 1130046456 1129901596 1130186351 1130179831 PCI-MSI-edge eth1

1264: 1226653615 1226507124 1226663069 1226742880 PCI-MSI-edge eth0

 

>2. Можно ли как-то управлять поллингом для драйвера e1000? Потому как, судя по документации, поллинг начинает работать только, когда количество пакетов превышает количество возможных прерываний в системе

Если режим - авто - то нельзя. Иначе можно указать конкретное кол-во пакетов на каждое прерывание.

 

>3. Можно ли как-то просматривать статистику драйвера? ( сколько пакетов в буфере сетевой карты, шедулятся ли пакеты на soft_irq, может еще что-то )

Это незнаю.

 

>4. Можно ли как-то просмотреть что именно делает ksoftirq во время работы?

oprofile

 

>5. В каком ядре ( 2.4 / 2.6 ) по-вашему лучше реализована работа этого всего механизма?

А ,что в 2.4 она вообще есть ?

 

Изменено пользователем Ivan Rostovikov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2Ivan Rostovikov:

 

> 1. Смотрите как равномерно распределены прерывания по ядрам:

>> При обычной загрузке машины - прерывания распределяются по процессорам примерно равномерно.

 

Тут именно вопрос о распределении soft_irq

 

2. Я знаю, что можно задавать интевалы времени на которые откладываются прерывания, но чтобы пакеты. Откуда система будет знать сколько пакетов в буфере сетвой карты и что пора делать прерывание? Может Вы вспомните опцию которой можно задать это количество пакетов для драйвера?

 

3.

 

4. Спасибо, посмотрю.

 

5. Да, кажется с 2.4.19 появился NAPI.

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Однажды я довольно многовремени убил на поиски решения проблемы "большая загрузка от soft_irq". Тоже kosftirqd " грузил цпу.

Ядрокот обьяснил популярно, что kosftirqd это собственно само ядро, а именно все что происходит с пакетом между интерфейсами - это kosftirqd. Значит молищите проблему не только в драйвере и сетевухе но и в обработке пакета (роутинг, iptables, qdisc... и т.д.).

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

Помоим ощущениям, современные процессоры и шины, практически невозможно "перегрузить" обычными пакетами (обычным трафиком) на гигабитных интерфейсах. На 10Г - может быть. Так, что проблема скорее всего не в NAPI. И не в сетевухе вообще.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы все верно говорите. Вот только задайте себе вопрос: неужели нельзя обрабатывать всю эту лабуду "(роутинг, iptables, qdisc... и т.д.)." на нескольких процессорах? Это как бы основной вопрос.

 

Насчет перегрузки, я с Вами не соглашусь. Когда packet blasters начинают рисовать по 350-400 Kpps четырех процессорный ксеон немного "худеет", даже слегка прихудевает от этого. А это "всего" 200-250 Мбит трафика. И повесьте Вы даже 100 процессоров, всеравно при входе в soft irq - машина будет умирать, потому что их обрабатывает 1 процессор. Кстати, даже, если нет iptables, qdisc.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

>потому что их обрабатывает 1 процессор

 

pppoe4:~# top -b | grep ksoftirq

4 root 15 -5 0 0 0 S 0 0.0 0:53.30 ksoftirqd/0

7 root 15 -5 0 0 0 S 0 0.0 0:57.97 ksoftirqd/1

10 root 15 -5 0 0 0 S 0 0.0 0:59.63 ksoftirqd/2

13 root 15 -5 0 0 0 S 0 0.0 0:59.92 ksoftirqd/3

pppoe4:~# uptime

13:15:56 up 5 days, 22:56, 1 user, load average: 0.16, 0.07, 0.02

 

Трафик в среднем примерно 2Гб/с через всю машину.

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

Я сильно не присматривался но мне казалось видел и больше.400kpps точно было.Без проблем.

 

Т.е. я намекаю на то, что софт ирки тоже расходятся по ядрам.Так же как и хард ирки.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

всё правильно темный ангел говорит, 4 сетевые и все задействованы,

у меня четырёхядерник ксеон, но 2 сетевые, вот как прерывания распределены:

 

[root@billing ~]# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  0:      90806      21096  459586880    1619224    IO-APIC-edge  timer
  1:          4          1        156         24    IO-APIC-edge  i8042
  6:          1          0          1          0    IO-APIC-edge  floppy
  8:          2          0          1          0    IO-APIC-edge  rtc
  9:          0          0          0          0   IO-APIC-level  acpi
12:         33         32        125         32    IO-APIC-edge  i8042
209:     104937          0   68496895          0         PCI-MSI  ahci
225:       1842 3815866906       1843       1860   IO-APIC-level  eth0
233:      42623          0          0 3540210025         PCI-MSI  eth1
NMI:          0          0          0          0
LOC:  461083806  461083771  460995047  460994963
ERR:          0
MIS:          0
[root@billing ~]#

 

получается, что 2 ядра тупо простаивают, когда другие 2 вечером загружены по самое немогу

Изменено пользователем BETEPAH

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тут нужно смотреть на чип сетевого интерфейса, например 82571EB/82572EI устанавливаемые в частности в EXPI9400PT имеют по 2 независимых TX/RX очереди и поддерживают MSI-X, соответственно каждая очередь может быть посажена на отдельный CPU. В 82575EB 4 очереди, а в новых 82576EB которые используются в адаптерах ET-серии вообще 16 очередей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2Ivan Rostovikov: А можете сказать какие именно у Вас сетевые карты, потому что если у Вас 2 Гбита и 400 kpps валит и нагрузка на 4-х ядрах 0.1 - это более чем интересно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2DemYaN: А где об этом количестве очередей можно прочесть?

 

2Ivan Rostovikov: А какой чип на Интелах?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 DemYaN: ткните пожалуйста, где можно прочитать про очереди и как их настроить на разные ядра, потому что нашёл, что в моём чипе 82566DM тоже независимые очереди RX и TX, правда про второй чип 82541GI не нашёл инфу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Количество очередей можно глянуть тут:

http://www.intel.com/products/ethernet/ind...rnetcontrollers

 

Сейчас не вспомню какую именно работу читал, где описывается более подробно работа дескрипторов очередей, однако поверхностно можно глянуть тут:

http://www.intel.com/network/connectivity/...pers/318483.pdf

 

еще здесь немножко (хотя касается в большей мере DCA):

http://rethink.intel.com/Download/318677.pdf

 

о DCA с пристрастием:

http://www.stanford.edu/group/comparch/pap...uggahalli05.pdf

 

касательно поддержки IO/A и DCA в Linux:

http://downloadmirror.intel.com/10959/ENG/README.txt

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

При 2082М суммарного RX/TX трафика на двух гигабитных интерфейсах начинает подскакивать ksoftirqd/0-1

На машине ещё много всего крутится (tc u32 около 2,5тыс. пайпов в пиках, iptables-ipset, fprobe, биллинг, mysql и прочее)

Я так понимаю увеличением частоты процессоров вопрос не решить и подозреваю что спасает только установка дополнительных сетевых?

А может поможет и то и другое? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
При 2082М суммарного RX/TX трафика на двух гигабитных интерфейсах начинает подскакивать ksoftirqd/0-1

На машине ещё много всего крутится (tc u32 около 2,5тыс. пайпов в пиках, iptables-ipset, fprobe, биллинг, mysql и прочее)

Я так понимаю увеличением частоты процессоров вопрос не решить и подозреваю что спасает только установка дополнительных сетевых?

А может поможет и то и другое? :)

Поможет разнесение сервисов по машинам.

Лично мне бы в страшном сне mysql и фаирвол на одной машине крутить не приснилось бы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2DemYaN: Большое спасибо за ссылки - изучаю. Вы на практике пробовали это юзать? Работает?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Поможет разнесение сервисов по машинам.

Лично мне бы в страшном сне mysql и фаирвол на одной машине крутить не приснилось бы.

В системе всего 8 ядер по 4 на 2-х процессорах. Остальные сервисы грузят мало, ядрышки гуляют. Убито только по одному ядру в каждом процессоре там где висят сетевые.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

azazello - если какая-то операция I/O заблокирует "нужную подсистему" локом - встанут все ядра, и буду ждать, пока закончит.

conntrack меня таким поведением доводил до белого каления... пока нашел в чем дело.

 

Плюс - используя mysql - можно "уронить" firewall глюками - которые возникают только из mysql (threads, mmap и т.п.)

Т.е. вероятность падения всего сервера - растет.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Можно еще посмотреть в сторону виртуализации, но там тоже не все так гладко :(

В общем mysql таки перенесу :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2nuclearcat: Попутно читая Вашу тему про softrouter, nag edition и обсуждение про ядра, хотел узнать, может Вы можете высказать по вопросу 5) этого топика?

 

Потому как бытует мнение, что в 2.4 работа с сетью реализована быстрее и стабильнее нежели в текущих 2.6 ядрах. Так ли это по-вашему?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Однозначно нет. 2.4 при работе с сетью - медленнее.

Именно поэтому Микротик перешел на 2.6.

Ребята с openwrt/dd-wrt подняли RB-533 на 2.6, и их сборка оказалась гораздо быстрее в сетевых делах, чем родная микротиковская, основанная в то время на 2.4.

 

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

Можно еще посмотреть в сторону виртуализации, но там тоже не все так гладко :(

В общем mysql таки перенесу :)

В некоторых случаях один сервер допустим.... небольшая организация, где более 1 сервера незачем ставить, и некритичные задачи.

Да и если не падает и не тормозит, можно пока не трогать :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

nuclearcat

а как дела обстоят с множественными таблицами маршрутизации(аля VRF), route leaking, все приложения и фичи vrf-aware?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ip route add table 200 1.2.3.0/24 dev eth0

ip route add table 200 default via 1.2.3.4

 

Т.е. отдельная таблица, 200

 

В таблицу можно классифицировать по src, dst адресу, tos, fwmark, входящему устройству,

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это все же не полноценный виртуальный стек.

Например iptables получается один на все пакеты/интерфейсы/таблицы маршрутизации

Поэтому, например, нат (или любой другой механизм использующий контраки) становится совсем не тривиальным при прохождении пакета более одного раза через стек.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас