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

Написано по следам публикации Большие потоки трафика и управление прерываниями в Linux

В нашей городской сети более 30 тысяч абонентов. Суммарный объем внешних каналов — более 3 гигабит. А советы, данные в упомянутой статье, мы проходили еще несколько лет назад. Таким образом, я хочу шире раскрыть тему и поделиться с читателями своими наработками в рамках затрагиваемого вопроса.

В заметке описываются нюансы настройки/тюнинга маршрутизатора и NAT-сервера под управлением Linux, а также приведены некоторые уточнения по поводу распределения прерываний.



Прерывания



Раскидывание прерываний сетевых карт по разным ядрам — это самое первое, с чем сталкивается сисадмин при возрастании нагрузки на linux-маршрутизатор. В упомянутой статье тема освещена достаточно подробно — поэтому надолго останавливаться на этом вопросе мы не будем.

Хочу только отметить:

  • если вы вручную раскидываете прерывания, то вам необходимо остановить сервис irqbalance. Этот сервис предназначен как раз для автоматического регулирования прерываний между ядрами процессоров. Если вы делаете эту работу вручную — сервис лучше остановить;
  • не забудьте внести соответствующие правки в «автозагрузку» (например, /etc/rc.local) — т.к. после рестарта сервера все прерывания опять распределятся вкучку на одном ядре;
  • после рестарта сервера, сетевые карты могут получить (а скорее всего, именно так и будет) новые номера прерываний. Поэтому в /etc/rc.local лучше не вписывать руками конкретные номера прерываний — а автоматизировать с помощью вспомогательного скрипта распознавание, какая сетевая какое прерывание заняла.


Маршрутизатор



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

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

Увеличиваем MTU на linux


/sbin/ifconfig eth0 mtu 9000

Увеличиваем MTU на коммутаторах


На коммутационном оборудовании обычно это будет называться jumbo-frame. В частности, для Cisco Catalyst 3750

3750(config)# system mtu jumbo 9000
3750(config)# exit
3750# reload


Заметьте: коммутатор затем надо перезагрузить. Кстати, mtu jumbo касаются только гигабитных линков, — 100-мбит такая команда не затрагивает.

Увеличиваем очередь передачи на linux


/sbin/ifconfig eth0 txqueuelen 10000

По умолчанию значение стоит 1000. Для гигабитных линков рекомендуется ставить 10000. В двух словах, это размер буфера передачи. Когда буфер наполняется до этого граничного значения, данные передаются в сеть.

Имейте ввиду, что если вы меняете размер MTU на интерфейсе какой-то железки — вы должны сделать то же самое и на интерфейсе её «соседа». Т.е., если вы увеличили MTU до 9000 на интерфейсе linux-роутера, то вы должны включить jumbo-frame на порту коммутатора, в который данный роутер включен. В противном случае сеть работать будет, но очень плохо: пакеты ходить по сети будут «через одного».

Итоги


В результате всех этих изменений, в сети возрастут «пинги» — но общая пропускная способность заметно возрастет, а нагрузка на активное оборудование снизится.

Сервер NAT



Операция NAT (Network Address Translation) является одной из самых дорогостоящих (в смысле, ресурсоёмких). Поэтому, если у вас большая сеть, без тюнинга NAT-сервера вам не обойтись.

Увеличение кол-ва отслеживаемых соединений


Для осуществления своей задачи, NAT-серверу необходимо «помнить» обо всех соединениях, которые через него проходят. Будь то «пинг» или чья-то «аська» — все эти сессии NAT-сервер «помнит» и отслеживает у себя в памяти в специальной таблице. Когда сессия закрывается, информация о ней из таблицы удаляется. Размер этой таблицы фиксирован. Именно поэтому если трафика через сервер идет достаточно много, а размера таблицы нехватает, — то NAT-сервер начинает «дропать» пакеты, рвать сессии, интернет начинает работать с жуткими перебоями, а на сам NAT-сервер бывает даже попасть по SSH становится просто невозможно.

