Переводы — Тонкая настройка TCP

Оригинал
Ядра Linux версий 2.4 и 2.6 существенно различаются. Сначала мы рассмотрим общие для них настройки.
Чтобы изменить настройки TCP, надо изменить файл /etc/sysctl.conf, а затем выполнить "sysctl -p".

Как и во всех операционных системах, стандартные размеры буфера TCP обычно слишком малы. Я предлагаю изменить их следующим образом:

1 2 3 4 5 6 7 8 9 10 11

# увеличим максимальный размер буфера TCP, устанавливаемый setsockopt() # 16 MB с несколькими параллельными потоками рекомендуется для большинства 10Gb участков сетей # 32 MB могут понадобиться для некоторых очень длинных последовательных 10Gb или 40Gb участков сетей net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 # увеличим пределы для автоматической настройки размера буфера TCP # минимальный, стандартный и максимальный размер в байтах net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_rmem = 4096 87380 33554432 net.ipv4.tcp_wmem = 4096 65536 33554432

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

1 2 3

sysctl net.ipv4.tcp_window_scaling sysctl net.ipv4.tcp_timestamps sysctl net.ipv4.tcp_sack

Примечание: tcp_mem лучше оставить в покое. Стандартное значение сойдёт.

Ещё одна вещь, которая поможет вам увеличить пропускную способность сетевых адаптеров 1000baseT - увеличение размера очереди сетевого интерфейса. Для участков сети с временем приёма-передачи (RTT) более, чем 50мс, рекомендуется значение 5000 — 10000:

1	ifconfig eth0 txqueuelen 5000

На длинных, быстрых участках сети вы таким образом можете достичь существенного увеличения пропускной способности, вплоть до десятикратного. Однако, это применимо только к машинам, соединённым Gigabit Ethernet. Кроме того, возможны побочные эффекты, такие как неравномерное распределение между несколькими потоками.

Кроме того, я рассказывал, что для некоторых участков сети использование подсистемы Linux traffic control ('tc', контроль трафика) (прим. переводчика: подробнее здесь и здесь) для ограничения скорости исходящего трафика может улучшить общую пропускную способность.
Linux 2.6

Начиная с ядра версии 2.6.7, в Linux включены альтернативные алгоритмы управления перегрузкой сети (которые были бэкпортированы в 2.4.27), помимо традиционного алгоритма 'reno'.(Прим.переводчика: см.также RFC 2581 — Контроль насыщения в TCP тут http://rfc2.ru/2581.rfc). Они разработаны для быстрого восстановления потерянных пакетов на высокоскоростных WAN.

Кроме того, в Linux 2.6 есть система автоматической настройки буфера со стороны отправителя и получателя (которая может изменять его вплоть до указанных выше максимальных размеров). Ниже описана опция, исправляющая странное кэширование ssthresh (порог медленного старта, RFC на русском)

Еще несколько дополнительных sysctl-настроек в 2.6:

1 2 3 4

# не кэшировать ssthresh с предыдущих соединений net.ipv4.tcp_no_metrics_save = 1 # рекомендуется увеличить для 10-ти гигабитных сетевых карт net.core.netdev_max_backlog = 30000

Начиная с версии 2.6.13, Linux поддерживает подключаемые алгоритмы управления перегрузкой сети. Используемый алгоритм управления перегрузкой устанавливается с помощью sysctl-переменной net.ipv4.tcp_congestion_control, которая по умолчанию установлена на bic, cubic или reno, в зависимости от версии используемого вами ядра 2.6.

Для получения списка доступных алгоримов управления перегрузкой для вашего ядра (если вы используете 2.6.20 или выше), выполните:

1	sysctl net.ipv4.tcp_available_congestion_control

Настройки управления перегрузкой выбираются при сборке ядра. Вот несколько опций, доступных для ядра 2.6.23:
reno: Традиционный TCP, используется в большинстве других ОС. (стандартный)cubic: CUBIC-TCP (прим. переводчика: подробнее на русском)bic: BIC-TCP (прим. переводчика: подробнее на русском)htcp: Hamilton TCPvegas: TCP Vegaswestwood: оптимизирован для сетей с потерями
Если cubic и/или htcp отсутствуют в списке, выданном 'sysctl net.ipv4.tcp_available_congestion_control', попробуйте выполнить приведенную ниже команду. В большинстве дистрибутивов эти алгоритмы содержатся в виде подгружаемых модулей ядра:

1 2	/sbin/modprobe tcp_htcp /sbin/modprobe tcp_cubic

ПРИМЕЧАНИЕ: Кажется, в bic и cubic в ядре 2.6.18, используемом в RedHat Enterprise Linux 5.3 - 5.5 и его производных (CentOS, Scientific Linux и т. д.), есть баги. Мы рекомендуем использовать htcp с ядрами 2.6.18.x для безопасности.

Для длинных быстрых участков сети мы настоятельно рекомендуем использовать cubic или htcp. Cubic установлен по умолчанию в большинстве дистрибутивов Linux, но если в вашей системе не так, вы можете исправить это следующим образом:

1	sysctl -w net.ipv4.tcp_congestion_control=cubic

В RPM-системах можно использовать пакет ktune, который делает всё это не хуже.

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

Больше информации о настройке параметров и значенях по умолчанию доступно в файле ip-sysctl.txt, который поставляется вместе с исходниками Linux 2.6.

Предупреждение о больших MTU: если вы настроили свою Linux-машину на использование MTU = 9000, а соединение использует пакеты по 1500 байт, то в действительности вам нужен в 9/1.5 = 6 раз больший размер буфера, чтобы заполнить канал. На практике, некоторые драйверы устройств резервируют память только в размере, равном степени двойки, поэтому вам может понадобиться в 16/1.5 = 11 раз больший размер буфера!

И, наконец, предупреждение для 2.4 и 2.6: для всех участков сети с большим BDP, где размер TCP window больше 20 MB, вы, вероятно, столкнётесь с проблемой реализации SACK в Linux. Если у ядра слишком много пакетов в потоке, при получении SACK-события на поиск SACK пакета уходит слишком много времени, и вы получаете TCP тайм-аут, а CWND возвращается на один пакет. Ограничение размера буфера TCP до 12 MB, по-видимому, позволяет избежать этой проблемы, но определённо ограничивает общую пропускную способность. Другое решение заключается в том, чтобы отключить SACK.
Linux 2.4

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

Однако, Linux 2.4 имеет некоторые другие странности, о которых вы должны знать. Например: Значение ssthresh для данного участка сети кэшировано в таблице маршрутизации. Это значит, что если соединение имеет ретрансляции и уменьшает своё окно, тогда все соединения к этому хосту на следующие 10 минут будут использовать уменьшенный размер окна, и даже не пытаясь увеличить его. Единственный способ отключить такое поведение это выполнить следующее (от суперпользователя) перед всеми новыми соединениями:

1	sysctl -w net.ipv4.route.flush=1

Больше информации о различных параметрах Linux 2.4 доступно в учебнике Ipsysctl.
Linux 2.2

Если вы всё ещё используете Linux 2.2, обновитесь! Если это невозможно, добавьте следующие строки в /etc/rc.d/rc.local

1 2 3 4

echo 8388608 > /proc/sys/net/core/wmem_max echo 8388608 > /proc/sys/net/core/rmem_max echo 65536 > /proc/sys/net/core/rmem_default echo 65536 > /proc/sys/net/core/wmem_default

Оригинал (английский): TCP Tuning Guide
Перевод: © Инициативная группа welinux.ru mhspace, Zereal, Pipeliner, settler.



Большое спасибо nikebl за ссылку на оригинал:)