[Iva]

а если использовать хешированные фильтры HTB спасает ситуацию? 275Кpps для 24-х ядер - слышком мало, даже с натом, форвардингом и даже если бы у вас была генерация флова.

Хешированные фильтры помогают как раз до этих пределов, потом начинается падение скорости и абоненты его чётко чувствуют. Сама архитектура HTB не подходит для эффективного распараллеливания. А 24 ядра, так это на оба порта (16 и 8) и 275 Kpps это всего лишь одно направление на одном интерфейсе. Карты загружены неравноморено (вход/исход) и такое распределение ядер по очередям подобрано опытным путём для оптимальной загрузки. Генерация флова присутствует, как и аккаунтинг, но они "бесплатные" в связках ipset+ulog+ipcad+ipt_account.

 

JMan, загружен ли на таком трафике и конфигурации модуль nf_nat и вообще хотелось бы больше технических подробностей (sysctl/lsmod/cat /proc/interrupts и т.п.).

 

На интеле тестировали НТ дает деградацию в 30-40% при загрузке свыше 55%. Подтверждаю проверено.

Хм, раньше такого не замечали, а на какой серии intel проверяли?

[Ivan_83]

lock-lock ... unlock-unlock будет то же по времени, что lock .. unlock lock +++ unlock

Нет, не будет.

И это не эквивалентно.

 

1. Повторное залочивание тем же потоком будет моментальным.

 

2. " lock .. unlock lock +++ unlock" - тут другой поток может занять ресурс пока он будет разблокирован и изменить данные.

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

 

3. Для инкрементации счётчиков блокировка нафик не сдалась.

Если нет опасности что txq будет освобождён и указатели там похерятся то и блокировка там не нужна.

Собственно, первое: "txq->tx_dropped++;" вроде и есть без всяких блокировок.

[Dark_Angel]

2Iva: а что говорит профайлер? Если у Вас 275 Kpps только на одно из направлений, то сколько всего проходит через данный интерфейс?

 

Насчет HT подтверждаю проблему с деградацией скорости, тоже наблюдали в тех же пределах ( после 60% начинает задираться загрузка ), просто меня удивило, что разница в 11 раз должна была получиться. Да, где-то 30-40%

Изменено 12 декабря, 2010 пользователем Dark_Angel

[bitbucket]

Нет, не будет.

И это не эквивалентно.

1. Повторное залочивание тем же потоком будет моментальным.

А так повторного залочивания не будет вообще. Надо будет проверить, будет ли эффект от выкидывания повторной лочки.

 

3. Для инкрементации счётчиков блокировка нафик не сдалась.

Если нет опасности что txq будет освобождён и указатели там похерятся то и блокировка там не нужна.

Собственно, первое: "txq->tx_dropped++;" вроде и есть без всяких блокировок.

По хорошему - да. Надо только посмотреть, где эти счетчики используются. Если используется и нужна точность - можно переделать на percpu.

 

Кстати, насчет урезания скорости : а почему htb ? Если надо хомячку отрезать его двушник-десятку, то почему бы не использовать tbf ? Типа такого: tc qdisc add dev pppX root tbf rate NNNkbit latency ТТms burst ZZZk

 

По поводу HT: под linux не проверял, но под freebsd на i7 870 оно дает небольшой прирост в производительности. В linux я на HT ядра вешаю слабо нагруженные потоки от карточек - оно вроде работает. Но до 60-70% не гружу.

[JMan]

<br />

4.interrupt moderation по умолчанию с драйвера, динамический.

<br />А сколько прерываний в секунду оно генерировало ?<br /><br />

Про драйвер ВЛАН diff прицепил. Там фикс по очередям и убрал глобальный лок при отправке в в влан пакетов ибо это логическое устройство зачем он нужен (у него и дисплины то нету абы положить в очередь пакет, елси один проц уже занял отправку) пусть уже на уровне реальной сетевой это делает.

Посмотрел я патч, вроде бы да, lock на отправке в vlan не нужен, но у вас он все равно есть, где счетчики пакетов прибавляются. Тогда смысл ? lock-lock ... unlock-unlock будет то же по времени, что lock .. unlock lock +++ unlock . Ну последний lock-unlock кусок будет меньше по времени. Правильней бы в dev_queue_xmit() (а лучше вообще в HARD_TX_LOCK) проверять, что если текущий txq->xmit_lock_owner == smp_processor_id(), то не лочить очередь - оно уже залочено (надо будет это проверить :) )<br /><br />

<br /><br /><br />

1. Прерываний было 8000 тыс.

