Dark_Angel

Вы меня не поняли. Я говорил о том, чтобы просмотреть netflow который вы собираете, а не об активности процесса сборки. В netflow ( собраных файлах ) есть поле отвечающее за количество потоков в том или инном направлении. Ценность информации в агрегации, потому как можно легко увидеть, что клиент генерит 1К потоков в час, а другой генерит 1М потоков в час, соответственно количество потоков в минуту или даже секунду Вы сами посчитаете. Найдя таких активных можно посмотреть что они делают. Обычно это вирусня.

Conntrack - это значение таблицы в текущий момент времени. Это интересно, но статистика интереснее. Поэтому я рекомендую посмотреть именно netflow. Ну там за 5-10-30-60 минут. У вас же он как раз собирается на роутере.

40К для 44К пакетов тоже многовато. Просмотрите флов отсортированый по flows, прошу прощения за каламбур. Наверняка кто-то генерит кучу сессий и тем самым портит вам всю малину. Про процессор спросил, чтобы не получилось, что говорим об одной машине, а статистика снимается с другой, а то были случаи.

Ну это функция матчинга строк, поэтому могла быть где угодно. Даже если нагрузка у вас сейчас низкая, то при росте pps будет расти нелинейно, потому что каждый пакет будет просматриваться через НАТ размером в 100К записей, а при увеличении pps того и глядиш вырастет.

Ну говорите Вы все красиво и таймеры правильные, но откуда в контраке 100К соединений при 46Кpps? Вы поройтесь в эту сторону. Так однозначно быть не должно. Далее по шейперам. Тоже все хорошо рассказываете, но откуда тогда в топе ts_kmp и sch_hfsc? Я допускаю, что ts_kmp может дергаться не из шейпера, а из iptables скажем или еще отуда-то, может даже из НАТА, но в топе ему не место, однозначно. Кстати, было бы не плохо выкупить, кто его просит. 1е место всетаки. Если пакет на шейпере пролетает 5-6 правил, то нагрузка от фильтров просто смешная, у вас же классификатор висит достаточно высоко. Если уверены, что все пакеты проходят именно так, то пока шейпер не трогайте, покопайтесь в НАТе. Кстати buckets лучше поставить CONNTRACK_MAX / 8 = 32K для вашего случая. Это на суть вопроса влияет мало, но всё же так согласно оф доке должно быть. У вас в профайлере написано "CPU: Intel Core/i7, speed 1994.99 MHz (estimated)" так и должно быть, разве ксеон не определяется как ксеон? А где tcp_keepalive_time, tcp_keepalive_probes, tcp_fin_timeout?

А как у вас получается при 130 Kpps 100K записей в таблице НАТ? Пакет = запись? Не хорошо. Кроме того вы таймеры для сессий подкрутили? Можете показать какие у вас? Нагрузка от снятия фильтров не может не падать, т.к. у вас минимум 3 функции оттуда в топе: шедулинг пакета, классификация, продвижение по цепочке. Я уже не говорю про то что фильтров 1.5К. Посмотрите профайлер после убирания фильтров. Еще, кстати, iptables выступает не плохо у вас, покажите тоже. Ну и давайте таблицу роутинга по размеру оценим, чтобы понять откуда ip_route_input_common(). Ну и в любом случае, на скоростях больше 100 Мбит, иметь 1.5К фильтров на шейпинг - это непозволительная роскош. Хеш таблицы же. Я уже не говорю про интефейс ifb0 который, я так понимаю есть заворачивание входящих пакетов туда? Это тоже не про роутер.

Судя по всему у вас много шейперов и ната. Можете показать количество сессий НАТ и количество фильтров у шейпера? Если говорить о емкости то такой и 10Г может потянуть на тупом роутинге наверное. 130 Kpps - это точно не его. 82576 - отличный чип, я его сам юзаю. Уткнутся в его потолок не реально. Я думаю, что у вас либо ядро с багами, либо реально много навесили на роутер. Я вообще рекомендую посмотреть в сторону 2.6.27 ядра, если никакие новые фичи из свежих ядер вам не надо. Из моих наблюдений оно самое быстрое и безпроблемное. Для 1 Гбита его даже напильником ровнять не надо.

Ну дело точно не в процессорах, т.к. spin lock - это когда процесс ожидает открытия лока для дальнеших действий, т.е. ожидает используя ресурсы. Я не знаю точно что именно у вас лочит процессор, но обратите внимание на наличия, почти 10% rb_next() в сценарии, когда всё встает и отсутствия его в другой ситуации. Так же посмотрите, нет ли вызовов этой функции ( raw_spin_lock ) из модулей nf_conntrack_find и hfsc_enqueue(). Может у вас флудом ложит роутер. Бывало такое. Ну и пробуйте ставить стабильное ядро. r4 может содержать и куда более неприятные баги. Есть же ванильное уже 2.6.38.8 причем давно.

120K - это очевидно мало для такой машины.

Ну вот это уже похоже на правду. Теперь, если есть желание, можете тюнить ядро. +1 к совету NiTr0 не делить очереди.

