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

меня смущает 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

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

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

7
backlog redis tcp

3 ответов

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

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

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

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

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

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

видно, что элементов complete connection queue переехали из incomplete connection queue.

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

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

1

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

Как сказали упомянутые вами документы:

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

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

Это означает, что текущие версии Linux используют второй вариант с две очереди: очередь SYN с размером, заданным системной настройкой, и очередь accept с размером, заданным приложением.

Redis server используйте конфигурацию TCP-backlog, чтобы указать размер очереди приема с слушать.)( И размер очереди SYN определяется администратором linux.

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

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

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

2

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

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

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

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

0