Приветствую, друзья!

В предыдущих двух статьях (раз, два) мы погружались в сложность выбора между технологиями и искали оптимальные настройки для нашего решения в Ostrovok.ru. Какую тему поднимем сегодня?

Каждый сервис должен работать на каком-то сервере, общаясь с железом посредством инструментов операционной системы. Этих инструментов великое множество, как и настроек для них. В большинстве случаев для их работы настроек по умолчанию будет более чем достаточно. В этой статье я хотел бы рассказать о тех случаях, когда стандартных настроек все-таки было недостаточно, и приходилось знакомиться с операционной системой чуть ближе – в нашем случае с Linux.

Используем ядра с умом

В предыдущей статье я говорил о параметре cpu-map в Haproxy. С его помощью мы привязывали процессы Haproxy к потокам одного ядра на двухпроцессорном сервере. Второе ядро мы отдали под обработку прерываний сетевой карты.

Ниже скрин, на котором можно увидеть подобное разделение. Слева ядра заняты Haproxy в user space, а справа – обработкой прерываний в kernel space.



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

В Haproxy мы привязывали процессы к ядрам, начиная с первого ядра. Этот же скрипт привязывает прерывания, начиная с последнего. Таким образом, мы можем разделить процессоры сервера на два лагеря.

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

Раскрываем возможности сетевых устройств

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

Поговорим же о буфере сетевой карты. Чаще всего в значениях по умолчанию используется не весь доступный буфер. Посмотреть текущие параметры можно, используя мощную утилиту ethtool.

Пример использования команды:

> ethtool -g eno1
Ring parameters for eno1:
Pre-set maximums:
RX:             4096
RX Mini:        0
RX Jumbo:       0
TX:             4096
Current hardware settings:
RX:             256
RX Mini:        0
RX Jumbo:       0
TX:             256

А теперь возьмем от жизни все:

> ethtool -G eno1 rx 4096 tx 4096
> ethtool -g eno1
Ring parameters for eno1:
Pre-set maximums:
RX:             4096
RX Mini:        0
RX Jumbo:       0
TX:             4096
Current hardware settings:
RX:             4096
RX Mini:        0
RX Jumbo:       0
TX:             4096

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

Минимум sysctl настроек для максимальной пользы

В Sysctl великое множество параметров всех цветов и размеров, которые только можно представить. И, как правило, статьи в интернетах, затрагивая вопрос оптимизации, охватывают довольно внушительную часть этих параметров. Я рассмотрю только те, которые было реально полезно поменять в нашем случае.

net.core.netdev_max_backlog – очередь, куда попадают фреймы из сетевой карты, которые затем обрабатываются ядром. При быстрых интерфейсах и больших объемах трафика она может быстро заполняться. Default: 1000.
Мы можем наблюдать за превышением этой очереди глядя на вторую колонку в файле /proc/net/softnet_stat.

awk '{print $2}' /proc/net/softnet_stat

Сам файл описывает структуру netif_rx_stats по строке на каждый CPU в системе.
Конкретно вторая колонка описывает количество пакетов в состоянии dropped. Если значение во второй колонке со временем растет, то вероятно стоит увеличить значение net.core.netdev_max_backlog или поставить CPU по-шустрее.

net.core.rmem_default / net.core.rmem_max && net.core.wmem_default / net.core.wmem_max – эти параметры указывают значение по умолчанию / максимальное значение для буферов сокета на чтение и запись. Default значение может быть изменено на уровне приложения в момент создания сокета (кстати, в Haproxy есть параметр, который это делает). У нас бывали случаи, когда ядро накидывало пакетов больше, чем успевал разгребать Haproxy, и тогда начинались проблемы. Поэтому штука важная.

net.ipv4.tcp_max_syn_backlog – отвечает за лимит новых еще не установленных соединений, для которых был получен SYN пакет. Если есть большой поток новых соединений (например, много HTTP запросов c Connection: close), есть смысл поднять это значение, чтобы не терять время на пересылке потерявшихся пакетов.

net.core.somaxconn – тут уже речь про установленные соединения, но еще не обработанные приложением. Если сервер однопоточный, а к нему пришло два запроса, то первый запрос будет обработан функцией accept(), а второй будет висеть в backlog, за размер которого и отвечает этот параметр.

nf_conntrack_max – вероятно, самый известный из всех параметров. Думаю, почти каждый, кто имел дело с iptables, знает о нем. В идеале, конечно же, если вам не нужно использовать iptables masquerading, то можно выгрузить модуль conntrack и не думать об этом. В моем случае используется Docker, поэтому особо ничего не выгрузишь.

Мониторинг. Очевидный и не очень

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

nf_conntrack_count – самая очевидная метрика. По ней можно следить сколько соединений сейчас находится в conntrack таблице. При переполнении таблицы путь для новых соединений будет закрыт.

Текущее значение можно посмотреть здесь:

cat /proc/sys/net/netfilter/nf_conntrack_count

Tcp segments retransmited – количество пересылок сегментов. Метрика очень объемная, так как может говорить о проблемах на разных уровнях. Рост пересылок может свидетельствовать о проблемах с сетью, о необходимости оптимизации настроек системы или даже о том, что конечное ПО (например, Haproxy) не справляется со своей работой. Как бы там ни было, аномальный рост этого значения может служить поводом для разбирательств.



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

Пример для проверки:

netstat -s|grep 'segments retransmited'

Socket Recv-Q — помните, мы говорили о моментах, когда приложение может не успевать отрабатывать запросы, и тогда socket backlog будет расти? Рост этого показателя совершенно ясно дает понять, что с приложением что-то не так и оно не справляется.

Я лицезрел горы на графиках с этой метрикой, когда параметр maxconn в Haproxy имел значение по умолчанию (2000), и тот попросту не принимал новых соединений.

И снова пример:

ss -lntp|awk '/LISTEN/ {print $2}'

Еще не лишним будет иметь график с разбивкой по состояниям TCP соединений:



И отдельно вынести time-wait/established, т.к. их значения, как правило, сильно отличаются от остальных:



Помимо этих метрик есть множество других, но уже более очевидных – например, загруженность сетевого интерфейса или CPU. Их выбор будет уже больше зависеть от специфики вашей нагрузки.

Вместо заключения

В общем-то, на этом все – я постарался описать ключевые моменты, с которыми мне довелось столкнуться при настройке http reverse proxy. Казалось бы, задача не сложная, но с ростом нагрузки растет и количество подводных камней, которые всегда всплывают не вовремя. Надеюсь, эта статья поможет вам избежать тех сложностей, с которыми пришлось столкнуться мне.

Всем Peace