Dark_Angel

Ну тут однозначно сначала надо избавится от любых ошибок, вне зависимости от того кто растет быстрее, а кто медленее. А то такое ошибки "связанные со слишком маленьким размером кадров"?

2bos9: Ситуация странная, согласен. Посмотрите ошибки на порту свитча. И покажите что за машина и сетевая у вас. Если количество пакетов = количеству прерываний, значит NAPI не работает, но это не значит, что он не включен в драйвере. Для современных машин всетаки 10К pps - это мало, вполне можно обходится и без NAPI. Проверить умеет ли драйвер NAPI можно по его инфе, как модулю. modinfo e1000. Сейчас современные драйвера все идут с NAPI. Чтобы его отключить - нужно специально это указывать при компиляции. 2telecom: Покажите ring buffer и посмотрите ошибки на свитче. Ну и кстати у Вас количество ошибок = 0.0018062%. Уверены, что хотите тратить на это время?

struct e1000_info e1000_82574_info = { .. FLAG_HAS_MSIX, pba = 32 Неплохо Даташит даже врет, что 40. ich8lan.c * 82566DM Gigabit Network Connection ... struct e1000_info e1000_ich8_info = { (если не ошибаюсь это именно ich8) <------>.pba<--><------><------>= 8, PBA 8k, что мало. В этом и соль, почему десктоп адаптеры сливают. Мы с Вами уже это обсужали, наверное даже в этой же теме. Я привел пример с 82566 специально, чтобы показать, что фичи драйвера и железа - это не есть залог успеха. Не всегда. Если прерывания отработали слишком медленно и карта ждала слишком долго, маленький PBA сыграет свою роль. Я считаю, что это очень редкий случай, на скоростях выше гигабита, наверное, встречается. Обычно всё упирается в то, что система не может генерировать столько прерываний, чтобы выгребать буфер своевременно. Кстати, как можно проверить, что бефер переполняется именно за счет медленных прерываний? А разве в случае узкого класса и дропа пакетов лезет в топ ksoftirq? Не верю. Не верю, что 800 (!!!) правил iptables не влияют на загрузку ядра. Не исключается, конечно, вариант, что ложит что-то другое, но тогда Вам правильно советуют профайлер. Для ядерного netflow - это семечки. Кроме того, его статистика доступна через обращение к драйверу. Посмотрите загрузку там. Мало ли, может не правильно настроен. Поможет, просто Вы будете изобретать свой велосипед, вместо уже существующего.

2Dyr: Потому что Вы не внимательно читаете. Чем меньше значение, тем больше прерываний, а не наоборот. Если у Вас при изменении этого параметра ничего не меняется, вероятно ваш драйвер не поддерживает динамическую смену параметров. Тогда меняйте через ITR в параметрах драйвера. Или меняйте драйвер. 2seagull: 800 правил в iptables? Так у вас еще всё круто работает - гигабит жует. Курите ipset или убирайте оттуда правила. Это основная причина. Рассматривалось в этой и других темах. Если коротко, то разнос по ядрам более еффективен из-за того, что более еффективно используется кеш процессора, когда одна очередь, еще лучше гибридная, по этой же причине, обрабатывается на одном и том же ядре. Не поможет.

Поэтому я и говорю: прибивайте прерывания статикой и смотрите, успевает ли система. Чтобы начать, расчитайте количество прерываний так, чтобы размер пакетов в буфере на момент прерывания было в 2 раза меньше размера буфера. Ну и дальше танцуйте - больше/меньше. Максимум 100К прерываний в секунду на очередь. Желаю Вам приятно провести время.

Intel Core i3-530. На 650+250mbps и 80+70kpps загружен на 45+5+50+15%. Круто, но у человека Ксеон. Я не против что Ваш проц похож, прожевывает такой же трафик, но он другой. Как можно так сравнивать? Мать другая соответственно. Я абслютно уверен, что переполнение буфера и ошибки возникают из-за малого количества прерываний. Плавал уже. У вас система позволяет их делать больше - потерь нет и всё круто. Там не позволяет делать сколько надо - будут ошибки. Почти угадали :) Это внешняя двухпортовая Intel/PT, купленная пару лет назад за $200. Бюджетная за $10 - это скорее встроенная 82579V. Да, прошу прощения, я ошибся в цифре и неверно написал. Имелась ввиду 82574L, 82751 - EB же. Единственное, чего в 571 нет по сравнению с 574 - MSI-X. Всё остальное - MSI, Throttling, Interrupt moderation - есть и работает. Гигабит реального трафика пропускает без малейших проблем. 82566DM - тоже имеет все эти фичи и стоит 10 баксов. Начинает ронять пакеты при 500-600 Мбит трафика на дефолтных настройках. На не дефолтных можно прогнать гигабит дуплексом. Вот только скажите, сколько стоит то время, чтобы так настроить систему и сколько стоит нормальная сетевая, скажем тот же 82575EB который на дефолте всё это сделает? Так что MSI, Throttling, Interrupt moderation - не залог успеха. Смотрите внимательнее - Dyr уже использует 82574, не должно с ними быть никаких проблем. У меня нормально работают и набортные 574, и внешние 571. Я не против, что на 82754 можно прокачать гигабит, но нужно поработать напильником. Кроме того, возможна ситуация, когда система не сможет выгребать буфер карты настолько часто, насколько это нужно, чтобы он не переполнялся, т.к. с этим связаны накладные расходы. В вашем случае система мощная или настроена так, что успевает. У Dur, видимо, драйвер решает, что больше прерываний не надо. Поэтому я и говорил избавиться от дефолтовой модерации. Буфер на всех картах установлен в максимум = 4096. Прерываниями занимаются throttling и interrupt moderation. 80k потерь на 28 миллиардов пакетов - в пределах статпогрешности. Я по поводу ваших характеристик сказал, что у вас всё ок. Насчет прерываний автоматом я уже говорил: бывает, что на дефолте драйвер правильно видит паттерн трафика, и подбирает количество прерываний. А бывает, что не правильно. Вам повезло, а Dur - нет. Вы используете относительно новое ядро. Данная версия драйвера уже есть 1.6.х. Стоит обратить на неё внимание. Ну и по-моему вкомпиливание драйвера в ядро - это лишнее. Никакого выиграша это не дает, зато чтобы обновить драйвер надо пересобирать ядро и перегружать машину. Не фонтан. Если бы упиралось в iptables - ядро бы сидело в топе, нашим любимым ksoftirqd. На сколько я понял - это не наблюдается, соответственно пакеты теряются еще до ядра. Верно, но, Dur, обратите внимание, что 1,2,3 - это те же режимы модерации, что и параметры для драйвера ITR, остальные значения - это статическое количество прерываний на очередь.

Всё очень условно. Ни версии драйверов, ни ядра Dur не указал. Процессор не указали Вы, при этом у вас обоих автоматическая модерация прерываний. Но и это не все отличия. У вас 4 сетевые, у него 2. То есть формально всё похоже, а на практике куча различий, которые могут давать такой еффект. Кроме того, важно понять: пока у карты буфер не начал переполняться, ошибок вообще не будет. А потом они резко полезут, хотя трафика стало не на много больше. Ведь не ясно, как у вас выходящий трафик распределяется между указанными сетевыми. Вообщем я бы не брался сравнивать. 82571L - это бюджетная сетевая за 10$, соответственно чтобы она проглотила 1 гиг - её надо пилить. Именно отсюда пожелание поменять сетевую. После смены ничего делать нужно не будет.

Это Вы отписываетесь уже по своей проблеме или Вы вместе с Dur? В любом случае у вас rx_no_buffer_count: 81676, что говорит о маленьком кольце или о недостаточном количестве прерываний на карту. На коммутаторе будет видно ошибки CRC ну и про буфер тоже, если включен flow control, который обычно для бордеров отключают. Всё остальное не видно. А если патчкорд битый, то проблемы видно и невооруженным глазом. Но вообще, сумма ваших всех ошибок по приему пакетов - это 0.000003333% от общего числа принятых пакетов. Овчинка выделки не стоит. А вот у Dur ошибок достаточно много.

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

2 NiTr0: Немного оффтопика. Я за чистоту бордюров, то есть чем меньше правил, тем лучше. В идеале вообще нет. Чтобы не было ситуаций, когда одно из правил начинает выносить машину, и чтобы это выяснить надо тратить время и терпение клиентов. Ведь всё можно резать на брасах и им уж точно плохо не будет, т.к. их, если что, можно отключать не нарушая сервис. Поэтому, когда я вижу рекомендации "та нормально", я немного негодую. Понятно, что 2-10 правил на бордере погоды не сделают, но зачем плодить бардак? Можешь зарезать на брасе - реж там. На бордере всегда удобнее резать, т.к. их один-два, а брасов может быть много и везде надо реплицировать. Только это, мне кажется, оправдание. Тот же торрент, надо резать на брасе или даже на аггрегации, если есть возможность. Или еще круче, прямо на доступе. Чем ближе тем лучше. Я вообще не вижу таких правил, которые надо поставить на брас и которые нельзя применить ближе к клиенту.

Только не догадайтесь резать на бордюре. Вообще выносите фаеры оттуда на брасы. Шейперы желательно тоже. Если все настроите правильно, то вы загрузите двухпортовую 82576 полностью и еще на такую же останется.

Ну, я думаю, что понадобится обработка напильником.

Посмотрите тут http://et.redhat.com/~jmh/tools/xen/itop

У меня на гигабитном интерфейсе стоит 512 байт, только что проверил. Правда модерация прерываний осталась на автомате.

Только прием/отправка. Ну туда еще другие устройства, кроме сетевой входят, очевидно. Скажем каждое ядро имеет локальный таймер ( LOC ) который делает 1К прерываний на каждом ядре. Есть полезный top для прерываний, называется itop. Но по факту, выставляете на карте жестко прерывания, проверяете, что настройки применились и потом только смотрите, чтобы буфера у карты не переполнялись. Потому как малое количество прерываний может приводить к такому эффекту при большом трафике. Еще из тюнинга, можете поиграться с буфером кольца. Рекомендуется уменьшать его пока не начнутся ошибки на интерфейсе, затем сделать x2 и оставить. Когда кольцо вырастите до максимума, начинаете увеличивать количество прерываний. Ну это если забегать вперед. На трафике порядка гигабита на порт, я думаю вы разок настроите и забудете, как это в свое время сделал я.

Я думаю, что если уберете прерывания, то будет еще в 2 раза меньше.

/sys/module/nf_conntrack/parameters/hashsize Он же net.ipv4.netfilter.ip_conntrack_buckets = 16384

2NiTr0: Может и так, но активных слава Богу не много. Могу судить по просмотреному flow - 10-20К сессий для активного за час видел. Это топовые. По hashsize пишут, что CONNTRACK / 8 формула. У меня раньше тоже был 512К на 128К соединений. Сделал 16К. К сожалению, тогда машина загружена не была, поэтому оценить еффект не смог. Сейчас работает по той же формуле.

Раз уже дергаете интерфейс, то поставьте по-нормальному через параметры драйвера. Может этот rx-usecs и то что надо, но у меня нет объяснения почему он у меня в таком случае равен 3, хотя настройки совсем другие. Поэтому чтобы наверняка - ставьте параметрами при загрузке драйвера. Насчет драйверов, то рекомендую проапдейтить ядро, если у вас до сих пор r4. Ну или поставьте уже последний драйвер из ветки 2.х. Кстати гугл говорит, что rx-usecs - это все же настройки сетевого кольца, а не политики модерации прерываний. То есть на количество прерываний эти настройки влияют, конечно, но мы же говорим о других параметрах? Поэтому лучше верните его как было, т.е. 3.

Возьмите драйвер посвежее. Интел там не только новые фичи вкручивает, но и оптимизирует. Он уже как минимум 3.2.х Не уверен, что rx-usecs - это именно режим работы драйвера. Вот мой: При этом: И больше прерываний не будет, т.к. я прибил статику. Поставьте драйвер посвежее, там этот параметр можно прямо указывать по идее, без всяких делений. Подсказать не могу, потому что у меня самого драйвер 2.1.9. Ну и еще. Плавающая нагрузка вас не должна волновать. Когда ядра пригрузят - она плавать не будет. При общей нагрузке системы ~10% она может плавать - не обращал внимание. Тем не менее нагрузка у вас снизилась вдвое, если количество пакетов не изменилось, но 50К прерываний - это всеравно много.

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

Если поставили дефолтное, то там динамическая система определения прерываний. Обычно дравер пытается сделать их как можно больше, чтобы пакеты улетали как можно быстрее. Тогда количество прерываний = количеству пакетов. NAPI начинается, когда система начинает захлебываться от прерываний, или драйвер решает, что трафика много и надо его включить. Я значение по умолчанию использую на обычных серверах и десктопах. На роутерах выставляю руками. Моя рекомендация в данной ситуации, поставить статически 1К на очередь, если очередей 8. Будет у вас в 12 раз меньше прерываний в вашем случае. Я считаю, что это будет еффективнее. Дальше уж сами смотрите как хотите. Мне кажется последние версии драйвера умеют менять этот параметр налету через ethtool. Я думаю, что там же его можно и прочитать.

А что показывает vmstat 1? Вообще, для большого количества ядер лучше прибивать количество прерываний руками. Скажем в сумме должно быть 8К прерываний. Соответственно если у вас 8 ядер и все с очередями, сделайте ITR = 1000. А то их дрвайвер по умолчанию наделает вам кучу переключений контекста.

Да, можно порезать. Таймауты на ожидание можно не больше 30 сек. выставлять. Это кардинально ситуацию не поменяет, но будет легче. Резать сессии клиентам вообще не хорошо. Лучше выяснить что за трафик и тогда уже думать как принимать меры, потому что явление может быть массовым, как например тема про торрент. Технически это можно легко и непринужденно сделать через connlimit, но тут нужно понимать, что с таким правилом, из-за торрента, например, клиент может не открыть или открыть кривой страницу в браузере, потому как часть соединений браузера будет отбрасываться.

Скажем так, я считаю, что абон без торрентов больше 20-30 соединений держать не может. С торрентами, ну пусть будет 100-200. Всё, что дальше можно резать, если прижимает. 1К - это явно либо торрент, либо вирус, что в принципе одно и тоже.