Большие потоки трафика и Linux: прерывания, маршрутизатор и NAT-сервер

[peter23]

В первоначальной статье есть фраза «если сервер работает только маршрутизатором, то тюнинг TCP стека особого значения не имеет». Это утверждение в корне неверно.

Однако настройка MTU не имеет отношения к тюнингу TCP-стека, а NAT это уже не «только маршрутизатор».

[peter23]

Еще.
Если увеличиваете параметр txqueuelen, то наверное имеет смысл rxqueuelen тоже увеличивать?
А также, наверное, не стоит эти параметры резко увеличивать до конкретных значений. Ведь у Вас гигабиты и Вам эти значения подходят, однако для меньших потоков эти значения лучше взять поменьше, иначе железо будет простаивать, а пинги упадут. Стоит их увеличивать до тех пор, пока нагрузка в часы пик не станет в пределах нормы. Это же касается и MTU.

[erazer]

Вообще-то я отдельно отметил, что данные рекомендации — прежде всего для гигабитных линков. Про хорошую нагрузку говорит само название топика.
Такое ощущение, что вы читали через строку.

[peter23]

Гигабиты бывают разные, железо бывает разное. В разных случаях — разные оптимальные параметры. Поэтому лучше всегда подкручивать «на месте».
А Ваши рекомендации прочитал внимательно, не через строку :)

[erazer]

:)
В общем-то гигабит — он и в Африке гигабит. И параметры вполне себе одинаковые в любых случаях. Конечно, если гигабит «больной» вследствие специфичности железа, то данные рекомендации могут и не подойти — однако, это уже отдельный частный случай, который в любом случае следует рассматривать отдельно.

[peter23]

А вопрос про rxqueuelen? :)

[erazer]

Однозначно не могу ответить. На практике я не выявил никаких улучшений изменения данного параметра. Как это ни странно прозвучит.

[Sap_ru]

rxquelen — меньше влияют влияет потому, что это программная очередь пакетов, и для того, чтобы он работал процессор должен успевать обрабатывать прерывания сетевой карты. Более того — это просто очередь «сырых»пакетов до всякой обработки и основная нагрузка это их обработка и фильтрация. Т.е. эта очередь — весьма второстепенная вещь — если процессор успевает получать и обрабатывать пакеты, то она не нужна, а если он не успевает принимать или обрабатывать, то она не поможет. Но! При скачках нагрузки на процессор эта очередь позволяет распределить нагрузку по времени. Т.е. если сервер занят чем-то ещё (например, работой с диском), то эта очередь оказывает огромное влияние. Короче говоря — вещь очень нужна, но измерить её полезность сложно, так как проявляется при весьма специфичных условиях (большой сетевая нагрузка при одновременном выполнении ещё каких-то задач).
Теория гласит, что в общем случае размер очереди равен «пропускная способность канала на приём»*«время отклика»/«средний размер пакета» или «пропускная способность канала на приём»*«кол-во задач»*«пропускная способность канала на приём»*«время отклика»/«средний размер пакета»/«средний размер пакета».
Для гигабита и Linux оптимум лежит видимо в диапазоне от 2000 до 20000. Т.е. можно тоже ставить 10'000 и радоваться :)

[Sap_ru]

Тьфу, должно быть:
Теория гласит, что в общем случае размер очереди равен «пропускная способность канала на приём»*«время отклика»/«средний размер пакета» или «пропускная способность канала на приём»*«кол-во задач»*«квант времени планировщика»/«средний размер пакета»
Кстати можно и через пинг посчитать (хе-хе, пинг для гигабита :) )
«пропускная способность канала на приём»*«пинг под нагрузкой»*2/(3*«средний размер пакета»)

[iDen]

нет, в Африке гигабит может быть не тем гигабитом который у вас дома. Зависит от железа и драйверов. Например в Латвии, Гигабит на 5ти портовом гигабитном роутере (если не ошибаюсь контролеры виа и атерос) совсем разный. eth1 ~0.8 gb.....eth2-eth5 ~ 0.4 gb… притом макс мту на eth1 1526, eth2-eth5 max mtu 1522

С Уваженим.
Гигабит Африканский

[erazer]

Читайте выше: «Конечно, если гигабит «больной» вследствие специфичности железа...» — как раз ваш случай. Или вы ожидаете, что я должен описывать все мыслимые вариации всех возможных «гигабитов» в пространстве? :)