Чтобы таких ужасов не происходило, необходимо адекватно увеличивать размер таблицы — в соответствии с проходящим через NAT трафиком:

/sbin/sysctl -w net.netfilter.nf_conntrack_max=524288

Настоятельно НЕ рекомендуется ставить такое большое значение, если у вас на NAT-сервере меньше 1 гигабайта оперативной памяти.

Посмотреть текущее значение можно вот так:

/sbin/sysctl net.netfilter.nf_conntrack_max

Посмотреть, насколько уже заполнена таблица отслеживания соединений, можно вот так:

/sbin/sysctl net.netfilter.nf_conntrack_count

Увеличение размера hash-таблицы


Пропорционально должная быть увеличена и хэш-таблица, в которой хранятся списки conntrack-записей.

echo 65536 > /sys/module/nf_conntrack/parameters/hashsize

Правило простое: hashsize = nf_conntrack_max / 8

Уменьшение значений time-out


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

Однако, по умолчанию значения тайм-аутов стоят достаточно большие. Поэтому, при больших потоках трафика даже если вы растянете nf_conntrack_max до предела — вы все равно рискуете быстро столкнуться с переполнением таблицы и разрывами соединений.

Чтобы такого не произошло, необходимо грамотно выставить тайм-ауты отслеживания соединений на NAT-сервере.

Текущие значения можно посмотреть, например, так:

sysctl -a | grep conntrack | grep timeout

В результате вы увидите что-то подобное:

net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_events_retry_timeout = 15


Это значения тайм-аутов в секундах. Как вы видите, значение net.netfilter.nf_conntrack_generic_timeout равно 600 (10 минут). Т.е. NAT-сервер будет держать в памяти информацию о сессии до тех пор, пока по ней будет «пробегать» хоть что-то хотя бы раз в 10 минут.

На первый взгляд, ничего страшного — но на самом деле это очень и очень много.

Если вы посмотрите на net.netfilter.nf_conntrack_tcp_timeout_established — то вы увидите там значение 432000. Другими словами, простую TCP-сессию ваш NAT-сервер будет отслеживать до тех пор, пока по ней не пробегает какой-нибудь пакетик хотя бы раз в 5 дней(!).

Говоря еще более простым языком, за-DDOS'ить такой NAT-сервер становится проще простого: его NAT-таблица (параметр nf_conntrack_max) переполняется «на ура» простейшим флудом — вследствие чего он будет рвать соединения и в худшем варианте быстро превратится в черную дыру.

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

И не забудьте вписать соответствующие изменения в /etc/rc.local и /etc/sysctl.conf

Итоги


После тюнинга вы получите вполне жизнеспособный и производительный NAT-сервер. Конечно же, это только «базовый» тюнинг — мы не касались, например, тюнинга ядра и т.п. вещей. Однако, в большинстве случаев даже таких простых действий будет достаточно для нормальной работы достаточно большой сети. Как я уже говорил, в нашей сети более 30 тыс. абонентов, трафик которых обрабатывают 4 NAT-сервера.

