Dark_Angel

Тут вариантов очень много. Если ничего не менялось в софте, значит изменилось снаружи. Если есть автоматизированные скрипты ( например добавление вланов ) возможно они дали сбой и нагенерили кучу хлама. Вырос трафик? DDoS? По двум приведенным строчкам из перфа не понятно что случилось и тем более что изменилось в неизвестной системе.

Страница 287 DS описывает как подсчитывается хеш для пакетов IPv4. Если коротко, то там тот же MSFT RSS. То есть туннелированные пакеты всегда попадают в одну очередь. Страница 670. Та же шляпа - MSFT RSS.

Да, csum_err - это ошибки L3/L4. Посыпаю голову пеплом. Решение рисовать графики, по-моему наиболее информативное. Всегда можно понять, когда началось.

А я и не говорил, что проблема только с кабелем. Замена кабеля - это самое простое что можно сделать. В некоторых ситуациях помогает. Когда не помогает пристально смотрим на свитч - не дает ли ошибок на других портах. Если нет, то можно поменять порт ( иногда помогает ), иногда приходится перепаивать конденсаторы цепи питания, но это уже хардкор. Не знаю, парни. У меня на здоровых инсталляциях ошибок - либо очень мало ( не видно, как увеличиваются ), либо 0. Битые пакеты из Интернета - будут отсекаться свитчем, т.к. это L2 и он тоже не будет принимать битые фреймы. Так что до роутера они даже не будут долетать. Если конечно роутер не подключен напрямую во внешку. В ситуации с оптикой не знаю что сказать. Битые фреймы и там могут быть, но как такое лечить, я не знаю. Вполне вероятно, что так же как и на меди. Одно я знаю точно - ошибки на интерфейсе - это не нормально в тех объемах которые мы тут обсуждаем. E-10, E-12 еще можно допустить, но 0.002% или 0.0002% - это много. Их быть не должно. Наличие ошибок свидетельствует о том, что какое-то оборудование функционирует не нормально. Другой вопрос, что ошибки находятся в допустимых для вас пределах.

Все верно и даже более того, разные версии одного и того же драйвера могут считывать показания карты в разные счетчики. Но в данном случае всё просто: rx_csum_offload_errors - это стопудово железная проблема бьющихся кадров. Я с ней сталкиваюсь периодически, особенно на 1Г по меди. Обратите внимание, что это счетчик без очереди, т.е. кадр отбрасывается еще до конвеера, где на него выставляется указатель, который определяет его движение в очереди. Рост ошибок в таких счетчиках как правило всегда проблемы с железом. Пруф по данному счетчику: http://comments.gmane.org/gmane.linux.drivers.e1000.devel/9507

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

Ну еще можно использовать тарегет SAME с ключем --persistent. И тем самым дать возможность системе самой рулить пулом. Но вопрос странный, т.к. очевидно, что лучше натить одной строкой. А дальше уже в зависимости от потребностей. Меняйте патчкорд. Эти ошибки означают, что к вам прилетают битые кадры в порт. И тут не много вариантов: либо бьет отправляющий порт ( например порт подгорел ), либо бьет патчкорд ( плохой контакт ), либо бьет принимающий порт. Начните с простого - заменый патча.

Так а что у вас за проблема которую вы пытаетесь решить?

А вообще имеет смысл ставить тиклесс ядро на роутер? Мне всегда казалось, что это фича для мобильного железа.

Ну и как он по ощущениям, 10Г через него прокачать можно будет? Пока момент с питанием отбросим.

Всетаки Zimbra с 2G чувствует себя не особо даже на малом количестве клиентов ( что-то типа 10К писем в день ). Вылазит в свап и может нагружать диск, когда наступает крон. Лучше всего 4Гб. Зато поставил, настроил и забыл. Странно, что этого комплекса нет в голосовании.

Крутые ссылки, парни, спасибо. 2NiTr0: тогда понятно почему сервера на АМД стоят дороже, на них спрос меньше. А десктопные версии процессоров от АМД тоже с этой проблемой? Где-то видел обсуждение о роутере на AMD Phenom X6 1090T. 6 ядер, хорошая частота, набортный контроллер памяти. Обсуждение правда было скучное, без цифр. Никто не пробовал?

А где можно про это почитать? Не про саму проблему, а про проблему и решение в 3.6+. У меня бывали и не такие ситуации на ядрах после 2.6.32. Там после 2.6.27 начали сильно пилить сетевой стек и далеко не все версии ядра были удачными для разных задач. То есть на одном роутере всё нормально, на второй ставишь и процессор в полку. Более менее всё нормально, по-моему, стало после 3.2.23. То о чем я говорил, это то что если машина на текущем ядре, отрабатывает по примерно заданным параметрам ( а у ТС всё именно так ), то замена ядра существенных улучшений не внесет, а проблем может прибавить.

