Jump to content
Калькуляторы

Тюнинг CentOS 5.5 под конкретную задачу Надо ли оно вообще, и если надо, то что конкретно?

Дано: сервер INTEL SR1600UR, 2 х Xeon E5503 2.00GHz, 6Гб RAM, сетевые карты - гигабитная 2-х портовая PCI-ex Intel 82576.

ОС - CentOS 5.5, собрано с ядром 2.6.34, iptables 1.4.8, драйвер на сетевую - igb 2.2.9

Задача железки:

1. роутинг

2. NAT

3. фаервол.

Интересует тюнинг ядра (sysctl) и сетевой подсистемы в свете поставленной задачи и с учетом дальнейшего роста.

Предположительная нагрузка:

трафик ~200 Мбит при ~50-60 Kpps

NAT ~ 1000-1500 он-лайн соединений.

Плюс ко всему прочему будет RIP на quagga.

Share this post


Link to post
Share on other sites

С такими параметрами сервера и таким трафиком - можно вообще ничего не тюнить...

А так HZ=250 вполне достаточно будет.

Вот дойдет трафик до 1,5-2 Гбит... тогда голова заболит - сетёвку придется добавить минимум :-).

Edited by sdy_moscow

Share this post


Link to post
Share on other sites

Не ну как бы ring у сетевок можно и увеличить с дефолтных 256 байт, до 2 Кб хотя бы для начала. см. ethtool [-g|-G]

Share this post


Link to post
Share on other sites

SokolovS

ring не в байтах меряется, а в дескрипторах

Share this post


Link to post
Share on other sites
А так HZ=250 вполне достаточно будет.
Это в ядре? Вот здесь?
CONFIG_HZ_100=y
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100

Или в sysctl.conf можно "подкрутить"? И вообще, вкратце поясните, пожалуйста, что даст HZ=250?

Не ну как бы ring у сетевок можно и увеличить с дефолтных 256 байт, до 2 Кб хотя бы для начала. см. ethtool [-g|-G]
А в дальнейшем? На что смотреть, "покручивая" ring?

И здесь в чем тайный смысл? Максимально использовать возможности сетевых для разгрузки процессора(ов), или что-то другое?

Кстати, а каким образом можно изменить этот параметр? Только с помощью ethtool, или в modprobe.conf возможно указать? Хотелось бы сразу при загрузке устанавливать, но не нахожу подходящего параметра в драйвере..

parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (array of int)
parm:           LLIPort:Low Latency Interrupt TCP Port (array of int)
parm:           LLIPush:Low Latency Interrupt on TCP Push flag (array of int)
parm:           LLISize:Low Latency Interrupt on Packet Size (array of int)
parm:           RSS:RSS - multiqueue receive count (array of int)
parm:           VMDQ:VMDQ - VMDq multiqueue receive (array of int)
parm:           max_vfs:max_vfs - SR-IOV VF devices (array of int)
parm:           QueuePairs:QueuePairs - TX/RX queue pairs for interrupt handling (array of int)
parm:           debug:Debug level (0=none, ..., 16=all) (int)

В modprobe.conf сейчас только вот это

options igb IntMode=2,2,2,2 RSS=2,2,2,2 QueuePairs=1,1

 

 

P.S. Прошу прощения за дополнительные вопросы, но хочется знать, что делаю, дабы потом не гадать, отчего это "оно вдруг стало так странно себя вести". :)

Edited by AlKov

Share this post


Link to post
Share on other sites
ring не в байтах меряется, а в дескрипторах
Ну да, ну да :)

 

А в дальнейшем? На что смотреть, "покручивая" ring?
ifconfig смотреть на предмет появления дропов и их причину

Вот посмотри http://www.ece.rice.edu/~willmann/teng_nics_hownicswork.html на общую схему процесса

Edited by SokolovS

Share this post


Link to post
Share on other sites
А в дальнейшем? На что смотреть, "покручивая" ring?
ifconfig смотреть на предмет появления дропов и их причину

Вот посмотри http://www.ece.rice.edu/~willmann/teng_nics_hownicswork.html на общую схему процесса

Ну и? А если дропов нет/не_было, то??? И ещё раз, чем "подкручивать" ring? Только костылём через ethtool (rc.local), или возможно "по-правильному" ;)?

