Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Глава 8. Сетевое окружение

Сетевой стек Red Hat Enterprise Linux оптимизирован для разных уровней нагрузки, поэтому в большинстве ситуаций автоматическая конфигурация обеспечивает оптимальную производительность.
Обычно снижение производительности сети наблюдается при сбое оборудования или нарушениях функциональности инфраструктуры. Обсуждение подобных ситуаций выходит за рамки этого документа, поэтому далее будут рассмотрены методы оптимизации рабочих окружений.
Элементы сетевой подсистемы могут включать чувствительные соединения, поэтому и Red Hat, и открытое сообщество уделяют много внимания улучшению возможностей автоматической коррекции производительности.

8.1. Производительность сети

Ниже перечислены основные функции оптимизации производительности сети в Red Hat Enterprise Linux 6.1.

8.1.1. RPS (Receive Packet Steering)

Механизм RPS распределяет нагрузку softirq, поступающую в очередь rx сетевой карты, между процессорами, что позволяет обслуживать запросы параллельно.
Для активации RPS необходимо указать имена процессоров в /sys/class/net/ethX/queues/rx-N/rps_cpus, заменив ethX именем сетевого устройства (например, eth1, eth2), а rx-N обозначением очереди. Пакеты, поступающие в очередь rx-N устройства ethX, будут обрабатываться на заданных процессорах. При выборе процессоров следует учитывать схему привязки кэша[4].

8.1.2. RFS (Receive Flow Steering)

RFS является дополнением RPS и позволяет контролировать выбор ресурсов на основе хэш-таблицы. Таблица заполняется автоматически при обращении к приложениям из сети и регистрирует, на каких процессорах выполняются приложения, получающие пакеты из сети.
На основе этой информации для обслуживания пакетов можно выбрать тот же процессор, на котором выполняется приложение. Параметры конфигурации RFS включают:
/proc/sys/net/core/rps_sock_flow_entries
Максимальное число потоков, перенаправляемых заданному процессору. Это общесистемное значение.
/sys/class/net/ethX/queues/rx-N/rps_flow_cnt
Максимальное число потоков, направляемых в очередь rx-N устройства ethX. Общее число потоков не может превышать /proc/sys/net/core/rps_sock_flow_entries.
RFS допускает совместное использование процессора при получении пакетов из очереди устройства и при обслуживании пакетов из приложения, что в некоторых случаях может улучшить производительность. Однако это зависит и от множества других факторов — иерархии кэша, нагрузки приложений и т.п.

8.1.3. Поддержка тонких потоков TCP в getsockopt

Термин тонкий поток используется для описания обработки пакетов небольшими блоками, что приводит к тому, что механизмы повторной передачи TCP не заполняются полностью. Такая передача используется приложениями, для которых время отклика имеет критическое значение: онлайн-играми, управляющими системами, системами биржевой торговли.
Потеря пакетов для таких приложений недопустима, поэтому вызов getsockopt теперь поддерживает два новых флага:
TCP_THIN_DUPACK
Разрешает динамический переход в режим обработки тонких потоков после получения одного подтверждения dupACK.
TCP_THIN_LINEAR_TIMEOUTS
Включает динамический таймаут для тонких потоков.
Оба параметра должны быть установлены приложением. За дальнейшей информацией обратитесь к file:///usr/share/doc/kernel-doc-версия/Documentation/networking/ip-sysctl.txt и file:///usr/share/doc/kernel-doc-версия/Documentation/networking/tcp-thin.txt.

8.1.4. Поддержка прозрачного прокси

Ядро разрешает подключение сокетов UDP и TCP к прозрачным прокси. Для этого надо будет настроить правила iptables и откорректировать правила маршрутизации.
Подробную информацию можно найти в file:///usr/share/doc/kernel-doc-версия/Documentation/networking/tproxy.txt.

[4] Привязка кэша процессора и сетевого устройства возможна за счет совместного использования кэша L2 (см. Раздел 8.3, «Обзор получения пакетов».