[pchol]

Тогда ещё в догонку вопрос. Стоит ли заодно манипулировать с размером очереди на самом интерфейсе ?

ip link set dev eth1 qlen Х.

Какие лучше значения выставлять, на каких потоках ?

[photon]

Это длина очереди виртуального устройства, с которой работает tc, она же txqueuelen, которая настраивается через ifconfig. Я тут тоже особо не думал, а просто увеличивал до размера tx ring сетевой карты (у e1000/e1000e максимально до 4096, у tg3 -- до 1024). Кстати не факт, что та или иная модель сетевухи может хранить в буферах до 4096 пакетов. Это справедливо скорее для каких-то серверных моделей, не даром же там по умолчанию 256 стоит.

Изменено 29 апреля, 2010 пользователем photon

[pchol]

Спасибо за конструктивный диалог =)

[disappointed]

50 маловато, вот смотрю на pfifo limit 50 при скорости 512 Килобит уже вылазят дропы в tc -s -d.

при limit 200 - на 5 Мегабитах пролетают дропы, а вот 250 для 5 Мбит хватает.

 

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

Изменено 29 апреля, 2010 пользователем disappointed

[photon]

50 маловато, вот смотрю на pfifo limit 50 при скорости 512 Килобит уже вылазят дропы в tc -s -d.

при limit 200 - на 5 Мегабитах пролетают дропы, а вот 250 для 5 Мбит хватает.

 

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

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

Изменено 29 апреля, 2010 пользователем photon

[disappointed]

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

Ну у нас такого не сделать, клиенты посчитают это наё№кой.

[pchol]

Апну тему, потому что возник вопрос в продолжение того что было.

Проследил я зависимости в использовании памяти и возникновения загрузки проца.

Ситуация складывается таким образом, что скачки начинаются когда активной памяти используется около гига. Хотя в системе 4 гига.

Есть подозрение что нужно по пробовать поменять значения rmem / wmem и им подобные.

Почитав про тюнинг стека tcp / ip увидел часто встречающиеся фразы в духе "при установке, система сама определяет оптимальные значения, и их изменения не дают особого прироста производительности".

Отсюда вопрос... не подскажи те ли изменение каких значений может быть реально эффективным ? Можно просто перечислить переменные, а дальше я сам.

Ещё раз напомню, машина выполняет функции НАТ сервера и шейпера.

В ЧНН vmstat показывает следующее. (sfq на "качающих" тарифах заменено на pfifo)

vmstat -s
      4055356 K total memory
       591244 K used memory
       150548 K active memory
        29668 K inactive memory
      3464112 K free memory
        31724 K buffer memory
        40364 K swap cache
      2650684 K total swap
            0 K used swap
      2650684 K free swap
        15004 non-nice user cpu ticks
            0 nice user cpu ticks
         9406 system cpu ticks
      1935355 idle cpu ticks
          792 IO-wait cpu ticks
        11143 IRQ cpu ticks
       295126 softirq cpu ticks
            0 stolen cpu ticks
        66502 pages paged in
        21376 pages paged out
            0 pages swapped in
            0 pages swapped out
     78337518 interrupts
     11549705 CPU context switches
   1272998312 boot time
        21625 forks

Изменено 4 мая, 2010 пользователем pchol

[DemYaN]

rmem и wmem тут уж точно не помогут, они влияют лишь на буферы сокетов (tcp, udp, netlink и прочее)

 

ps замена sfq на pfifo сильно изменила ситуацию?

Изменено 5 мая, 2010 пользователем DemYaN

[pchol]

Да.

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

[photon]

rmem и wmem тут уж точно не помогут, они влияют лишь на буферы сокетов (tcp, udp, netlink и прочее)

Лично мне не совсем понятно, на что именно влияют значения /proc/sys/net/core/rmem|wmem_max , потому что для буферов сокетов есть другие параметры:

/proc/sys/net/ipv4/tcp_rmem_max, /proc/sys/net/ipv4/udp_rmem_max и т.д. При этом, классификаторы и многие шедулеры (SFQ, например) используют структуру sk_buff для извлечения данных из заголовков пакетов. Может быть значения из /proc/sys/net/core/* влияют на некий общий буфер, содержащий структуры sk_buff, который используется не только сокетами?

Изменено 5 мая, 2010 пользователем photon

[DemYaN]

rmem и wmem тут уж точно не помогут, они влияют лишь на буферы сокетов (tcp, udp, netlink и прочее)

Лично мне не совсем понятно, на что именно влияют значения /proc/sys/net/core/rmem|wmem_max , потому что для буферов сокетов есть другие параметры

помимо tcp/udp есть и другие протоколы, например netlink

 

[pchol]

Странно... не было проблем 2 недели после введения pfifo.

А тут снова появилась. Перечитал тему...

У поминалось про память... Но как то странно гляжу на vmstat и вижу

shaper:/script# vmstat -s
      4055356 K total memory
      1501556 K used memory
       421348 K active memory
       530720 K inactive memory
      2553800 K free memory
       202068 K buffer memory
       648320 K swap cache
      2650684 K total swap
            0 K used swap
      2650684 K free swap

 

Памяти 3 гига свободно, да и в своп ничего не залезло.

И ещё особенность, всё это сопровождается дропами на внешней сетевухе. Что довольно странно, если учитывать то, что u32 (который как раз по опрофайлу и отжирает максимум ресурсов), работает на внутренней сетевухе.

 

[photon]

Странно... не было проблем 2 недели после введения pfifo.

А тут снова появилась. Перечитал тему...

У поминалось про память... Но как то странно гляжу на vmstat и вижу

vmstat тут не поможет, т.к. он показывает общие объемы, а не размер какой-то конкретной области памяти, выделяемую под те или иные структуры в ядре.

Для маршрутизатора или моста на FreeBSD или Linux, без разницы, нужно искать параметры ядра, управляющие размерами релевантных областей памяти. Первым делом надо смотреть в ethtool приемный буфер сетевухи. На внешней надо тоже увеличить rx ring. Еще вспоминается параметр /proc/sys/net/core/netdev_max_backlog, который определяет размер приемных буферов в ядре, куда обработчики прерываний складывают принятые с устройств пакеты. Его можно выставить побольше, 4000 или выше. Есть параметр netdev_budget -- максимальное число пакетов, снимаемое за один цикл опроса, используется если драйвер поддерживает NAPI. Его тоже можно увеличить.

 

Прогнал греп по документации ядра, эти и другие сетевые параметры документированы в Documentation/sysctl/net.txt . Действительно, rmem_max и wmem_max имеют отношение только к сокетам. Еще нашел недавно такую книгу про сетевую подсистему Linux: http://book.chinaunix.net/special/ebook/or...work_Internals/

Изменено 17 мая, 2010 пользователем photon

[DemYaN]

...

В шейпере на исходящий трафик порядка 3к классов, на входящий повешен лишь один ingress полисер.

...

то бишь на ingress ограничивается скорость всего трафика? или с ingerss все-таки перенаправляется скажем на ifb, а там свои классы?

 

имхо, надо все-таки u32-фильтры переделывать

Изменено 17 мая, 2010 пользователем DemYaN

[photon]

имхо, надо все-таки u32-фильтры переделывать

Если проц не загружен softirq под 100%, то проблема не в фильтрах, а в недостаточном размере каких-то буферов для хранения пакетов, IMHO.

Изменено 17 мая, 2010 пользователем photon

[DemYaN]

имхо, надо все-таки u32-фильтры переделывать

Если проц не загружен под 100%, то проблема не в фильтрах, а в недостаточном размере каких-то буферов для хранения пакетов, IMHO.

см. пост #11

иначе были бы значительные дропы

Изменено 17 мая, 2010 пользователем DemYaN

[pchol]

Да, на ингрес всего 1 полисер.

А на что переделывать u32 ?

 

[photon]

Альтернативой фильтрам u32 являются классификатор flow и модули IPMARK и IPCLASSIFY. Прежде чем что-то переделывать, надо понять, не являются ли эти проблемы следствием атак со стороны взломанных пользовательских машин. Для этого в проблемные периоды надо запустить tcpdump, поймать им 1000 пакетов (параметр -c 1000) и посмотреть на IP источников. Если большинство пакетов валится с одного IP, то это явно атака, и данный IP надо банить на порту свича (максимально близко к источнику). Увеличивая размеры буферов и переписыванием правил можно лишь повысить "запас прочности" маршрутизатора, но это не убережет от DoS-атак, т.к. даже один-два юзера со 100Мбитным Ethernetом могут создать довольно большой пакетрейт и забить приемный буфер гигабитной сетевухи.

Изменено 18 мая, 2010 пользователем photon

[DemYaN]

но планка то - 70kpps... это мало с dos'ом или без него

[pchol]

Но переполнение буфера по идее должно вызвать дропы, но не как загрузку процессора. Или нет?

Смотрел в этот момент через tc пакет рейты пользователей всё в пределах нормы с учётом активных "торрент-качков", на 5-8мбитных тарифах ппс порядка 1,2-1,5к.

[photon]

Но переполнение буфера по идее должно вызвать дропы, но не как загрузку процессора. Или нет?

Смотрел в этот момент через tc пакет рейты пользователей всё в пределах нормы с учётом активных "торрент-качков", на 5-8мбитных тарифах ппс порядка 1,2-1,5к.

Аномально большие пакетрейты вызывают и то, и другое. Пакеты обрабатываются путем опроса состояния очередей, поэтому если очереди всегда забиты, то будет избыточно расходоваться и процессорное время. В tc не видно общей картины, надо запустить tcpdump на внутреннем интерфейсе, там сразу видно, когда идет куча пакетов с одного IP.

Изменено 18 мая, 2010 пользователем photon

[pchol]

Вчера ситуация стала совсем загадочной =)

Вечер, проц в полке, глядел tcpdump / iftop, думал может ботнет какой. Ничего аномального, pps 65к, трафика 300мбит.

Меняю всем пользователям sfq на pfifo... и результата 0.

ksoftirqd отжирает процессорное время.

Ночью когда закончилась вся эта бодяга поднял пользователям скорость чтобы изобразить ЧНН. Как оказалось такое отжирание процессорного времени для u32 это нормально. То есть показатель был примерно такой же как в первом посте, но загрузка на процах была по 25%. pps 55к / 300мбит.

в dmesg пусто. из доп сервисов крутящихся на машине только bind.