[erazer]

ОК. Это имеет отношение к тюнингу «сетевого стека» — неточно выразился. NAT описан в далее в своем разделе. А про txqueuelen и MTU было написано в разделе «маршрутизатор». Так что все верно.

[dmitryfedoseev]

А зачем распределять прерывания вручную? irqbalance с этим справляется — в зависимости от количества процессоров и ядер делает распределение динамически (работает демоном на многопроцессорных машинах) или статически (настраивает при запуске на однопроцессорных многоядерных машинах, и завершает работу). И «останавливать сервис irqbalance» смысла нет — сам остановится, если это нужно.

[erazer]

Зачем — это надо спросить автора заметки, ссылка на которую есть в начале данного поста.
irqbalance отнюдь не всегда справляется со своей задачей. В моем случае он не справляется в принципе. Поэтому в том что лучше разбросать прерывания руками — я с автором соглашусь.
А насчет того что он сам останавливается — так этого за ним замечено не было. Он или есть, или его нет.

[dmitryfedoseev]

Всё же irqbalance не враги делали. Там по ссылкам во втором комментарии поподробнее описано.

[peter23]

В случае с маршрутизатором хороший эффект дает группировка rx-прерывания одного интерфейса с tx-прерыванием другого интерфейса на одном ядре. Это обсуждалось в статье, которую автор упомянул в начале.
А вот от постоянных прыганий прерываний по процессорам, которые делает irqbalance, — только вред.

[dmitryfedoseev]

Имеем устройство с двумя интерфейсами. То, что вошло в eth0 выходит через eth1, и наоборот. Это и есть маршрутизатор :)

Чисто гипотетически предположим, что трафик идет только в одну сторону. При предложенной группировке одним прерыванием будет обрабатываться и входящее через eth0, и исходящее через eth1, а другое прерывание не будет использоваться вообще. Что в этом хорошего? По-моему это противоречит первоначальной идее — распределять нагрузку поровну.

Где ошибка?

[peter23]

Прочитайте Большие потоки трафика и управление прерываниями в Linux. Предполагается, что сетевые интерфейсы имеют несколько очередей. Иначе обработка больших потоков трафика скорее всего не получится.
В Вашем конкретном случае нужно проверить на практике, в каком случае нагрузка будет меньше — eth0 на одном процессоре, eth1 на другом или оба на одном.

[dmitryfedoseev]

Статью читал, декларацию о пользе перекрёстного объединения RX и TX видел, и не первый раз. Доказательств, почему это должно работать не видел ни разу. Поэтому и интересуюсь.

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

PS ap450.pdf тоже читал.

[peter23]

Группировка RX и TX на одном процессоре в основном дает оптимизицию использования кэша процессора. Более подробно вопрос не изучал, когда ставил эксперименты — группировка действительно дала некоторое снижение нагрузки. Если руки дойдут, то попробую эксперименты повторить и привести конкретные числа.
Еще могу посоветовать почитать вот этот документ: vger.kernel.org/netconf2009_slides/LinuxCon2009_JesperDangaardBrouer_final.pdf

[dmitryfedoseev]

Да-да, именно в кэше собака и зарылась. Вот мы уже начинаем догадываться, что рекомендация лечить зелёнкой все болезни распределять прерывания вручную не универсальна, и даже на процессорах от Intel можно приводить к очень разным результатам.

За ещё пополнение списка для чтения спасибо. Но если бы статьи не ограничились простым, но не совсем верным советом, то и дополнительная литература не понадобилась бы :)

[borisko]

>Значения тайм-аутов рекомендуется ставить в пределах 30-120 секунд. Этого вполне достаточно для нормальной работы абонентов, и этого вполне хватит для своевременной очистки NAT-таблицы, исключающей её переполнение.

Люди, пользующиеся ssh и иногда сильно задумывающиеся перед вводом очередной команды, ненавидят Вас :)

[peter23]

А keepalive-пакеты? По умолчанию net.ipv4.tcp_keepalive_intvl = 75, так что если у провайдера >75, то проблем быть не должно. Если же у провайдера проведен подобный тюнинг, то уменьшите это значение со своей стороны и опять же проблем быть не должно.

[Mielofon]

Так вот откуда мой провайдер взял, что можно поставить net.netfilter.nf_conntrack_tcp_timeout_established = 180 и проблем у клиентов не будет.
Вы с такими таймаутами попробуйте залить что нибудь на FTP что бы заливалось больше 3х минут — будете удивлены.