2. А я так и переписал драйвер что-бы не было лока в HARD_TX_LOCK, посмотрите там флаг один взводится который и в bond используется. А меленький лок сделал лишь бы гарантировать верность подсчета статистики. Тоесть теперь нету глобального лока в HARD_TX_LOCK, а раньше получалось что если хоть один ЦПУ влез то пока не закончит все работы аж в в реальной сетевой лок держался, и все остальные ЦПУ что захотели бы отправить сидели бы ждали в холостую в HARD_TX_LOCK.

[JMan]

<br />

а если использовать хешированные фильтры HTB спасает ситуацию? 275Кpps для 24-х ядер - слышком мало, даже с натом, форвардингом и даже если бы у вас была генерация флова.

<br />Хешированные фильтры помогают как раз до этих пределов, потом начинается падение скорости и абоненты его чётко чувствуют. Сама архитектура HTB не подходит для эффективного распараллеливания. А 24 ядра, так это на оба порта (16 и 8) и 275 Kpps это всего лишь одно направление на одном интерфейсе. Карты загружены неравноморено (вход/исход) и такое распределение ядер по очередям подобрано опытным путём для оптимальной загрузки. Генерация флова присутствует, как и аккаунтинг, но они "бесплатные" в связках ipset+ulog+ipcad+ipt_account.<br /><br />JMan, загружен ли на таком трафике и конфигурации модуль nf_nat и вообще хотелось бы больше технических подробностей (sysctl/lsmod/cat /proc/interrupts и т.п.).<br /><br />

На интеле тестировали НТ дает деградацию в 30-40% при загрузке свыше 55%. Подтверждаю проверено.

<br />Хм, раньше такого не замечали, а на какой серии intel проверяли?<br />

<br /><br /><br />

Проверялось на последнем ксеоне правда не 6 ядерном, а те что 4 ядерные. То есть физических ядер было 8, а с НТ 16, так вот при 16 загрузка в потолок начиналась на меньшем pps. Странна но факт похоже из-за того что при роутинге кеш часто подгружается и лишнее виртуальные ЦПУ только больше вносят таких "подгрузок"

 

Сейчас думаю сесть за 2 часть статьи, и пожалуйста, напишите что описать более подробно, абы ничего не упустил и удовлетворил ваш интерес к данной теме. Нат не был загружен, еще раз повторяю тестировался в качестве пограничного БГП маршрутизатора. В планах и пробовать в качестве НАТ такой сервер, но пока планируем как мы в рамках сети такое сможем сделать.

И в НАТ нужен шейпинг, а пока в линуксе эти все дисциплины только один ЦПУ смогут использовать. Общая дисциплина на все очереди сетевой будет, соответственно при отправке упремся в общий лок, что человек уже и видел, сам раньше такое наблюдал, в прошлом, что больше 300 К пакетов никак с шейпингом не выдавить, а вот с чистым натом легко.

Есть пару идей как это можно обойти но еще надо подумать потом вынесу на общее обсуждение.

 

[JMan]

<br />

lock-lock ... unlock-unlock будет то же по времени, что lock .. unlock lock +++ unlock

<br />Нет, не будет.<br />И это не эквивалентно.<br /><br />1. Повторное залочивание тем же потоком будет моментальным.<br /><br />2. " lock .. unlock lock +++ unlock" - тут другой поток может занять ресурс пока он будет разблокирован и изменить данные.<br />Не знаю что там за код, между блокировками, но возможно что он не сможет продолжить дальше корректную работу, ибо данные на которые он полагался будут изменены.<br /><br />3. Для инкрементации счётчиков блокировка нафик не сдалась.<br />Если нет опасности что txq будет освобождён и указатели там похерятся то и блокировка там не нужна.<br />Собственно, первое: "txq->tx_dropped++;" вроде и есть без всяких блокировок.<br />

<br /><br /><br />