2 Justas: Еще я рекомендую отключить HT. Практически доказано, что это вымывает кеш. Да, я вижу, что вы прибили сетевые раз через раз, и они должны быть на разных процессорах, но чтобы исключить вероятность вымывания кеша, отключите их. Всеравно пользоваться виртуальными ядрами на роутере вы не сможете. Кроме того вы не указали значение pps которое у вас сейчас загружает новую машину. 2nicol@s: Я понимаю, что задаю вопрос немного поздновато, но удалось ли решить описанные проблемы?

Я просто оставлю это здесь: http://habrahabr.ru/blogs/linux/114082/ Хотя к данной теме это отношения не имеет, т.к. виновник есть и смотри на него через top или mpstat - разницы это не сделает. Ну и для разных задач разные инструменты.

2morf: По поводу не хочу городить своих костылей. Спрашивая тут вы будете городить не свои, а наши костыли. Уж не знаю даже что лучше. Как по мне, то разбивка на ВЛАНы и агрегация их в центре, если будете бить по 32-64 адреса на ВЛАН потребует ставить еще свитч который это будет агрегировать между собой. Причем не только на L2 но и на L3 уровне, маршрутизация же. Дело не только в свитче, но и в том, что весь трафик вне этих ВЛАНов будет проходить транзитом через ваш центр агрегации. Если у вас будет много абонентов и вы будете юзать ретрекер, что логично, то это создаст дополнительную нагрузку на агрегатор, и загрузит сеть, вместо разгрузки. Поэтому я бы делал одно серое адресное пространство на всех, резал бы дома ВЛАНАми, чтобы нельзя было вывести из строя больше одного сегмента, а ВЛАНы терминировал бы где-то до центра. Бродкаст, если он кого-то так волнует, потому что меня нет, я бы резал ACL на домах.Тогда бы это был чистый L2, юзера бы видели друг друга всегда, сеть управляемая. Со шлюзом ситуация тоже понятна - он один, в ядре. Вообще, вопрос как строить сеть ВЛАН на юзера или ВЛАН на дом и как лучше это делать - холиварная. Не только на форуме, но и на сайте было сломано копий, не счесть. Так что единственное правильное решение тут - всё читать, изучать и строить свое решение. По мере возникновения вопросов, задач при проектировании задавать вопросы здесь. И сразу будет понятно какой из методов какие имеет недостатки, как с ними справлятся и подходит ли конкретный метод вам. Хотя даже так можно начать холиварить. Перечисленные вами задачи в ответе весьма обобщены. Конкретно там звучит только защита от DHCP. Всё остальное можно сделать разными способами и оно будет работать. Даже НАТ, несмотря на очевидность вопроса, можно сделать кучей способов в куче мест. Некоторые крупные сети НАТ делают еще до брасов, на узлах агрегации. И это получается выгоднее при их размерах. Так что если хотите решить задачу, задавайте конкретные вопросы и задавайте исходные данные, потому что даже решение конкретных вопросов в любом случае зависит от ваших размеров. Я уже не говорю про актуальность.

2wtyd: В профайлинге видно, что процессор ест не нат, так что либо убрали и помогло, либо не убрали, но он и не мешал. Что трекинг, что НАТ на 200Kpps вообще не напряг для данной машины. 2wired: По крайней мере картина расхода теперь у вас есть. К сожалению, я не знаю что это за функция такая и за что отвечает - не сталкивался. Послушайте что говорит nuclearcat, ну + гугл. Я думаю решение найдется.

Дело в том, что правильного решения вопроса не существует, в противном случае существовал бы рецепт универсального счастья как построить сеть. Если говорить конкретнее, по 1), то можно в точке агрегации ВЛАНов сделать шлюз, тогда он будет один. Если Вы хотите ВЛАНами разбить еще и логику, читайте на подсети, то вам тогда нужен шлюз для каждого ВЛАНА. Работать будет и так и так. Не зная ваших задач давать какие-то рекомендации тут сложно. Не случайно ведь каждый решает свою задачу по-своему. Касательного 2). Если получается сделать NAT+шейпер на брасе - это будет замечательно. К сожалению, иногда НАТ приходится выносить ближе к ядру сети в силу того, что если сделать НАТ сразу нельзя собрать нужную статистику/решить промежуточную задачу. Вы описали очень мало для того, чтобы вам советовать что-то конкретное. Тут и от биллинга многое зависит и от пакетов и от целей которые вы перед собой ставите. Это всё не освещено в теме никак.

Вы задали весьма общий вопрос, потому как данные задачи каждый решает как ему удобно. В часности 1) и 3). По 1) у меня коментариев нет, а по 3) - это вообще специфика вашего биллинга. Если он поддерживает радиус - делайте радиусом, если нет - прийдется изобретать костыли. По 2): мне кажется правильно, когда БРАС сразу шейпер. Это легкомасштабируемое и достаточно гибкое решение. Ставить шейперы ближе к границе сети экономически не выгодно. Хотя, возможно, у кого-то есть и обратный опыт.