Мы случайно не путаем RRS ( ??? ) и RSS ( Receive side scaling ), т.к. второй нужен обязательно и всё как вы говорите, а что такое первый я найти не могу.

Ну между 2.6.27 и 3.6 там вообще кучу всего переделали. Другой вопрос, что на скоростях до 10Гбит включительно, 2.6.27 показывает себя не хуже чем новое ядро. Там, наверное, есть разница в несколько процентов, может даже в 10%, в производительности, но вот существенной, чтобы прямо сейчас всё менять, я не заметил. Я не к тому, что новые ядра пробовать не надо, но все же не в продакшене. А расскажите в двух словах, что не так было с Route Cache? И как его отсутствие влияет на производительность. Я ж так понимаю, что его чем-то заменили?

Просто выше по треду автор говорит, что в профайлере именно ipt_NETFLOW портит кайф. Насчет RRS/RPS уже вижу вы не в первый раз пишите об этих механизмах, которые по умолчанию отключены. Не вижу ниодной причины их включать, если стоит нормальная сетевая ( а мы же в теме про софт роутеры ), которая имеет много очередей. Я не прав?

Спасибо за детальное объяснение работы ipt_NETFLOW. А как тогда из профайлера понять что такое ipt_NETFLOW? Получается, что никто кроме экспортера это быть не может?

Я другого и не говорил. src-dst-port-time - это и есть соединение. В данной ситуации аггрегация будет по времени. То есть если у меня за период аггрегации будет 2 соединения с одним и тем же src-dst например на порт 22, то у меня будет 1 строка во флов. Без агрегации - 2. Поправьте если я не прав. У меня такое же наблюдение, но автор говорит о том, что пакеты размазываются, а вот генерация флов - нет. Кстати, а модуль ipt_NETFLOW самособранный? Может он как-то криво собран? Как же тогда получается, что пакеты обрабатываются на всех ядрах, а ipt_NETFLOW всё на одном? По вашей логике всё должно размазаться.

Я тут думаю зайду после выходных почитаю тему, в ожидании увидеть очередное обсуждение количества ядер или размер буфера, а тут МЯСО по коннтраку. Спасибо junjunk2, интересный эксперимент. Спасибо что провели, оформили и поделились. Все бы так. Выяснили, что /8 пока решает. Тут я согласен aabc, который подробно всё расписал. Судя по всему соотношение /8 является оптимальным. Более того, не забываем, как производится поиск по хешу, там скорее всего B-tree ( или что-то умнее ), и как только символ не совпадает, мы переходим на следующую ветку дерева. В этом случае слишком короткий хеш будет давать очень длинные ветви по которым нужно долго спускаться, не смотря на то, что значение самих листьев не значительно и влазит в кеш. Длинный же хеш делает больше ветвей, но сами они получаются короче, и как следствие, проходятся быстрее, хоть и занимают больше памяти. Я не говорил о двухкратном приросте, речь шла именно о 4х ядерной системе для трафика больше 10Гбит. Так же обращаю ваше внимание, что я тоже советую ТС разнести нагрузку на 2 железки. А есть какие-то тесты? Потому что на сколько я помню, АМД первые начали ставить контроллер памяти на кристал с процессором, что как раз нивелировало эту проблему. О размере буфера и ITR. У меня бывали случаи, когда динамический ITR начинал творить треш. Типа 1К прерываний на ядро, при куче трафика и другие не понятные вещи. Бывало, что он работал нормально ( разные версии драйвера ). Динамический ITR умеет два режима: 70K при низком трафика ( почти realtime - пакет, прерывание ), или 40К ( при большой нагрузке ). Когда начинаются чудеса с потерей пакетов, я всегда перевожу тазик на ручной ITR. Это требует немного внимания, конечно, зато позволяет всё правильно зарегулировать и избежать проблем. Например, можно сделать минимальный буфер, и побольше прерываний, таким образом уменьшая задержку обработки пакетов ( там где это критично ), и по мере роста нагрузки буфер увеличивать. В общем случае, на максимально загруженой машине буфер максимален, а количество прерываний настроено так, чтобы при полной расчетной загрузке машины ( например DOS ), карта не теряла пакеты потому что кончился буфер. Но бывали ситуации, когда увеличение буфера до максимума устраивало перегрузку других подсистем и это было не еффективно. Так же нужно быть аккуратным с выбором мамы. Потому что можно уперется в шину PCIe. Ошибки типа rx_no_dma - это оттуда. Карта не успевает отдать все пакеты из буфера за прерывание и теряет их. Надо чтобы было PCIe v3 хотябы с 128 GT/s ( это 8 GT/s per lane ) для 16х. Если этого нет, то всё будет плохо. Можно, конечно сделать меньше буфер и чаще прерываться, но мы же все понимаем последствия этого решения. Насчет ядра ТС - согласен. Не надо ничего менять. У меня есть тазики на 2.6.27. If it's working, don't fix it. kipmi - это процесс IPMI. Не понятно только почему он ест процессорное время. Может кто-то ломится к вам на IPMI порт?