Абы txq не ушел, в принципе там есть в начале функции dev_hold а в конце dev_put. для ++ операции точно лок не нужен, только ради += операции там лок делаю (хотя надо проанализировать асм код что генерируется и посмотреть может тоже не надо. А dev_hold сделал на случае если сетевую хотят убрать а сейчас какойто ЦПУ отправляет, то когда пакет реально отправится у него ссылка на сетевую снимется и может стать равна 0 и система освободит dev, а мы потом будем txq-> использовать для статистики, и можем получить кернел паник.

[JMan]

Еще отвлеченный вопрос а интересно ли людям модифицированный ipset таблица, которая проверяет айпи на наличие и если есть айпи, то возвращает что есть, и кроме того делает классификацию куда отправить трафик. То есть при добавление айпи в таблицу надо указывать и номер класса куда слать трафик.

Пример ipset -A test_tbl 10.13.56.7 1:ab56. Может добавить удобства когда нужно в iptables быстро посмотреть открыт ли доступ для айпи и сразу промаркировать в нужный класс трафик.

[Dark_Angel]

2JMan: покажите больше технической информации: сколько прерываний, переключений контекста, кто большего всего систему грузит, размер таблицы НАТ, количество фильтров шейпера и другие параметры системы в процессе полной загрузки. Я думаю всем будет интересна именно эта информация.

 

Касательно HT: Да, вымывает кеш и растет оверхед на перегрузку этого кеша в реальных ядрах. Получается ситуация, как будто очереди к ядрам не прибиты. Там примерно такая же потеря производительности при этом: 30%. Видимо на 50-60% оверхед не так видно, а потом начинается лавина. Вообщем для роутинга НТ однозначно отключать.

 

Касательно 8000 прерываний. Всего 8К на все очереди или каждая очередь делала 8К?

[nag-f]

2JMan

 

Относительно второй статьи. Прошу учеть опыт самой Intel:

http://www.vyatta.com/downloads/whitepaper...olBrief_r04.pdf

 

И если не сложно, протестировать работу в реальных условиях на vyatta.

[JMan]

<br />2JMan: покажите больше технической информации: сколько прерываний, переключений контекста, кто большего всего систему грузит, размер таблицы НАТ, количество фильтров шейпера и другие параметры системы в процессе полной загрузки. Я думаю всем будет интересна именно эта информация. <br /><br />Касательно HT: Да, вымывает кеш и растет оверхед на перегрузку этого кеша в реальных ядрах. Получается ситуация, как будто очереди к ядрам не прибиты. Там примерно такая же потеря производительности при этом: 30%. Видимо на 50-60% оверхед не так видно, а потом начинается лавина. Вообщем для роутинга НТ однозначно отключать.<br /><br />Касательно 8000 прерываний. Всего 8К на все очереди или каждая очередь делала 8К?<br />

<br /><br /><br />

На каждую очередь по 8000 прерываний. НАТ небыло. А вот абы понимать трафик нет флов коллектор (с другого оборудования) лил суммарно 29 тыс записей в секунду, всего не суммировали сколько активных фловов было, но в районе 3 миллионов активных фловов в сети вечерами бывает спокойно, сколько в тот момент было не могу сказать не подумали снять показатели.

[JMan]

<br />2JMan<br /><br />Относительно второй статьи. Прошу учеть опыт самой Intel:<br /><a href="http://www.vyatta.com/downloads/whitepapers/Intel_Router_solBrief_r04.pdf" target="_blank">http://www.vyatta.com/downloads/whitepaper...olBrief_r04.pdf</a><br /><br />И если не сложно, протестировать работу в реальных условиях на vyatta.<br />

<br /><br /><br />

Да читал, а чем vyatta отличается от моего решения по-моему тоже самое :), только вланы модифицировал ибо с ними неправильно работали очереди.

По поводу тестов, не знаю как там тестировали ребята по указной ссылке ( в чем заключался этот тест). Но приоткрою тайну, на синтетических тестах (с вланом) последняя платформа амд дала спокойно 4,5 Мпс, при этом потерь не было пинг был по прежнему 0.4 мс, и консоль работала по ссх нормально в несколько сесий (там были разные мониторинг утилиты запущены). Хотя показывало что загрузка всех 16 ЦПУ были в 100%, дальше можно дорастить Мпс и свыше 5, потерь не было, но уже юзер приложения давали притормаживания.

Очень хочу на следующей недели провести тестирование интел платформы на 6 ядер в одном ЦПУ. И тогда будет видна полнота картины.

 

[nag-f]

2JMan ни в коем случае один ЦПУ. Берите пару 5650+.

[nag-f]

/*Да читал, а чем vyatta отличается от моего решения по-моему тоже самое :), */

 

Ну вот и проверите. Тоже самое или отличается :)

[JMan]

<br />2JMan ни в коем случае один ЦПУ. Берите пару 5650+.<br />

<br /><br /><br />

Мне пару на 3.33 Ггц по 6 ядер каждый и предоставят так сказать самый топ. АМД давали самый топ 2 по 12 ядер и 2 по 8 ядер цпу, но там частоты ниже были 2,2 для 12 ядер и 2,4 для 8 ядер.

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

[stelsik]

