13

我对tcp-backlogredis.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限制不完整连接队列的大小？

4

3 回答 3

9

tcp-backlog 是“完整的连接队列”（三次握手完成，这里描述的内容）的大小还是“不完整的连接队列”的大小？

tcp-backlog是完整连接队列的大小。实际上，Redis 将这个配置作为listen(int s, int backlog)调用的第二个参数传递。

@GuangshengZuo 对于这个问题已经有了很好的答案。所以我会专注于另一个。

如果它意味着“完整的连接队列”，那么我为什么要提高 tcp_max_syn_backlog 来限制不完整的连接队列的大小？

引用您提到的文档：

该实现使用两个队列，一个 SYN 队列（或不完整的连接队列）和一个接受队列（或完整的连接队列）。处于 SYN RECEIVED 状态的连接被添加到 SYN 队列中，然后当它们的状态变为 ESTABLISHED 时，即收到 3 次握手中的 ACK 数据包时，将移动到接受队列中。顾名思义，accept 调用的实现只是为了使用来自接受队列的连接。在这种情况下，listen 系统调用的 backlog 参数决定了接受队列的大小。

我们可以看到里面的项目complete connection queue是从incomplete connection queue.

如果您有一个大somaxconn的和一个小的tcp_max_syn_backlog，那么您可能没有足够的物品可以移动到complete connection queue，并且complete connection queue可能永远不会满。许多请求在有机会移动到第二个队列之前可能已经从第一个队列中删除。

所以只提高somaxconn可能行不通的值。你必须提高他们两个。

于 2017-08-22T05:54:17.950 回答
4

tcp-backlog 是接受队列或完整连接队列的大小。

正如您提到的文档所说：

在 Linux 上，情况有所不同，如 listen 系统调用的手册页所述：

TCP 套接字上 backlog 参数的行为在 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服务器进行3次握手，并且这些客户端读取响应和发送请求的速度很慢，它们会因为速度慢而占用redis服务器的SYN队列很长时间。

在某些情况下，SYN 队列会因为这些低效的客户端而被填满。如果 SYN 队列被填满，redis 服务器将无法接受新的客户端。所以你应该提高 tcp_max_syn_backlog 来处理这个问题。

于 2017-08-22T04:09:24.973 回答
0

昨天，我在 Redis In Action 中阅读了第 6 章，其中 Joshua Carlton 写道：“Redis 发布和订阅模型的缺点之一是客户端必须始终连接才能接收消息，断开连接会导致客户端丢失消息，如果订阅者速度较慢，旧版本的 Redis 可能会变得无法使用、崩溃或被杀死。”

然后，Joshua Carlton 表示，“虽然推送消息很有用，但当客户端由于某种原因不能一直保持连接时，我们会遇到问题。为了解决这个限制，我们将编写两种不同的拉取消息方法，可以用作 PUBLISH/SUBSCRIBE 的替代品。我们将首先从单一收件人消息传递开始，因为它与我们的先进先出队列有很多共同之处。在本节的后面，我们将转到我们可以有多个消息收件人的方法。对于多个收件人，当我们需要将消息发送给所有收件人时，我们可以替换 Redis PUBLISH 和 SUBSCRIBE，即使他们已断开连接“我们很想知道它是否会更高效用 Joshua Carlton 的第 6.5 节替换 Redis PUBLISH 和 SUBSCRIBE。2 多接收者发布/订阅替换，而不是利用UDP协议来检测和修复断开连接丢失。

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

Joshua Carlson 的单收件人消息传递和多个收件人消息传递方法在每秒 20,000 条消息的负载下断开连接，其中每条消息为 20 个字节？

于 2018-02-07T12:14:31.537 回答