Dark_Angel

Это гибридные очереди. Рекомедуется использовать именно их, т.к. Tx обычно очень дешевый, а Rx наоборот - дорогой. Поэтому я бы ничего не менял. Кстати в этой теме это уже обсуждалось.

У меня лично в продакте нет 3.х, но люди в соседних ветках, говорят, что по сравнению с последними 2.6 - 3.1 подфиксили сетевой стек. Ну и немного подтюнили. Поэтому посуществу сказать ничего не могу. ITR надо подбирать исходя из параметров трафика. 500K pps - это 25К на очередь, или 14 Мб данных ( при пакете 600 байт ). Посмотрите сколько PHY идет в вашей карте на очередь, чтобы увидеть как быстро будет переполняться буфер без выгребания. Потом даете двойной-тройной запас и проверяете. Обязательно смотретите потери в этом случае. Обычно, я выставляю 2К прерываний на очередь, и жует до полки в порту. Иногда надо ринг подкручивать. Вообщем пару Мpps должны прожевать после этого. Но я все же бы на вашем месте попробовал собрать на стенде 3.1 и прогнать синтетику. Я когда тестил ядра 2.6, у меня лучше всего получалось на 2.6.27. Вот на нем и плаваю.

Я бы начал только с ITR. Увеличение ринга, если нет потерь делать не нужно. Может получиться бОльшая нагрузка из-за cache misses. 200К прерываний, то есть по 10К на очередь - многовато, а в топе у вас всеравно ядро да драйвер. Тут много не натюниш. Разве что пробовать ядро тянуть до 3.1. Но на продакшене ссыкотно же.

Там же не просто гейт, а шейпер и фаервол наверное будет не в одно правило. Поэтому на гиг лучше крутить на нескольких процессорах. 4 гибридных очереди на порт с головой.

82575 тоже сгодится, если найдете.

Соглашусь, про PAE и память никто ничего не говорил. Похоже таки дело в PAE, т.к. vmlinux-2.6.32-5-686-bigmem. Суфикс bigmem кагбэ намекает. Но от себя дополню: поменял бы и версию ядра сразу же заодно, раз прийдется перезагружаться. 2.6.32 все же имеет ряд проблем устраненных в более поздных ветках. Согласны?

Смену ядра рекомендовали еще на прошлой странице. Очевидно, что на роутере виртуальные ядра должны быть отключены и не должно быть PAE. Аргументом тоже было то, что в топе профайлера только функции ядра. Человек вместо этого оптимизировал iptables.

Всё хорошо, вот только обработка правил в таблице NAT делается не per packet, а per flow. Поэтому запихните туда хоть 10К правил - ничего не изменится, если количество новых потоков не будет очень большим ( дестки и сотни тысяч в секунду ). По поводу оптимизации iptables - это всё мимо кассы. Профайлер про iptables вообще ничего не говорит, поэтому оптимизировать можно всегда, но в данной ситуации - это будет потраченное время, т.к. проблемы не решит.

Тогда берите ядро 3.1. Ребята в соседних темах пишут, что там всё ок. Таймауты порежте. Особенно те которые на ожидания пакетов на разрыв - макс 30 сек. Timeout established - поставьте меньше. Но я думаю, что максимальный еффект будет именно от смены ядра. 2.6.32 имеет пачку проблем именно с производительностью и стабильностью. Не знаю как сейчас, но раньше с него стремительно бежали. Профайлер тоже тыкает пальцем на функцию ядра. И обратите внимание на классификатор u32 в профайлере. Он не должен быть на 3ем месте если фильтры построены на хешах.

Если у вас никаких извратов типа ifb нет, то я бы взял последнее 2.6.27.

2.6.32-35 Не очень удачные ядра. Либо ползите выше, либо ниже. Там авось и показания прийдут в норму и меньше напильника надо будет. Гиг должен завестись без танцев с бубном на свежих или старых ядрах. Ну разве что НАТ надо всеравно подкручивать.

Это когда другие процессы ожидают когда освободится какой-то лок. На сколько я понимаю, у вас в системе где-то есть узкое место и у него собственно всё и упирается.

2taf_321: Не советуйте то что не пробовали. Прибивать карты к ядрам - ОБЯЗАТЕЛЬНО. irqbalance для балансировки карт ОБЯЗАТЕЛЬНО отключать. Об этом даже написано в мануалах к драйверам Интел. Обсуждалось даже по-моему в рамках этой темы с примерами. 2muchacho: А какая версия ядра у вас? Ну и 100K записей при 63Kpps - это много, сразу скажу. Как и 100К прерываний при таком трафике.