[slimlv]

есть ли смысл менять MTU когда большая часть трафика идет в интернет?

[erazer]

А почему нет? Какая разница куда он идет?
У нас внешние каналы в интернет исчисляются гигабитами.
Конечно, если в вашем случае в интернет уходит меньше гигабита — очевидно, что крутить MTU особой надобности нет.

[slimlv]

разве MTU не должен быть одинаковым у принимающей и отсылающей стороны?

[erazer]

Должен. И это в статье отдельно указано, между прочим.

[flyaway]

>Конечно же, это только «базовый» тюнинг — мы не касались, например, тюнинга ядра и т.п. вещей.

Хотеть.
С реализацией ядерного ната во FreeBSD линуксовую сравнивали?

[erazer]

FreeBSD у нас не используется. Пользовал в разное время в разных условиях (на других сетях), но в одинаковых условиях с linux-ом сравнить вохзможности не было. Так что ничего конкретного не скажу.

[Sov1et]

Очень интересно. Пишите ещё про шейпер.

[facha]

>Как я уже говорил, в нашей сети более 30 тыс. абонентов, трафик которых обрабатывают 4 NAT-сервера.

Интересно, сколько килопакетов и мегабит в секунду пережевывают Ваши «питомцы»?

[erazer]

Не могу точно ответить на данный момент. Возможно, приведу данные чуть позже в «следующих выпусках».

[segoon]

Немного не в тему, но у меня такой вопрос. У меня есть роутер zyxel Prestige 600. Его можно заставить ребутнуться как нефиг делать, если начать кидать SYN пакеты с произвольных адресов внутренней сетки на произвольные интернет адреса. Стабильно через 5 секунд — ребут.

Понятно, что нормальная ОС при нехватке памяти под таблицы должна дропать пакеты/коннекты. Но отсюда вопрос — есть ли вообще способ защитить машину, делающую NAT, от таких страстей? Или доверие внутренней сети == беззащитность перед DoS'ом с их стороны?

[erazer]

У него есть файрвол? Добавьте в него правило, запрещающее весь входящий трафик на его ИП кроме какого-то одного, с которого вы им управляете.

[Sov1et]

Это не поможет. Как мы можем ограничить свою внутренню подсетку по опции куда отсылать пакеты?
По хорошему нужно тюнить tcp-стек на таймауты спуфинг и тд.

[erazer]

Если ваш роутер ложится от син-флуда — надо просто заблокировать к нему доступ. Почему вы думаете, что это не поможет?

[Sov1et]

Если это роутер через который ходят клиенты. Как к нему заблокируешь доступ? Он как раз и нужен что бы через него ходили.

[erazer]

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

[Sov1et]

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

[erazer]

Ухты как мрачно. Я не знаю этого роутера — но вполне возможно, что там вариантов может и не быть.

[cosmobot]

В наш прогрессивный век сажать пользователей за нат просто жлобство.

[gag_fenix]

Не скажите, Федор Михайлович, : NAT не пропустит соединения из вне => выше безопасность.
И потом, адреса IPv4 наоборот заканчиваются в наш прогрессивный век, а на IPv6 почему-то никто не спешит переходить.

[gag_fenix]

P.S. когда у нас в сети появилась возможность заиметь внешний IP-адрес, у первого пользователя этой услуги через 40 минут после подключения на FTP стали долбится боты из интернета :)
А если у юзверя будет непропатченный Windows? Страшно себе представить.

[andrewsh]

NAT doesn't improve security itself.

[CentALT]

1. hashsize = nf_conntrack_max / 8 не правда, на больших объемах трафика hashsize должен быть максимально приближен к nf_conntrack_max это снижает нагрузку на ЦПУ NAT сервера

2. Крутить MTU на интерфейсах ни имеет никакого смысла. Трафик у Вас транзитный и пакуеты будут бегать с MTU 1500 так что ваши 9000 никуда.

[erazer]

1. почему неправда? Аргументы?
И почему он должен быть максимально приближен? Цитирую первоисточник:

On i386 architecture, HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (in bytes) / 131072 = RAMSIZE (in MegaBytes) * 8. So for example, a 32 bits PC with 512MB of RAM can store 512*1024^2/128/1024 =
512*8 = 4096 buckets (linked lists)

