0

以下是我在 linux 系统上处理 tcp 和打开文件的当前值：

$cat /proc/sys/fs/file-max  # outputs 1,624,164.
$cat /proc/sys/net/ipv4/tcp_max_syn_backlog  #outputs 1,048,576
$cat /proc/sys/net/core/somaxconn  # output 65535
$ulimit -a  # open files = 1,024,000, max user processes = 10,240

Q2：我也将redis中的超时设置为0，tcp-keepalive设置为60，tcp-backlog设置为65535。我正在使用predis，我将超时设置为0，read_write_timeout设置为-1 . 但是，我们会定期收到以下错误。

2015-10-28 11:24:14     406309  cron-web        Error while reading line from the server. [tcp://10.0.0.1:6379]
2015-10-28 19:15:13     0       web-billing-3   Error while reading line from the server. [tcp://10.0.0.1:6379]
2015-10-28 19:56:58     0       web-billing-3   Operation timed out [tcp://10.0.0.1:6379]
2015-10-29 10:02:25     437257  web-billing-1   Error while reading line from the server. [tcp://10.0.0.1:6379]
2015-10-29 12:03:54     439897  cron-web        Error while reading line from the server. [tcp://10.0.0.1:6379]
2015-10-29 15:06:23     443772  web-billing-3   Error while reading line from the server. [tcp://10.0.0.1:6379]

我尝试将超时时间更改为 300，但仍然无法正常工作。linux 系统参数的设置也如问题 1 所示。所有这些都无济于事。请问有什么建议吗？

4

1 回答 1

0

似乎这种情况发生在 w/PRedis 之前，它可能是它使用连接的方式导致服务器上的 IP 连接跟踪超载。或者你的脚本启动了“太多”的连接。无论哪种方式，您都可以很容易地弄清楚是否是这种情况。

在 Redis 服务器上，运行dmsg| grep conntrack. 如果您看到类似的消息，ip_conntrack: table full, dropping packet那么这就是问题所在。您可以按照本文中的步骤通过更改/proc/sys/net/ipv4/ip_conntrack_max设置以匹配/超过您在 中看到的峰值来修复它/proc/sys/net/ipv4/netfilter/ip_conntrack_count。

最终，尽管这可能属于超级用户，因为它可能是系统级问题。

编辑：为了确定并发连接，您需要查看info clients并查看当前连接数。您需要随着时间的推移对其进行跟踪以确定并发配置文件是什么，以便查看它是否可能是问题所在。显然，您运行的分辨率越细（即检查和存储的频率越高），您捕获并发峰值的机会就越大。

我真的怀疑问题出在 Predis 上，因为它存在已知的连接管理问题。如果可以，请尝试使用 phpredis 看看它是否继续出现。

于 2015-11-10T15:27:31.953 回答