Ну и никаких проблем у вас быть не должно. Кстати в чем проблема использовать более старые или новые ядра? В соседней теме пишут, что 3.1 ветка ведет себя вполне сносно при больших нагрузках.

Их тех очередей, что я тестировал - SFQ давал самые хорошие и честные характеристики по лимитам. Говорю о пинге, дроп рейте и полезной полосе со стороны клиента. Ну и среднезатрано по ресурсам. Мне кажется оптимально. Правда тогда еще не было uTorrent с мелкими UDP, может сейчас ситуация изменилась и надо юзать другие очереди?

+1 за SFQ. Тоже используем и всё работает как задумано.

Упадет ли нагрузка - не знаю, скорее всего нет или на уровне стат погрешности, но распределение ресурсов будет заметно лучше, т.к. если где-то резко понадобится полоса ( например ДОС снаружи ), вы не упретесь в полку бондов по 2 порта. Я уже не говорю о случаях, когда один из портов/патчей по какой-то причине ломается и одно из направлений сразу деградирует. Другой вопрос, что стоит на той стороне бондов. Если разные железки, тогда не получится. Если одна - то я не вижу ниодного аргумента не сделать 1 интерфейс вместо двух. За советы по ядру спасибо, но где-то на этих ветках ( 32-34 ) были проблемы с НАТом выше 3х Гбит. Ядро паниковало раз в сутки примерно. Где-то даже была тема здесь про это. Нет у вас НАТа на 33 и чтобы больше 3х Гбит?

MTU точно таким не должен быть, верните взад. Насчет сетевой - замена с большой вероятностью поможет, да, но мне кажется, что тут проблему можно решить без замены. Flow control включен? Если да, то выключите. net.core.netdev_max_backlog=8192 net.ipv4.tcp_max_syn_backlog=1024 Поставьте человеческие очереди, пакетов эдак на 300-400К. Ну и не забудьте про очередь на конкретном интерфейсе. Ну и я бы откатился на 2.6.27, потому что пахнет полтергейстом. Кстати, Вы говорили, что до тюнинга потерь не было. Пробовали скидывать всё на дефолт? Проблема остается?

Не знаю в чем причина. Не хотите попробовать откатиться на 2.6.27? то есть я правильно понимаю: выполняется 64К прерываний, система не перегружена, но пакеты теряются? Кстати, а что это? MTU 9198 bytes

На порту коммутатора точно ошибок нет, потому что я видимой причины ошибок не вижу?

а откуда у вас rx_csum_offload_errors: 4254 и не увеличиваются ли они с missed_errors? Сколько прерываний выполняется? На сколько я вижу CPU1 вообще без сетевых сидит, зато CPU3 аж с двумя?

Поищите, я думаю, что найдете. Я тогда 82576 купил из-за жадности, думал, что 4 очереди не хватит. В целом, зависит от задач. Если это не бордер, а какой-нибудь шейперо-фаер, то может оказаться, что и 8мь очередей мало. Для моих же задач, да я думаю и для всех в основном, 4 очереди - навалом.

Да, за 80 были, когда покупал 82576 себе. Нарыл в Инете поставщика, который под заказ привез, правда партию 82576. Сейчас контакты не найду, к сожалению.

2yannails: Посмотрите ошибки на порту коммутатора. Ошибки в чексуммах обычно возникают именно на стыке. Вернее сказать, я других ситуаций, когда они возникают, - и не знаю. 2telecom: Бурное обсуждение начинается, когда предоставляются все данные. Когда данные в расследовании проблемы приходят отрывками, помогать очень сложно, если вообще реально. Я вас попросил показать буфер _и_ состояние порта коммутатора. Вы показали ринг и всё. Ринг обсуждать нечего, показывайте коммутатор. Насчет карт посмотрите в сторону 82575 еще. Это младшая модель 82576 и имеет по 4 очереди на порт ( вместо 8ми ). Стоит в 2 раза дешевле. Гиг прожует без вопросов, если CPU хватит. Я бы рекомендовал брать именно 82575, 82576. С ними сон дежурного становится гарантированно приятным и продолжительным. Насчет ядер, то если не надо фичи ядер старше, я бы рекомендовал оставаться на последних версиях 2.6.27. Там всё гарантированно нормально работает, и главное, быстро. Если надо, то начинается свистопляска с отдельными боками разных версий. Где-то НАТ укладывает машину на 3х Гбитах, где-то проблемы с бондингом, где-то проблемы с шейпером. Если кто-то нашел ядро посвежее и стабильное, а главное быстрое - расскажите.

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