Comments 54
В первоначальной статье есть фраза «если сервер работает только маршрутизатором, то тюнинг TCP стека особого значения не имеет». Это утверждение в корне неверно.
Однако настройка MTU не имеет отношения к тюнингу TCP-стека, а NAT это уже не «только маршрутизатор».
Еще.
Если увеличиваете параметр txqueuelen, то наверное имеет смысл rxqueuelen тоже увеличивать?
А также, наверное, не стоит эти параметры резко увеличивать до конкретных значений. Ведь у Вас гигабиты и Вам эти значения подходят, однако для меньших потоков эти значения лучше взять поменьше, иначе железо будет простаивать, а пинги упадут. Стоит их увеличивать до тех пор, пока нагрузка в часы пик не станет в пределах нормы. Это же касается и MTU.
Если увеличиваете параметр txqueuelen, то наверное имеет смысл rxqueuelen тоже увеличивать?
А также, наверное, не стоит эти параметры резко увеличивать до конкретных значений. Ведь у Вас гигабиты и Вам эти значения подходят, однако для меньших потоков эти значения лучше взять поменьше, иначе железо будет простаивать, а пинги упадут. Стоит их увеличивать до тех пор, пока нагрузка в часы пик не станет в пределах нормы. Это же касается и MTU.
Вообще-то я отдельно отметил, что данные рекомендации — прежде всего для гигабитных линков. Про хорошую нагрузку говорит само название топика.
Такое ощущение, что вы читали через строку.
Такое ощущение, что вы читали через строку.
Гигабиты бывают разные, железо бывает разное. В разных случаях — разные оптимальные параметры. Поэтому лучше всегда подкручивать «на месте».
А Ваши рекомендации прочитал внимательно, не через строку :)
А Ваши рекомендации прочитал внимательно, не через строку :)
:)
В общем-то гигабит — он и в Африке гигабит. И параметры вполне себе одинаковые в любых случаях. Конечно, если гигабит «больной» вследствие специфичности железа, то данные рекомендации могут и не подойти — однако, это уже отдельный частный случай, который в любом случае следует рассматривать отдельно.
В общем-то гигабит — он и в Африке гигабит. И параметры вполне себе одинаковые в любых случаях. Конечно, если гигабит «больной» вследствие специфичности железа, то данные рекомендации могут и не подойти — однако, это уже отдельный частный случай, который в любом случае следует рассматривать отдельно.
А вопрос про rxqueuelen? :)
Однозначно не могу ответить. На практике я не выявил никаких улучшений изменения данного параметра. Как это ни странно прозвучит.
rxquelen — меньше влияют влияет потому, что это программная очередь пакетов, и для того, чтобы он работал процессор должен успевать обрабатывать прерывания сетевой карты. Более того — это просто очередь «сырых»пакетов до всякой обработки и основная нагрузка это их обработка и фильтрация. Т.е. эта очередь — весьма второстепенная вещь — если процессор успевает получать и обрабатывать пакеты, то она не нужна, а если он не успевает принимать или обрабатывать, то она не поможет. Но! При скачках нагрузки на процессор эта очередь позволяет распределить нагрузку по времени. Т.е. если сервер занят чем-то ещё (например, работой с диском), то эта очередь оказывает огромное влияние. Короче говоря — вещь очень нужна, но измерить её полезность сложно, так как проявляется при весьма специфичных условиях (большой сетевая нагрузка при одновременном выполнении ещё каких-то задач).
Теория гласит, что в общем случае размер очереди равен «пропускная способность канала на приём»*«время отклика»/«средний размер пакета» или «пропускная способность канала на приём»*«кол-во задач»*«пропускная способность канала на приём»*«время отклика»/«средний размер пакета»/«средний размер пакета».
Для гигабита и Linux оптимум лежит видимо в диапазоне от 2000 до 20000. Т.е. можно тоже ставить 10'000 и радоваться :)
Теория гласит, что в общем случае размер очереди равен «пропускная способность канала на приём»*«время отклика»/«средний размер пакета» или «пропускная способность канала на приём»*«кол-во задач»*«пропускная способность канала на приём»*«время отклика»/«средний размер пакета»/«средний размер пакета».
Для гигабита и Linux оптимум лежит видимо в диапазоне от 2000 до 20000. Т.е. можно тоже ставить 10'000 и радоваться :)
Тьфу, должно быть:
Теория гласит, что в общем случае размер очереди равен «пропускная способность канала на приём»*«время отклика»/«средний размер пакета» или «пропускная способность канала на приём»*«кол-во задач»*«квант времени планировщика»/«средний размер пакета»
Кстати можно и через пинг посчитать (хе-хе, пинг для гигабита :) )
«пропускная способность канала на приём»*«пинг под нагрузкой»*2/(3*«средний размер пакета»)
Теория гласит, что в общем случае размер очереди равен «пропускная способность канала на приём»*«время отклика»/«средний размер пакета» или «пропускная способность канала на приём»*«кол-во задач»*«квант времени планировщика»/«средний размер пакета»
Кстати можно и через пинг посчитать (хе-хе, пинг для гигабита :) )
«пропускная способность канала на приём»*«пинг под нагрузкой»*2/(3*«средний размер пакета»)
нет, в Африке гигабит может быть не тем гигабитом который у вас дома. Зависит от железа и драйверов. Например в Латвии, Гигабит на 5ти портовом гигабитном роутере (если не ошибаюсь контролеры виа и атерос) совсем разный. eth1 ~0.8 gb.....eth2-eth5 ~ 0.4 gb… притом макс мту на eth1 1526, eth2-eth5 max mtu 1522
С Уваженим.
Гигабит Африканский
С Уваженим.
Гигабит Африканский
ОК. Это имеет отношение к тюнингу «сетевого стека» — неточно выразился. NAT описан в далее в своем разделе. А про txqueuelen и MTU было написано в разделе «маршрутизатор». Так что все верно.
А зачем распределять прерывания вручную? irqbalance с этим справляется — в зависимости от количества процессоров и ядер делает распределение динамически (работает демоном на многопроцессорных машинах) или статически (настраивает при запуске на однопроцессорных многоядерных машинах, и завершает работу). И «останавливать сервис irqbalance» смысла нет — сам остановится, если это нужно.
Зачем — это надо спросить автора заметки, ссылка на которую есть в начале данного поста.
irqbalance отнюдь не всегда справляется со своей задачей. В моем случае он не справляется в принципе. Поэтому в том что лучше разбросать прерывания руками — я с автором соглашусь.
А насчет того что он сам останавливается — так этого за ним замечено не было. Он или есть, или его нет.
irqbalance отнюдь не всегда справляется со своей задачей. В моем случае он не справляется в принципе. Поэтому в том что лучше разбросать прерывания руками — я с автором соглашусь.
А насчет того что он сам останавливается — так этого за ним замечено не было. Он или есть, или его нет.
Всё же irqbalance не враги делали. Там по ссылкам во втором комментарии поподробнее описано.
В случае с маршрутизатором хороший эффект дает группировка rx-прерывания одного интерфейса с tx-прерыванием другого интерфейса на одном ядре. Это обсуждалось в статье, которую автор упомянул в начале.
А вот от постоянных прыганий прерываний по процессорам, которые делает irqbalance, — только вред.
А вот от постоянных прыганий прерываний по процессорам, которые делает irqbalance, — только вред.
Имеем устройство с двумя интерфейсами. То, что вошло в eth0 выходит через eth1, и наоборот. Это и есть маршрутизатор :)
Чисто гипотетически предположим, что трафик идет только в одну сторону. При предложенной группировке одним прерыванием будет обрабатываться и входящее через eth0, и исходящее через eth1, а другое прерывание не будет использоваться вообще. Что в этом хорошего? По-моему это противоречит первоначальной идее — распределять нагрузку поровну.
Где ошибка?
Чисто гипотетически предположим, что трафик идет только в одну сторону. При предложенной группировке одним прерыванием будет обрабатываться и входящее через eth0, и исходящее через eth1, а другое прерывание не будет использоваться вообще. Что в этом хорошего? По-моему это противоречит первоначальной идее — распределять нагрузку поровну.
Где ошибка?
Прочитайте Большие потоки трафика и управление прерываниями в Linux. Предполагается, что сетевые интерфейсы имеют несколько очередей. Иначе обработка больших потоков трафика скорее всего не получится.
В Вашем конкретном случае нужно проверить на практике, в каком случае нагрузка будет меньше — eth0 на одном процессоре, eth1 на другом или оба на одном.
В Вашем конкретном случае нужно проверить на практике, в каком случае нагрузка будет меньше — eth0 на одном процессоре, eth1 на другом или оба на одном.
Статью читал, декларацию о пользе перекрёстного объединения RX и TX видел, и не первый раз. Доказательств, почему это должно работать не видел ни разу. Поэтому и интересуюсь.
Мой пример с трафиком в одну сторону достаточно очевидно показывает — идея либо неверна, либо изложена недостаточно подробно. Интересуюсь с пристрастием.
PS ap450.pdf тоже читал.
Мой пример с трафиком в одну сторону достаточно очевидно показывает — идея либо неверна, либо изложена недостаточно подробно. Интересуюсь с пристрастием.
PS ap450.pdf тоже читал.
Группировка RX и TX на одном процессоре в основном дает оптимизицию использования кэша процессора. Более подробно вопрос не изучал, когда ставил эксперименты — группировка действительно дала некоторое снижение нагрузки. Если руки дойдут, то попробую эксперименты повторить и привести конкретные числа.
Еще могу посоветовать почитать вот этот документ: vger.kernel.org/netconf2009_slides/LinuxCon2009_JesperDangaardBrouer_final.pdf
Еще могу посоветовать почитать вот этот документ: vger.kernel.org/netconf2009_slides/LinuxCon2009_JesperDangaardBrouer_final.pdf
Да-да, именно в кэше собака и зарылась. Вот мы уже начинаем догадываться, что рекомендация лечить зелёнкой все болезни распределять прерывания вручную не универсальна, и даже на процессорах от Intel можно приводить к очень разным результатам.
За ещё пополнение списка для чтения спасибо. Но если бы статьи не ограничились простым, но не совсем верным советом, то и дополнительная литература не понадобилась бы :)
За ещё пополнение списка для чтения спасибо. Но если бы статьи не ограничились простым, но не совсем верным советом, то и дополнительная литература не понадобилась бы :)
>Значения тайм-аутов рекомендуется ставить в пределах 30-120 секунд. Этого вполне достаточно для нормальной работы абонентов, и этого вполне хватит для своевременной очистки NAT-таблицы, исключающей её переполнение.
Люди, пользующиеся ssh и иногда сильно задумывающиеся перед вводом очередной команды, ненавидят Вас :)
Люди, пользующиеся ssh и иногда сильно задумывающиеся перед вводом очередной команды, ненавидят Вас :)
А keepalive-пакеты? По умолчанию net.ipv4.tcp_keepalive_intvl = 75, так что если у провайдера >75, то проблем быть не должно. Если же у провайдера проведен подобный тюнинг, то уменьшите это значение со своей стороны и опять же проблем быть не должно.
Так вот откуда мой провайдер взял, что можно поставить net.netfilter.nf_conntrack_tcp_timeout_established = 180 и проблем у клиентов не будет.
Вы с такими таймаутами попробуйте залить что нибудь на FTP что бы заливалось больше 3х минут — будете удивлены.
Вы с такими таймаутами попробуйте залить что нибудь на FTP что бы заливалось больше 3х минут — будете удивлены.
есть ли смысл менять MTU когда большая часть трафика идет в интернет?
>Конечно же, это только «базовый» тюнинг — мы не касались, например, тюнинга ядра и т.п. вещей.
Хотеть.
С реализацией ядерного ната во FreeBSD линуксовую сравнивали?
Хотеть.
С реализацией ядерного ната во FreeBSD линуксовую сравнивали?
Очень интересно. Пишите ещё про шейпер.
>Как я уже говорил, в нашей сети более 30 тыс. абонентов, трафик которых обрабатывают 4 NAT-сервера.
Интересно, сколько килопакетов и мегабит в секунду пережевывают Ваши «питомцы»?
Интересно, сколько килопакетов и мегабит в секунду пережевывают Ваши «питомцы»?
Немного не в тему, но у меня такой вопрос. У меня есть роутер zyxel Prestige 600. Его можно заставить ребутнуться как нефиг делать, если начать кидать SYN пакеты с произвольных адресов внутренней сетки на произвольные интернет адреса. Стабильно через 5 секунд — ребут.
Понятно, что нормальная ОС при нехватке памяти под таблицы должна дропать пакеты/коннекты. Но отсюда вопрос — есть ли вообще способ защитить машину, делающую NAT, от таких страстей? Или доверие внутренней сети == беззащитность перед DoS'ом с их стороны?
Понятно, что нормальная ОС при нехватке памяти под таблицы должна дропать пакеты/коннекты. Но отсюда вопрос — есть ли вообще способ защитить машину, делающую NAT, от таких страстей? Или доверие внутренней сети == беззащитность перед DoS'ом с их стороны?
У него есть файрвол? Добавьте в него правило, запрещающее весь входящий трафик на его ИП кроме какого-то одного, с которого вы им управляете.
Это не поможет. Как мы можем ограничить свою внутренню подсетку по опции куда отсылать пакеты?
По хорошему нужно тюнить tcp-стек на таймауты спуфинг и тд.
По хорошему нужно тюнить tcp-стек на таймауты спуфинг и тд.
Если ваш роутер ложится от син-флуда — надо просто заблокировать к нему доступ. Почему вы думаете, что это не поможет?
Если это роутер через который ходят клиенты. Как к нему заблокируешь доступ? Он как раз и нужен что бы через него ходили.
В наш прогрессивный век сажать пользователей за нат просто жлобство.
1. hashsize = nf_conntrack_max / 8 не правда, на больших объемах трафика hashsize должен быть максимально приближен к nf_conntrack_max это снижает нагрузку на ЦПУ NAT сервера
2. Крутить MTU на интерфейсах ни имеет никакого смысла. Трафик у Вас транзитный и пакуеты будут бегать с MTU 1500 так что ваши 9000 никуда.
2. Крутить MTU на интерфейсах ни имеет никакого смысла. Трафик у Вас транзитный и пакуеты будут бегать с MTU 1500 так что ваши 9000 никуда.
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, то бегать будет значительно лучше.
Так что ваш комментарий не имеет никакого смысла.
И почему он должен быть максимально приближен? Цитирую первоисточник:
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, то бегать будет значительно лучше.
Так что ваш комментарий не имеет никакого смысла.
1. почему неправда? Аргументы?
Поставьте равным и сами увидите что нагрузка на CPU уменьшится :)
2. Разве я где-то сказал что 1500 бегать не будут? Будут, конечно. Но если включить jumbo frame, то бегать будет значительно лучше
в 2 раза быстрее? :)
Кстати что там насчет ethtool -k ethX и ethtool -g ethX на ваших интерфейсах?
Что за сетевые посоветуете приобретать под NAT?
Какое ядро использовать?
Поставьте равным и сами увидите что нагрузка на CPU уменьшится :)
2. Разве я где-то сказал что 1500 бегать не будут? Будут, конечно. Но если включить jumbo frame, то бегать будет значительно лучше
в 2 раза быстрее? :)
Кстати что там насчет ethtool -k ethX и ethtool -g ethX на ваших интерфейсах?
Что за сетевые посоветуете приобретать под NAT?
Какое ядро использовать?
у меня аж слезы на гхлазах наворачиваются от статей которые пестрят последнее время на хабре, всетаки хабр торт, ну по крайней мере старается. Чего только стоит недавняя про DHCP snooping. Я ж подумал что юзеры которые не попабаятся таких терминов и технологий уже давно покинули хабр.
Ну ладно перейдем от лирики к делу.
Жаль что статья не очень густая, и очень обидно если проанонсированные будущие статьи будут нести такуюже умственную нагрузку.
Как раз таки лично мне было бы интересно именно тюнинг ядра линукса на тачке под маршрутизатор/шейпер/фаервол.
Также было бы интересно услышать про различные способы билинга в таких системах. Конечно не подробные конфиги (кто их даст) атак вобщем, название систем или протоколов.
Постораюсь на днях сворганить статейку про сетевой проект над которым работаю сейчас. Правда в роли маршрутизаторов/шейперов/фаерволов служат RouterBoardы от Mikrotik. A Linux сервера в основном для ААА, SNMP, Syslog сервисов.
Ну ладно перейдем от лирики к делу.
Жаль что статья не очень густая, и очень обидно если проанонсированные будущие статьи будут нести такуюже умственную нагрузку.
Как раз таки лично мне было бы интересно именно тюнинг ядра линукса на тачке под маршрутизатор/шейпер/фаервол.
Также было бы интересно услышать про различные способы билинга в таких системах. Конечно не подробные конфиги (кто их даст) атак вобщем, название систем или протоколов.
Постораюсь на днях сворганить статейку про сетевой проект над которым работаю сейчас. Правда в роли маршрутизаторов/шейперов/фаерволов служат RouterBoardы от Mikrotik. A Linux сервера в основном для ААА, SNMP, Syslog сервисов.
1. чем вас не устраивает умственная нагрузка?
2. простите, я не знал что здесь принято писать сугубо лично для Вас, мсье
3. в каких-таких системах вы хотите увидеть биллинг? всмысле, бывают какие-то «не такие» системы?
4. про подробные конфиги и «кто их даст» — вам дать конфиги нашего биллинга? что вы там секретного хотите найти?
5. ценность вашего камента про «постораюсь написать про свой проект» я вообще не понял.
2. простите, я не знал что здесь принято писать сугубо лично для Вас, мсье
3. в каких-таких системах вы хотите увидеть биллинг? всмысле, бывают какие-то «не такие» системы?
4. про подробные конфиги и «кто их даст» — вам дать конфиги нашего биллинга? что вы там секретного хотите найти?
5. ценность вашего камента про «постораюсь написать про свой проект» я вообще не понял.
я думаю вам стоит выпить валерьяночку мон сеньер. и отнести к моему посту полегче не принимая его так близко к сердцу. а еще под момим коментом есть кнопочка «Ответить». (Заметил что вы недавно прибывший на хабр. с чем и поздравляю)
1. жидковат. больше конфигов
2. кто сказал что для меня?
3. в каких таких? очевидно… речь в статье идет о интернет провайдерских сетях до енд-юзера.
4. ну наверное вы не сталкивались с такими системами некоторые решения и строчки конфигов не выложешь на публику в виду конкуренции и промышленного шпионажа (ну скажите что я параноик… пазязя… хмммм)
5. ценность… а ценность в том что вы можете уже сейчас начать радоватся что я попытаюсь описать в своей статье одно из провайдерских решений, часть архитектуры сети…
ну ладно шучу… на самом деле мне очень понравилась и ваша статья и все предыдущие, за что всем спасибо. Они вызвали во мне очень положительные эмоции которые подталкивают меня поделится с обществом своими наработками и конфигами которые могут быть настолько же полезными насколько полезны ваши, более того вместе они повысят КПД какойнить системы.
вот и все/
peace
1. жидковат. больше конфигов
2. кто сказал что для меня?
3. в каких таких? очевидно… речь в статье идет о интернет провайдерских сетях до енд-юзера.
4. ну наверное вы не сталкивались с такими системами некоторые решения и строчки конфигов не выложешь на публику в виду конкуренции и промышленного шпионажа (ну скажите что я параноик… пазязя… хмммм)
5. ценность… а ценность в том что вы можете уже сейчас начать радоватся что я попытаюсь описать в своей статье одно из провайдерских решений, часть архитектуры сети…
ну ладно шучу… на самом деле мне очень понравилась и ваша статья и все предыдущие, за что всем спасибо. Они вызвали во мне очень положительные эмоции которые подталкивают меня поделится с обществом своими наработками и конфигами которые могут быть настолько же полезными насколько полезны ваши, более того вместе они повысят КПД какойнить системы.
вот и все/
peace
1. конкретнее, пожалуйста — каких именно конфигов и чего именно?
2. ну вы ж пишете: «Как раз таки лично мне было бы интересно именно тюнинг ядра линукса» — при том, что я писал не про тюнинг ядра линукса
3. на теме биллинга в провайдерских сетях вполне, думаю, можно диссертацию защитить — уж больно широка и разнообразна тема
4. конечно, за 10+ лет я не сталкивался с биллингом никогда, что вы, мсье…
прошу пример привести — что ценного может быть в конфиге биллинга для промышленного шпионажа, что его нельзя выкладывать на публике? только без очевидных вещей, пожалуйста, типа паролей и т.п. воды много, а ничего конкретного вы нам так и не сообщили.
5. рад за вас. и все же — какое отношение ваши достижения имеют к данной заметке и освещаемым вопросам?
2. ну вы ж пишете: «Как раз таки лично мне было бы интересно именно тюнинг ядра линукса» — при том, что я писал не про тюнинг ядра линукса
3. на теме биллинга в провайдерских сетях вполне, думаю, можно диссертацию защитить — уж больно широка и разнообразна тема
4. конечно, за 10+ лет я не сталкивался с биллингом никогда, что вы, мсье…
прошу пример привести — что ценного может быть в конфиге биллинга для промышленного шпионажа, что его нельзя выкладывать на публике? только без очевидных вещей, пожалуйста, типа паролей и т.п. воды много, а ничего конкретного вы нам так и не сообщили.
5. рад за вас. и все же — какое отношение ваши достижения имеют к данной заметке и освещаемым вопросам?
Я думаю, стоит ещё про
Интересно было бы ещё прочитать про
Упомянуть про
ethertool -K написать.netdev_backlog тоже стоит упомянуть, раз уж написали про txqueueИнтересно было бы ещё прочитать про
I/OAT и DCA. Упомянуть про
NUMA, MSI-X и Flow Affinity тоже не лишне.Sign up to leave a comment.
Большие потоки трафика и Linux: прерывания, маршрутизатор и NAT-сервер