Все именно так. 180 правил достаточно много, но если они все у вас с исходящим интерфейсом, да еще и в построутинге, то они обрабатываются достаточно быстро. Не думаю, что удасться оптимизировать без изменения самой схемы адресации. Ну так и увеличите вместе с conntrack_max. Зачем держать запас? У вас кеш пошарен с L2. Intel Smart Cache же. Я не уверен, впрочем, что он сбрасывается полностью. Уже не говоря о L3. L1 точно сбрасывается, а вот остальные - не знаю. Но в любом случае таблица кусками попадает во все кеши. Целиком она ни в один из них не влезет, т.к. она слишком большая и есть более важные данные, которые нужны процессору прямо сейчас. Зато она точно находится в ОЗУ. Вся и целиком. И оттуда выгружается в кеши при надобности. Частота напрямую влияет на пропускную способность роутера. Поэтому чем больше частота, тем лучше. По количеству прерываний вы ошиблись на несколько порядков. Прерывание занимает больше времени чем один такт процессора. По факту, я не думаю, что современный драйвер вам даст выполнить более 100К прерываний на очередь. Да и не нужно столько. Поэтому да, вам нужно смотреть на E5, два процессора и чтобы камни были побыстрее. И память тоже побыстрее. Мамки с быстрой памятью стоят немного дороже. Если так хочется 20 Гбит, попробуйте i7 с 6ю ядрами. Там и кеша больше и вообще разогнать можно. Короче 20 Гбит реально пропихнуть. 2.5-2.7 Mpps. Но я бы лучше поставил вторую железку рядом. АМД я пробовал, но там не было такого трафика. В целом, АМД показали себя не плохо ( 2 процовая система ), но когда я последний раз искал железо, у меня получилось, что AMD будет стоить в 1.5 раза дороже сервера на Intel. Уж не знаю как так получилось. Поэтому пока на АМД не смотрю. Да и зачем, если на Интеле всё отлично работает и стоит нормально?

Если все так просто, то зачем тогда дефолтный буфер установлен в 512? Ставили бы стразу в 4096. А все потому что ваше утверждение ложно. Чем меньше буфер, тем меньше будет cache_miss при прерывании. В теме про софтроутер эта тема обсуждалась, с участием ядерного кота. Почитайте. Поэтому буфер нужно держать не максимальным, а поближе к заполненности, тогда это будет наиболее еффективно. Ну и да, чем больше буфер, тем реже можно звать прерывания, но одно дело обработать прерывания и достать из буфера 500 пакетов, а другое 4000. Моя практика показывает, что разница в производительности может достигать 10% между минимальным размером буфера и максимальным. На одинаковом трафике. Конечно зависит. Поставьте 16, и 1.5М соединений потрекать, и посмотрим что будет. Будет куча коллизий хеша и всё будет плохо. Кроме того, в LARTC написано ставить его кратным conntrack_max именно по приведенной выше формуле. Почему вы считате, что рекомендация в LARTC туфта и сколько вы предлагаете поставить в текущем случае и что это даст? Мне правда интересно. Из личного опыта. Мне не удавалось настроить машину так, чтобы обработать 2Mpps реального трафика под НАТом на 4х ядрах. 10Г или 1.2-1.3Mpps - это разумный потолок для такой машины.

