Назад | Перейти на главную страницу

Будет ли иметь значение увеличение net.core.somaxconn?

У меня возник аргумент по поводу параметра net.core.somaxconn: мне сказали, что это не будет иметь никакого значения, если мы изменим значение по умолчанию 128.

Я полагал, что этого может быть достаточно доказательств:

«Если аргумент невыполненной работы больше, чем значение в / proc / sys / net / core / somaxconn, то он автоматически усекается до этого значения» http://linux.die.net/man/2/listen

но это не так.

Кто-нибудь знает способ засвидетельствовать это с помощью двух машин, находящихся в сети Gbit? Лучше всего было бы против MySQL, LVS, apache2 (2.2), memcached.

Настройка net.core.somaxconn к более высоким значениям требуется только на высоконагруженных серверах, где новая скорость соединения настолько высока / скачкообразна, что имеет 128 (на 50% больше в BSD: 128 backlog + 64 half-open) еще не принятые соединения считаются нормальными. Или когда вам нужно передать определение «нормального» самому приложению.

Некоторые администраторы используют высокий net.core.somaxconn чтобы скрыть проблемы с их услугами, чтобы с точки зрения пользователя процесс выглядел как всплеск задержки вместо прерывания / тайм-аута соединения (контролируется net.ipv4.tcp_abort_on_overflow в Linux).

listen(2) инструкция говорит - net.core.somaxconn действует только верхняя граница для приложения, которое может выбрать что-то меньшее (обычно устанавливается в конфигурации приложения). Хотя некоторые приложения просто используют listen(fd, -1) Это означает, что для невыполненной работы необходимо установить максимальное значение, разрешенное системой.

Реальной причиной является либо низкая скорость обработки (например, однопоточный блокирующий сервер), либо недостаточное количество рабочих потоков / процессов (например, многопоточное / блокирующее программное обеспечение, такое как apache/tomcat)

PS. Иногда предпочтительнее быстро выйти из строя и позволить балансировщику нагрузки выполнить свою работу (повторить попытку), чем заставлять пользователя ждать - для этой цели мы устанавливаем net.core.somaxconn любое значение и ограничить отставание приложения, например, 10 и установить net.ipv4.tcp_abort_on_overflow к 1.

PPS. В старых версиях ядра Linux есть неприятная ошибка усечения somaxcon значение для его 16 младших битов (т.е. приведение значения к uint16_t), поэтому увеличивая это значение до более чем 65535 может быть даже опасным. Для получения дополнительной информации см .: http://patchwork.ozlabs.org/patch/255460/

Если вы хотите более подробно ознакомиться со всеми внутренними функциями бэклога в Linux, не стесняйтесь читать: Как TCP backlog работает в Linux.