Share this post


Link to post
Share on other sites

Ну по идее на 50-60 кппс, уже должны были появиться дропы при дефолтном ринге в 256.

Можно и по правильному :) Правильность каждый сам для себя определяет, для кого-то и через rc.local правильно ;)

 

touch /sbin/ifup-local
touch /sbin/ifdown-local

 

Содержимое файлов:

/sbin/ifup-local

#!/bin/sh

DEVICE=$1
if [ "$DEVICE" = "" ]; then
    echo "Usage: $0 <DEVICE>"
fi

FILE="/etc/sysconfig/network-scripts/up/$DEVICE"
if [ -f $FILE ]; then
    . $FILE
fi

 

/sbin/ifdown-local

#!/bin/sh

DEVICE=$1
if [ "$DEVICE" = "" ]; then
    echo "Usage: $0 <DEVICE>"
fi

FILE="/etc/sysconfig/network-scripts/down/$DEVICE"
if [ -f $FILE ]; then
    . $FILE
fi

 

В каталоге /etc/sysconfig/network-scripts создаете две папки up и down и ложите туда файлики с именем интерфейса, например eth0. Выполняться будут при поднятии и опускании интерфейса.

 

Вот пример одного из моих на поднятие.

#!/bin/sh

# Disable tcp segmentation offload
/sbin/ethtool -K $DEVICE tso off tx off sg off

# Set rings params
/sbin/ethtool -G $DEVICE rx 2048
/sbin/ethtool -G $DEVICE tx 2048

# Set queue lenght
/sbin/ifconfig $DEVICE txqueuelen 3000

#... и.т.д, тут можно и маршруты и автоподнятие шейпера

 

Этот правильный костыль я сам делал, в некоторых системах нечто похожее уже есть, т.е. только файлик со скриптом положить в правильное место. В RHEL-based системах реализовано только автоподнятие маршрутов через файлики вида routes-<iface> который должны лежать в /etc/sysconfig/network-scripts, но их функциональность ограничена только поднятием марщрутов.

Edited by SokolovS

Share this post


Link to post
Share on other sites
...Этот правильный костыль я сам делал, в некоторых системах нечто похожее уже есть, т.е. только файлик со скриптом положить в правильное место. В RHEL-based системах реализовано только автоподнятие маршрутов через файлики вида routes-<iface> который должны лежать в /etc/sysconfig/network-scripts, но их функциональность ограничена только поднятием марщрутов.
Ок. Спасибо за "правильный костыль". :)

Вот возник еще вопрос насчет "tcp segmentation offload". Кто-то рекомендует его отключить (в частности, для решения этой проблемы), а кто-то наоборот включить, для повышения производительности сетевой подсистемы.

Кому-нибудь приходилось играться с этим параметром? Какие результаты были получены?

 

Share this post


Link to post
Share on other sites
1. роутинг

2. NAT

3. фаервол.

Вот возник еще вопрос насчет "tcp segmentation offload"

там оно использоваться не будет...

Share this post


Link to post
Share on other sites
1. роутинг

2. NAT

3. фаервол.

Вот возник еще вопрос насчет "tcp segmentation offload"

там оно использоваться не будет...

То есть? Я правильно Вас понимаю, что tcp segmentation offload только для входящих tcp? И для данной машины значение его (on/off) не имеет решающего значения?

Share this post


Link to post
Share on other sites
1. роутинг

2. NAT

3. фаервол.

Вот возник еще вопрос насчет "tcp segmentation offload"

там оно использоваться не будет...

То есть? Я правильно Вас понимаю, что tcp segmentation offload только для входящих tcp? И для данной машины значение его (on/off) не имеет решающего значения?

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

 

Я тоже словил странный баг с включенным TSO на шейпящем мосте, htb выдавал скорость в 2-5 раз больше. Нашел что лечится только отключением TSO.

Edited by SokolovS

Share this post


Link to post
Share on other sites
То есть? Я правильно Вас понимаю, что tcp segmentation offload только для входящих tcp? И для данной машины значение его (on/off) не имеет решающего значения?
для исходящих, разрешает апликухе писать в карту по 64к котрые она сама порубит на куски по размеру мту в отправит в сеть, нфс сервер, например...

для входящих такое называют lro.

гугль тут сильно поможет .... :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this