我对tcp-backlogredis.conf 感到困惑:
tcp-backlog
# 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- backlog
如果它表示“完整连接队列”,那我为什么要提高tcp_max_syn_backlog它来限制不完整连接队列的大小?
tcp_max_syn_backlog
tcp-backlog是“完整连接队列”(三向握手完成,此处描述什么)的大小还是“不完整连接队列”的大小?
tcp-backlog是 完整连接队列 的大小。实际上,Redis将此配置作为listen(int s, int backlog)呼叫的第二个参数传递。
listen(int s, int backlog)
@GuangshengZuo已经很好地回答了这个问题。因此,我将专注于另一个。
如果它表示“完整连接队列”,那为什么我应该提高tcp_max_syn_backlog来限制不完整连接队列的大小?
引用您提到的文档:
该实现使用两个队列,一个SYN队列(或不完整的连接队列)和一个接受队列(或完整的连接队列)。将状态为SYN RECEIVED的连接添加到SYN队列中,然后在状态变为ESTABLISHED时(即,在收到3次握手中的ACK数据包时)将其移至接受队列。顾名思义,然后简单地实现accept调用以消耗来自accept队列的连接。在这种情况下,listen syscall的backlog参数确定接受队列的大小。
我们可以看到中的 项目complete connection queue已从中移出incomplete connection queue。
complete connection queue
incomplete connection queue
如果您有一个somaxconn带有小号的大号tcp_max_syn_backlog,则可能没有足够的项目移动到complete connection queue,并且complete connection queue可能永远不会满。许多请求可能已经从第一个队列中删除,然后才有机会被移至第二个队列。
somaxconn
因此,仅提高的价值somaxconn可能行不通。你必须两个都养。