В следующих выпусках:
  • большие потоки и высокопроизводительный шейпер;
  • большие потоки и высокопроизводительный файрвол.
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 54

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

    Однако настройка MTU не имеет отношения к тюнингу TCP-стека, а NAT это уже не «только маршрутизатор».
      0
      Еще.
      Если увеличиваете параметр txqueuelen, то наверное имеет смысл rxqueuelen тоже увеличивать?
      А также, наверное, не стоит эти параметры резко увеличивать до конкретных значений. Ведь у Вас гигабиты и Вам эти значения подходят, однако для меньших потоков эти значения лучше взять поменьше, иначе железо будет простаивать, а пинги упадут. Стоит их увеличивать до тех пор, пока нагрузка в часы пик не станет в пределах нормы. Это же касается и MTU.
        +2
        Вообще-то я отдельно отметил, что данные рекомендации — прежде всего для гигабитных линков. Про хорошую нагрузку говорит само название топика.
        Такое ощущение, что вы читали через строку.
          0
          Гигабиты бывают разные, железо бывает разное. В разных случаях — разные оптимальные параметры. Поэтому лучше всегда подкручивать «на месте».
          А Ваши рекомендации прочитал внимательно, не через строку :)
            0
            :)
            В общем-то гигабит — он и в Африке гигабит. И параметры вполне себе одинаковые в любых случаях. Конечно, если гигабит «больной» вследствие специфичности железа, то данные рекомендации могут и не подойти — однако, это уже отдельный частный случай, который в любом случае следует рассматривать отдельно.
              0
              А вопрос про rxqueuelen? :)
                +2
                Однозначно не могу ответить. На практике я не выявил никаких улучшений изменения данного параметра. Как это ни странно прозвучит.
                  +1
                  rxquelen — меньше влияют влияет потому, что это программная очередь пакетов, и для того, чтобы он работал процессор должен успевать обрабатывать прерывания сетевой карты. Более того — это просто очередь «сырых»пакетов до всякой обработки и основная нагрузка это их обработка и фильтрация. Т.е. эта очередь — весьма второстепенная вещь — если процессор успевает получать и обрабатывать пакеты, то она не нужна, а если он не успевает принимать или обрабатывать, то она не поможет. Но! При скачках нагрузки на процессор эта очередь позволяет распределить нагрузку по времени. Т.е. если сервер занят чем-то ещё (например, работой с диском), то эта очередь оказывает огромное влияние. Короче говоря — вещь очень нужна, но измерить её полезность сложно, так как проявляется при весьма специфичных условиях (большой сетевая нагрузка при одновременном выполнении ещё каких-то задач).
                  Теория гласит, что в общем случае размер очереди равен «пропускная способность канала на приём»*«время отклика»/«средний размер пакета» или «пропускная способность канала на приём»*«кол-во задач»*«пропускная способность канала на приём»*«время отклика»/«средний размер пакета»/«средний размер пакета».
                  Для гигабита и Linux оптимум лежит видимо в диапазоне от 2000 до 20000. Т.е. можно тоже ставить 10'000 и радоваться :)
                    0
                    Тьфу, должно быть:
                    Теория гласит, что в общем случае размер очереди равен «пропускная способность канала на приём»*«время отклика»/«средний размер пакета» или «пропускная способность канала на приём»*«кол-во задач»*«квант времени планировщика»/«средний размер пакета»
                    Кстати можно и через пинг посчитать (хе-хе, пинг для гигабита :) )
                    «пропускная способность канала на приём»*«пинг под нагрузкой»*2/(3*«средний размер пакета»)
                  +1
                  нет, в Африке гигабит может быть не тем гигабитом который у вас дома. Зависит от железа и драйверов. Например в Латвии, Гигабит на 5ти портовом гигабитном роутере (если не ошибаюсь контролеры виа и атерос) совсем разный. eth1 ~0.8 gb.....eth2-eth5 ~ 0.4 gb… притом макс мту на eth1 1526, eth2-eth5 max mtu 1522

                  С Уваженим.
                  Гигабит Африканский
                    0
                    Читайте выше: «Конечно, если гигабит «больной» вследствие специфичности железа...» — как раз ваш случай. Или вы ожидаете, что я должен описывать все мыслимые вариации всех возможных «гигабитов» в пространстве? :)
            0
            ОК. Это имеет отношение к тюнингу «сетевого стека» — неточно выразился. NAT описан в далее в своем разделе. А про txqueuelen и MTU было написано в разделе «маршрутизатор». Так что все верно.
              +2
              А зачем распределять прерывания вручную? irqbalance с этим справляется — в зависимости от количества процессоров и ядер делает распределение динамически (работает демоном на многопроцессорных машинах) или статически (настраивает при запуске на однопроцессорных многоядерных машинах, и завершает работу). И «останавливать сервис irqbalance» смысла нет — сам остановится, если это нужно.
                +2
                Зачем — это надо спросить автора заметки, ссылка на которую есть в начале данного поста.
                irqbalance отнюдь не всегда справляется со своей задачей. В моем случае он не справляется в принципе. Поэтому в том что лучше разбросать прерывания руками — я с автором соглашусь.
                А насчет того что он сам останавливается — так этого за ним замечено не было. Он или есть, или его нет.
                  0
                  Всё же irqbalance не враги делали. Там по ссылкам во втором комментарии поподробнее описано.
                  +1
                  В случае с маршрутизатором хороший эффект дает группировка rx-прерывания одного интерфейса с tx-прерыванием другого интерфейса на одном ядре. Это обсуждалось в статье, которую автор упомянул в начале.
                  А вот от постоянных прыганий прерываний по процессорам, которые делает irqbalance, — только вред.
                    0
                    Имеем устройство с двумя интерфейсами. То, что вошло в eth0 выходит через eth1, и наоборот. Это и есть маршрутизатор :)

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

                    Где ошибка?
                      0
                      Прочитайте Большие потоки трафика и управление прерываниями в Linux. Предполагается, что сетевые интерфейсы имеют несколько очередей. Иначе обработка больших потоков трафика скорее всего не получится.
                      В Вашем конкретном случае нужно проверить на практике, в каком случае нагрузка будет меньше — eth0 на одном процессоре, eth1 на другом или оба на одном.
                        0
                        Статью читал, декларацию о пользе перекрёстного объединения RX и TX видел, и не первый раз. Доказательств, почему это должно работать не видел ни разу. Поэтому и интересуюсь.

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

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

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

                  Люди, пользующиеся ssh и иногда сильно задумывающиеся перед вводом очередной команды, ненавидят Вас :)
                    +3
                    А keepalive-пакеты? По умолчанию net.ipv4.tcp_keepalive_intvl = 75, так что если у провайдера >75, то проблем быть не должно. Если же у провайдера проведен подобный тюнинг, то уменьшите это значение со своей стороны и опять же проблем быть не должно.
                      0
                      Так вот откуда мой провайдер взял, что можно поставить net.netfilter.nf_conntrack_tcp_timeout_established = 180 и проблем у клиентов не будет.
                      Вы с такими таймаутами попробуйте залить что нибудь на FTP что бы заливалось больше 3х минут — будете удивлены.
                      0
                      есть ли смысл менять MTU когда большая часть трафика идет в интернет?
                        0
                        А почему нет? Какая разница куда он идет?
                        У нас внешние каналы в интернет исчисляются гигабитами.
                        Конечно, если в вашем случае в интернет уходит меньше гигабита — очевидно, что крутить MTU особой надобности нет.
                          0
                          разве MTU не должен быть одинаковым у принимающей и отсылающей стороны?
                            0
                            Должен. И это в статье отдельно указано, между прочим.
                        0
                        >Конечно же, это только «базовый» тюнинг — мы не касались, например, тюнинга ядра и т.п. вещей.

                        Хотеть.
                        С реализацией ядерного ната во FreeBSD линуксовую сравнивали?
                          0
                          FreeBSD у нас не используется. Пользовал в разное время в разных условиях (на других сетях), но в одинаковых условиях с linux-ом сравнить вохзможности не было. Так что ничего конкретного не скажу.
                          0
                          Очень интересно. Пишите ещё про шейпер.
                            0
                            >Как я уже говорил, в нашей сети более 30 тыс. абонентов, трафик которых обрабатывают 4 NAT-сервера.

                            Интересно, сколько килопакетов и мегабит в секунду пережевывают Ваши «питомцы»?
                              0
                              Не могу точно ответить на данный момент. Возможно, приведу данные чуть позже в «следующих выпусках».
                              0
                              Немного не в тему, но у меня такой вопрос. У меня есть роутер zyxel Prestige 600. Его можно заставить ребутнуться как нефиг делать, если начать кидать SYN пакеты с произвольных адресов внутренней сетки на произвольные интернет адреса. Стабильно через 5 секунд — ребут.

                              Понятно, что нормальная ОС при нехватке памяти под таблицы должна дропать пакеты/коннекты. Но отсюда вопрос — есть ли вообще способ защитить машину, делающую NAT, от таких страстей? Или доверие внутренней сети == беззащитность перед DoS'ом с их стороны?
                                0
                                У него есть файрвол? Добавьте в него правило, запрещающее весь входящий трафик на его ИП кроме какого-то одного, с которого вы им управляете.
                                  0
                                  Это не поможет. Как мы можем ограничить свою внутренню подсетку по опции куда отсылать пакеты?
                                  По хорошему нужно тюнить tcp-стек на таймауты спуфинг и тд.
                                    0
                                    Если ваш роутер ложится от син-флуда — надо просто заблокировать к нему доступ. Почему вы думаете, что это не поможет?
                                      0
                                      Если это роутер через который ходят клиенты. Как к нему заблокируешь доступ? Он как раз и нужен что бы через него ходили.
                                        0
                                        Вы путаете доступ к интернету через ваш роутер и доступ к вашему роутеру. Я предлагаю настроить файрвол на роутере, который пропускал бы транзитный трафик, но блокировал бы трафик не посредственно на роутер (за исключением одного какого-то адреса для управления).
                                          0
                                          >SYN пакеты с произвольных адресов внутренней сетки на произвольные интернет адреса
                                          то есть переполянется таблица ната и сетевая подсистема, а не количество сокетов на менеджмент интрефейсе.
                                            0
                                            Ухты как мрачно. Я не знаю этого роутера — но вполне возможно, что там вариантов может и не быть.
                                +2
                                В наш прогрессивный век сажать пользователей за нат просто жлобство.
                                  +1
                                  Не скажите, Федор Михайлович, : NAT не пропустит соединения из вне => выше безопасность.
                                  И потом, адреса IPv4 наоборот заканчиваются в наш прогрессивный век, а на IPv6 почему-то никто не спешит переходить.
                                    0
                                    P.S. когда у нас в сети появилась возможность заиметь внешний IP-адрес, у первого пользователя этой услуги через 40 минут после подключения на FTP стали долбится боты из интернета :)
                                    А если у юзверя будет непропатченный Windows? Страшно себе представить.
                                      +1
                                      NAT doesn't improve security itself.
                                    0
                                    1. hashsize = nf_conntrack_max / 8 не правда, на больших объемах трафика hashsize должен быть максимально приближен к nf_conntrack_max это снижает нагрузку на ЦПУ NAT сервера

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

                                      0
                                      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, то бегать будет значительно лучше.

                                      Так что ваш комментарий не имеет никакого смысла.
                                        +1
                                        1. почему неправда? Аргументы?

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

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

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

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

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

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

                                      Постораюсь на днях сворганить статейку про сетевой проект над которым работаю сейчас. Правда в роли маршрутизаторов/шейперов/фаерволов служат RouterBoardы от Mikrotik. A Linux сервера в основном для ААА, SNMP, Syslog сервисов.
                                        –2
                                        1. чем вас не устраивает умственная нагрузка?
                                        2. простите, я не знал что здесь принято писать сугубо лично для Вас, мсье
                                        3. в каких-таких системах вы хотите увидеть биллинг? всмысле, бывают какие-то «не такие» системы?
                                        4. про подробные конфиги и «кто их даст» — вам дать конфиги нашего биллинга? что вы там секретного хотите найти?
                                        5. ценность вашего камента про «постораюсь написать про свой проект» я вообще не понял.
                                          –2
                                          я думаю вам стоит выпить валерьяночку мон сеньер. и отнести к моему посту полегче не принимая его так близко к сердцу. а еще под момим коментом есть кнопочка «Ответить». (Заметил что вы недавно прибывший на хабр. с чем и поздравляю)
                                          1. жидковат. больше конфигов
                                          2. кто сказал что для меня?
                                          3. в каких таких? очевидно… речь в статье идет о интернет провайдерских сетях до енд-юзера.
                                          4. ну наверное вы не сталкивались с такими системами некоторые решения и строчки конфигов не выложешь на публику в виду конкуренции и промышленного шпионажа (ну скажите что я параноик… пазязя… хмммм)

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

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

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

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

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

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

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

                                          Only users with full accounts can post comments. Log in, please.