Что такое "tcp-backlog" в redis.conf

Question

Я смущен tcp-backlog в redis.conf:

# TCP listen() backlog.
#
# In high requests-per-second environments you need an high backlog in order
# to avoid slow clients connections issues. Note that the Linux kernel
# will silently truncate it to the value of /proc/sys/net/core/somaxconn so
# make sure to raise both the value of somaxconn and tcp_max_syn_backlog
# in order to get the desired effect.
tcp-backlog 511

Является tcp-backlog размер "полной очереди подключения" (трехстороннее рукопожатие завершено, что описано здесь) или "неполной очереди подключения"?

Если это означает "полная очередь подключения", то почему я должен поднять tcp_max_syn_backlog что ограничивает размер неполной очереди подключения?

Answer 1

Является ли tcp-backlog размером "полной очереди подключения" (трехстороннее рукопожатие завершено, что описано здесь) или "неполной очереди подключения"?

tcp-backlog размер полной очереди подключения. Фактически, Redis передает эту конфигурацию как второй параметр listen(int s, int backlog) вызов.

У @GuangshengZuo уже был хороший ответ на этот вопрос. Поэтому я сосредоточусь на другом.

Если это означает "полная очередь соединений", то почему я должен поднимать tcp_max_syn_backlog, который ограничивает размер неполной очереди соединений?

Цитата из документа, который вы упомянули:

Реализация использует две очереди: очередь SYN (или очередь неполного соединения) и очередь приема (или очередь полного соединения). Соединения в состоянии SYN RECEIVED добавляются в очередь SYN, а затем перемещаются в очередь приема, когда их состояние изменяется на ESTABLISHED, т.е. когда принимается пакет ACK в 3-стороннем рукопожатии. Как следует из названия, вызов accept затем реализуется просто для использования соединений из очереди accept. В этом случае аргумент backlog системного вызова listen определяет размер очереди приема.

Мы можем видеть, что предметы в complete connection queue перемещены из incomplete connection queue,

Если у вас есть большой somaxconn с небольшим tcp_max_syn_backlog, тогда у вас может быть недостаточно предметов для перемещения на complete connection queue и complete connection queue может никогда не быть полным. Многие запросы уже могут быть удалены из первой очереди, прежде чем они смогут переместиться во вторую.

Так что только поднять ценность somaxconn может не работать. Вы должны поднять их обоих.

Answer 2

Tcp-backlog - это размер очереди приема или полной очереди подключения.

Как сказано в ваших документах:

В Linux все по-другому, как упомянуто на странице руководства системного вызова listen:

Поведение аргумента backlog на TCP-сокетах изменилось в Linux 2.2. Теперь он задает длину очереди для полностью установленных сокетов, ожидающих принятия, вместо количества незавершенных запросов на подключение. Максимальная длина очереди для неполных сокетов может быть установлена ​​с помощью /proc/sys/net/ipv4/tcp_max_syn_backlog.

Это означает, что в текущих версиях Linux используется вторая опция с двумя различными очередями: очередь SYN с размером, заданным общесистемным параметром, и очередь приема с размером, указанным приложением.

Сервер Redis использует конфигурацию tcp-backlog для указания размера очереди приема с помощью listen(). И размер очереди SYN определяется администратором Linux.

Если это означает "полная очередь соединений", то зачем мне поднимать tcp_max_syn_backlog, который ограничивает размер очереди неполных соединений?

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

А в некоторых случаях SYN-очередь будет заполнена этими неэффективными клиентами. Если очередь SYN заполнена, сервер Redis не может принимать новых клиентов. Поэтому вы должны поднять tcp_max_syn_backlog, чтобы справиться с этим.

Answer 3

Вчера я прочитал главу 6 в Redis In Action, где Джошуа Карлтон пишет, что "Одним из недостатков модели Redis Publish and Subscribe является то, что клиент должен быть постоянно подключен для получения сообщений, разъединение может привести к потере сообщений, и более старые версии Redis могут стать непригодными к использованию, аварийно завершить работу или быть убиты, если подписчик будет медленным ".

Затем Джошуа Карлтон заявляет: "Хотя push-сообщения могут быть полезны, мы сталкиваемся с проблемами, когда клиенты не могут оставаться на связи все время по той или иной причине. Чтобы устранить это ограничение, мы напишем два разных метода обмена сообщениями по запросу. может использоваться в качестве замены для PUBLISH/SUBSCRIBE. Сначала мы начнем с обмена сообщениями с одним получателем, поскольку он имеет много общего с нашими очередями "первым пришел - первым вышел". Далее в этом разделе мы перейдем к метод, в котором у нас может быть несколько получателей сообщения. При наличии нескольких получателей мы можем заменить Redis PUBLISH и SUBSCRIBE, когда нам нужно, чтобы наши сообщения были доступны всем получателям, даже если они были отключены. "Нам интересно знать, будет ли оно более производительным заменить Redis PUBLISH и SUBSCRIBE на раздел 6.5.2 Джошуа Карлтона о замене публикации / подписки с несколькими получателями вместо использования протокола UDP для обнаружения и исправления потери при отключении.

 Could we set a high tcp_max_syn_backlog in redis.conf to prevent either of

Обмен сообщениями Джошуа Карлсона с одним получателем и методы обмена сообщениями с несколькими получателями от отключения при нагрузке 20000 сообщений в секунду, где каждое сообщение составляет 20 байтов?