Позволю себе вставить свои 5 копеек: Могу сказать, что Вы явно что-то упускаете. 200Kpps для такой машины - это чих. Самый крутой и правильный способ узнать что делают софтирки - это сделать профайлинг. Может у вас там шейперы, может iptables в таблице filter содержит 1К записей, может еще что. Тюнинг на уровне параметров ядра тут мало чем поможет - нужно выяснять что делает ядро с пакетом. Трансляция адресов, о которой тут говорят происходит per flow и для 200Kpps её вообще не видно. Впишите хоть 1000 правил. Тут советовали увеличить ринг - это глупости. Чем меньше ринг, тем быстрее работает сетевое устройство. Увеличивать его нужно только, когда начинают теряться пакеты, которым нет места в буфере. Поэтому идеально самый маленький, на котором нет потерь, с запасом. Но в вашем случае я бы ставил дефолт для диагностики. Что еще. 100К Interrupt Throttle Rate - это не ваш случай. Те кто советует ставить маленькое статическое значение - правы, но вам лучше пока ставить дефолты. Я вообще рекомендую все настроенные вами параметры сбросить в дефолты, поставить профайлер и посмотреть. К сожалению, не вижу какой у вас дистрибутив, но во всех нормальных серверных дистрибутивах настройки по умолчанию решат вашу задачу на вашем железе без проблем и без напильника. Там потом надо будет подкрутить немного настройки ядра связанные с очисткой conntrack но на данном этапе я бы даже это не трогал, если ядро не ругается в лог, что кончились таблицы. Я помню очень долго боролся на одной машине с софтирками и что только не крутил и что только не проверял. Профайлинг за 2 минуты показал, что всё жрется фильтрами шейпера, которые из-за ошибки в скриптах генерились сотнями в виде дублей. А на первый взгляд шейперы были здоровы. Так что бросайте крутить ядро и iptables, берите профайлер, смотрите и нам показывайте.

Если вам не нужен RPS, я бы откатился на 2.6.27 ядро. Где-то в инете пробегали графики бенчей, где на одинаковых конфигах ядер теребили апач на высокую загрузку. Так вот из всех тестов 27 ядро было с большим отрывом впереди. Ядра тогда были до 32 версии. Ну и там гарантированно SMP Affinity работает.

Поздно увидел тему, жаль. Железки наверное уже отдали. Нигде не видно версии ядра. Там в предпоследних 2.6.3х были проблемы с НАТом. Как раз где-то около 4Гбит уходило в панику, а если нагрузка порядка 3Гбит, то уходило в панику в течении суток. Как с последними ядрами - не знаю, но после 2.6.27 сильно поползла вниз производительность сетевой подсистемы. Я жду пока вылижут. Далее не видно профайлера, что именно отъедает на ядре 100% в очереди. Я тоже заметил что загрузка очередей на прием распределяется не равномерно. Видимо тут играет политика распределения драйвера. У меня такого не было, что упирается одна очередь в ядро, но если бы было, я бы написал в лист интелу - думаю они ответили бы оперативно - такие тесты для них интересны. Но в любом случае, если вы ищите решение и это не подходит, то лучше пробовать что-то другое. Обработка напильником может затянуться и не дать нужного результата.

А покажите "vmstat 1" и как трафик по интерфейсам расходится? То есть работает ли боддинг? И давайте выберем какую-то одну машину для выяснения, например те же Ксеоны.

Пожалуйста. Рад что помог. Вас еще ждет увлекательное путешествие в мир хешированых фильтров, чуть позже, когда нагрузка будет расти.

Ну если гарантировать какую-то полосу 1:90 не надо, то задача решена. Можете даже не стесняться и дать классу 100% цейла, а то из-за 15% недостающих могут начать возбуждаться клиенты.

То есть есть, скажем 3 класса: 1:2 rate 2Mbit ceil 3Mbit И два лифа: 1:10 rate 1Mbit ceil 2Mbit 1:20 rate 1Mbit ceil 2Mbit Кстати попробуйте еще в вашей текущей схеме дать rate 1Kbit для класса с торрентом. У него тогда корзина должна быть мелкой и при мелком кванте он может не продавить http.

Ну вот теперь на этой простой конфигурации и откатайте то решение которое хотите внедрить. Попробуйте схему 2+1 о которой я писал выше. Клиенты займут для сайтов чуть больше полосы, но зато тормозить оно у них не будет и если начнется кач с обоих источников, торрента и веба( маловероятно ), то клиенты не заберут больше 3х Мбит. В основном же они будут сидеть в своих 2х Мбитах. Решение - не фонтан, но тем не менее. Попробуйте еще покрутить quantum, и убрать любые бурсты классу с торрентом и cburst корневому классу. Может отдаст хотябы какой-то процент своего класса. Целиком загнать его в рейт можно будет только множественными потоками в http классе, которые будут вести себя так же по-хамски как и он сам.

Если распределение полос будет нормальным, значит в конфигурации с мудреными фильтрами что-то плывет. Я же думаю, что торрент отберет свой цейл, т.е. почти всю полосу, вместо 25%.