But the real formula is: HASHSIZE = CONNTRACK_MAX / 8 = RAMSIZE (in bytes) / 131072 / (x / 32)
where x is the number of bits in a pointer (for example, 32 or 64 bits)

2. Разве я где-то сказал что 1500 бегать не будут? Будут, конечно. Но если включить jumbo frame, то бегать будет значительно лучше.

Так что ваш комментарий не имеет никакого смысла.

[CentALT]

1. почему неправда? Аргументы?

Поставьте равным и сами увидите что нагрузка на CPU уменьшится :)

2. Разве я где-то сказал что 1500 бегать не будут? Будут, конечно. Но если включить jumbo frame, то бегать будет значительно лучше

в 2 раза быстрее? :)

Кстати что там насчет ethtool -k ethX и ethtool -g ethX на ваших интерфейсах?
Что за сетевые посоветуете приобретать под NAT?
Какое ядро использовать?

[iDen]

у меня аж слезы на гхлазах наворачиваются от статей которые пестрят последнее время на хабре, всетаки хабр торт, ну по крайней мере старается. Чего только стоит недавняя про DHCP snooping. Я ж подумал что юзеры которые не попабаятся таких терминов и технологий уже давно покинули хабр.

Ну ладно перейдем от лирики к делу.
Жаль что статья не очень густая, и очень обидно если проанонсированные будущие статьи будут нести такуюже умственную нагрузку.
Как раз таки лично мне было бы интересно именно тюнинг ядра линукса на тачке под маршрутизатор/шейпер/фаервол.
Также было бы интересно услышать про различные способы билинга в таких системах. Конечно не подробные конфиги (кто их даст) атак вобщем, название систем или протоколов.

Постораюсь на днях сворганить статейку про сетевой проект над которым работаю сейчас. Правда в роли маршрутизаторов/шейперов/фаерволов служат RouterBoardы от Mikrotik. A Linux сервера в основном для ААА, SNMP, Syslog сервисов.

[erazer]

1. чем вас не устраивает умственная нагрузка?
2. простите, я не знал что здесь принято писать сугубо лично для Вас, мсье
3. в каких-таких системах вы хотите увидеть биллинг? всмысле, бывают какие-то «не такие» системы?
4. про подробные конфиги и «кто их даст» — вам дать конфиги нашего биллинга? что вы там секретного хотите найти?
5. ценность вашего камента про «постораюсь написать про свой проект» я вообще не понял.

[iDen]

я думаю вам стоит выпить валерьяночку мон сеньер. и отнести к моему посту полегче не принимая его так близко к сердцу. а еще под момим коментом есть кнопочка «Ответить». (Заметил что вы недавно прибывший на хабр. с чем и поздравляю)
1. жидковат. больше конфигов
2. кто сказал что для меня?
3. в каких таких? очевидно… речь в статье идет о интернет провайдерских сетях до енд-юзера.
4. ну наверное вы не сталкивались с такими системами некоторые решения и строчки конфигов не выложешь на публику в виду конкуренции и промышленного шпионажа (ну скажите что я параноик… пазязя… хмммм)

5. ценность… а ценность в том что вы можете уже сейчас начать радоватся что я попытаюсь описать в своей статье одно из провайдерских решений, часть архитектуры сети…

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

вот и все/
peace

[erazer]

1. конкретнее, пожалуйста — каких именно конфигов и чего именно?

2. ну вы ж пишете: «Как раз таки лично мне было бы интересно именно тюнинг ядра линукса» — при том, что я писал не про тюнинг ядра линукса

3. на теме биллинга в провайдерских сетях вполне, думаю, можно диссертацию защитить — уж больно широка и разнообразна тема

4. конечно, за 10+ лет я не сталкивался с биллингом никогда, что вы, мсье…
прошу пример привести — что ценного может быть в конфиге биллинга для промышленного шпионажа, что его нельзя выкладывать на публике? только без очевидных вещей, пожалуйста, типа паролей и т.п. воды много, а ничего конкретного вы нам так и не сообщили.

5. рад за вас. и все же — какое отношение ваши достижения имеют к данной заметке и освещаемым вопросам?

[iDen]

увольте.

[SaveTheRbtz]

Я думаю, стоит ещё про ethertool -K написать.
netdev_backlog тоже стоит упомянуть, раз уж написали про txqueue
Интересно было бы ещё прочитать про I/OAT и DCA.
Упомянуть про NUMA, MSI-X и Flow Affinity тоже не лишне.