Лучше смотрите на тот как потоковое видео работает. При большой нагрузке, онлайн видео жестоко лагает также как скорость одной тсп сессии.

[JMan]

<br />Лучше смотрите на тот как потоковое видео работает. При большой нагрузке, онлайн видео жестоко лагает также как скорость одной тсп сессии.<br />

<br /><br /><br />

Так не важно это софт роутер или аппаратный если порт в 100% забит то будет лагать там и там. Или вы о чем-то другом.

[bitbucket]

Собственно, первое: "txq->tx_dropped++;" вроде и есть без всяких блокировок.

Убрал я там lock, по сравнению со стоковым вариантом изменений никаких не видно.

[JMan]

<br />

Собственно, первое: "txq->tx_dropped++;" вроде и есть без всяких блокировок.

<br />Убрал я там lock, по сравнению со стоковым вариантом изменений никаких не видно.<br />

<br /><br /><br />

В роутере и не будет ибо влан сейчас создает вирутальные очереди ровно количетсву виртуальных очередй в реально сетевой (и при патче с номеров очереди нету перекроса по процам). А вот если это будет просто сервер с кучей соединений типа веба то могут быть колизии, так сделал для верности.

[stelsik]

<br />Лучше смотрите на тот как потоковое видео работает. При большой нагрузке, онлайн видео жестоко лагает также как скорость одной тсп сессии.<br />

<br /><br /><br />

Так не важно это софт роутер или аппаратный если порт в 100% забит то будет лагать там и там. Или вы о чем-то другом.

Я про то, чтобы тестировать в реальных условиях, у меня например на 2хЕ5530 с 6х82576EB в бондинге, при более гига в обе стороны, начинало тормозить онлайн видео, а все остальное было в норме

[bitbucket]

В роутере и не будет ибо влан сейчас создает вирутальные очереди ровно количетсву виртуальных очередй в реально сетевой (и при патче с номеров очереди нету перекроса по процам). А вот если это будет просто сервер с кучей соединений типа веба то могут быть колизии, так сделал для верности.

А кто эту статистику по байтикам в очереди использует ? Что-то я не нашел где оно реально используется.

 

[JMan]

<br />

В роутере и не будет ибо влан сейчас создает вирутальные очереди ровно количетсву виртуальных очередй в реально сетевой (и при патче с номеров очереди нету перекроса по процам). А вот если это будет просто сервер с кучей соединений типа веба то могут быть колизии, так сделал для верности.

А кто эту статистику по байтикам в очереди использует ? Что-то я не нашел где оно реально используется.<br /><br />

<br /><br /><br />

Потом она сумируется по всем очередям и выводится всего по девайсу, статистика в ifconfig

 

<br />

<br />Лучше смотрите на тот как потоковое видео работает. При большой нагрузке, онлайн видео жестоко лагает также как скорость одной тсп сессии.<br />

<br /><br /><br /><br />Так не важно это софт роутер или аппаратный если порт в 100% забит то будет лагать там и там. Или вы о чем-то другом.<br />

<br />Я про то, чтобы тестировать в реальных условиях, у меня например на 2хЕ5530 с 6х82576EB в бондинге, при более гига в обе стороны, начинало тормозить онлайн видео, а все остальное было в норме<br />

<br /><br /><br />

Незаню у нас на реальном тесте жалоб небыло от клиентов, больше недели работало. И елси тормозит онлайн видео то и любые тсп сесии должны бы тормозить, ибо онлайн видео поверх тсп идет. А у нас даже спид тест спокойно по аю-ах выдавал до 90 МБит :) в пике загрузки. Такчто ТСП нормально работал.

[bitbucket]

Потом она сумируется по всем очередям и выводится всего по девайсу, статистика в ifconfig

Ну тогда для точности можно так сделать:

txq->tx_packets++; меняется на (примерно, не силен я в gasm)

asm volatile(LOCK_PREFIX "incl %0"

: "+m" (txq->tx_packets));

а txq->tx_bytes += len; меняется на:

asm volatile(LOCK_PREFIX "addl %1,%0"

: "+m" (txq->tx_bytes)

: "ir" (len));

с tx_dropped аналогично с tx_packets.

 

Конечно, это костыль, но он убирает один lock-unlock.

[Ivan_83]

Во фряхе нет локов на счётчиках.

В принципе, можно объявить как volatile и на этом забыть.

Либо небольшая потеря производительности за счёт потенциально небольшого повышения точности статистики.

[nag-f]

/*Про драйвер ВЛАН diff прицепил.*/

 

2JMan

Дайте пожалуйста ссылку