Вопрос не простой, попробую дать свое видиние. 1. Вы не сможете сместить весь 7.5Гб на 2 ядра, т.к. в этом случае каждое ядро будет нагружено на 120%. Соответственно ваш путь - это назначать прерывания на те же ядра. Это даст оверхед при переключениях контекста, но даст возможность принять больше трафика. При трафике на втором порту, у вас будет примерно 70% занятости на каждое ядро, вместо 60%. Вообще, при 70% загрузке, я бы рекомендовал начинать разнос нагрузки на еще одну железку. Ну или апгрейдить эту. 2. Если белые адреса ната пересекаются для разных подсетей /25, то можно агреггировать в цепочки. Но вообще, я не думаю, что данная оптимизация что-то даст. Сколько у вас таких правил, штук 10? Посмотрите в профайлере общий вклад фильтра iptables, я думаю, что он будет 1-2% максимум. 3. hashsize как и, например размер ring buffer, который у вас 2048 - чем меньше, тем лучше, потому что быстрее. Но чем меньше, тем выше возможность в ЧНН начать терять пакеты ( ring buffer ), либо соединения ( hashsize ). Вообще hashsize зависит от conntrack_max в виде hashsize = conntrack_max/8. В вашем случае это = 196608. Ни больше, ни меньше его ставить не надо. У вас больше чем надо. 4. Таблица соединений не попадает в кеш процессора ( возможно разве что частично ), а находится обычно в ОЗУ, т.к. слишком большая и операции над ней происходят на более высоком уровне ОС, а не на уровне драйверов, например. Уменьшить количество csw можно уменьшив количество прерываний. Но это опять игра в баланс. Уменьшая количество прерываний вы рискуете в случае всплеска трафика не успевать всё выгребать из буферов карт - будет потеря пакетов. В целом, я хочу сказать, что 10 Гбит на 4 ядра такого процессора как ваш, это хороший результат для НАТа ( будет 90% нагрузка где-то ). Возможно, вам удасться что-то подкрутить и засунуть туда, 11 Гбит, но по-моему это не имеет смысла, т.к. рисковано. Если хотите 20 Гбит - надо 8 ядер. Кстати, еще важна скорость ОЗУ. Вы её не указали, а это не менее важный параметр, нежели скорость проца. Но опять таки, судя по достигнутым результатам со скоростью ОЗУ всё нормально.

L1 разделен на 2 части: кеш инструкций и кеш данных. Честно говоря я не думаю, что поможет, поэтому переживать как сделать чтобы всё было после ребута я бы не стал. Это просто подтвердит ( или опровергнет ) теорию о том, что ipt_NETFLOW моет кеш. В любом случае надо общаться с автором. Начиная с одного ядра это всё выглядит странно. Но я не эксперт по ipt_NETFLOW, увы. У меня он работает без нареканий и с меньшей нагрузкой на ядра. Правда у меня обычно 1-2 правила. Можете как вариант попробовать сделать агрегированное правило вместо ваших 8. И еще: сколько примерно соединений активно одновременно ( ну или за 1-5 минут, без аггрегации ) и какой pps? Может у вас трафик не большой, но куча пакетов и соединений. Если не агрегировать, получается куча результатов, о которых NETFLOW радостно вещает.

Да, но есть отдельная тема про ipt_NETFLOW, как раз для таких случаев. Хотя я не спорю, что темы сопряженные. Теория нормальная, потому что помимо Intel Smart Cache, который L2 и общий, есть кеш у каждого ядра, который L1. Если ядро без трафика на нем будет всеравно давать 50-60%, то дело не в вымывании кеша. Кстати, на всякий случай, у вас irqbalance и HT отключены?

Ну ip_NETFLOW это немного оффтоп, конечно. Интересная ситуация тем, что ядерный модуль не размазывается по ядрам. Видимо написан не паралельным. И aggregation - это костыль, вы же понимаете. С другой стороны, если не нужен флов по соединение - строка, а достаточно чтобы был агрегирован, то не вижу причины не делать агрегацию. Если новая версия не помогла, то надо либо связываться с автором, либо копать самому функцию. Ядро процессора, которое выполняет модуль ядра, на сколько я понимаю, выбирается во время добавления правил и загрузки соответствующего модуля. Навскид вариант без гугла, можно выгружать, загружать, модуль пока он не окажется у нужного kworker. У меня в практике проблем с ipt_NETFLOW не было, собираю не аггрегированный флов. Ядра разные 2.6.27 и 3.12. Еще как вариант попробуйте убрать трафик с ядра, которому достался NETFLOW. Подтвердите теорию о вымывании кеша. Правильно сомневаетесь, правило обрабатывается в контексте прерывания, затем после отработки правила, зовется модуль ipt_NETFLOW ( контекст переключается на следующее прерывание или что там ). Сам модуль прибит гвоздями к kworker и само исполнение правила переходит уже физически на другое ядро. На сколько я понял. Но тогда не понятно, почему у других, включая меня, проблем нет.