高并发服务器 tcp 内核参数优化及对于连接池配置数量请教

[yuandj]

现在遇到的问题：

现在业务有 15 台服务器做负载均衡，nginx 轮询方案。其中有 3 台服务器，对 kafka 集群、mysql 、redis 的连接数，要大于其他的服务器。造成这 3 台的接口响应时长比较长。

服务器配置相同（ 8 核 8G ）；

跑的项目相同：

php 语言，hyperf2.0 框架，接口整体 qps 目前在 9000 左右，单机负载 qps600 左右。

服务器承载的 qps 相近，都是 600 左右。

新建服务器时，用的同一个镜像，但是都进行过一些 tcp 参数调优：

echo '1200'> /proc/sys/net/ipv4/tcp_keepalive_time
echo '8192'> /proc/sys/net/ipv4/tcp_max_syn_backlog
echo '10000'> /proc/sys/net/ipv4/tcp_max_tw_buckets
echo '1'> /proc/sys/net/ipv4/tcp_tw_reuse
echo '30'> /proc/sys/net/ipv4/tcp_fin_timeout
echo '1024 65000'> /proc/sys/net/ipv4/ip_local_port_range
echo '131072' > /proc/sys/net/ipv4/tcp_max_orphans
echo '383652 511537 767304' > /proc/sys/net/ipv4/tcp_mem
echo '32768' > /proc/sys/net/ipv4/tcp_max_orphans
echo '93723 124966 187446'> /proc/sys/net/ipv4/tcp_mem

下面是两台服务器连接数的情况：

#正常的服务器
941 10.10.45.199
357 10.10.55.43
356 10.10.28.148
353 10.10.85.51
320 10.10.59.7

#异常的服务器
771 10.10.45.199
652 10.10.55.43
651 10.10.28.148
649 10.10.85.51
442 10.10.58.73

# 45.199 是 nginx 服务器；排在前 2 、3 、4 的是 Kafka 集群；可见异常的服务器连接数比正常的服务器要多

疑问：

1. 有没有哪位大佬知道可能存在的原因是什么呢？并且如何解决呢？

[geligaoli]

几百的连接数，不 TCP 调优也足够用了。还是看看接口中的业务逻辑调用吧，估计是业务处理慢，连接也就释放不了

[yuandj]

@liuxu 排除了一下，不是定时器的问题。

后来尝试把异常的三台服务器的 swoole worker number 调整为了 8 ，其他的是 16 ，初步观察变得正常了，所以推测还是程序处理慢，cpu 切换频繁带来的性能消耗。

但是如果是 redis 或者 kafka 响应慢，也不应该只出现在这几台服务器上。所以这个问题还需要继续排查

[liuxu]

@yuandj

mysql/redis 不太可能，他们是单机，如果有问题，应该是你所有 swoole 随机出现问题

我之所推测是 kafka 的问题，是因为你的 kafka 是集群，而集群中一个 topic 有多个 partition ，而且 kafka 可以指定 key ，我是推测你是写入到某个特定的 partition 了，而这个 partition 所在服务器的磁盘 io 爆了，或者内存爆了大量 swap 占用

但是也只是根据已有信息做的推测，更准确的定位方法起码得知道 nginx 配置，nginx 服务器硬件 benchmark ，php 接口 profile （分析所有外部 io 调用，kafka ，mysql 等等），php 机器 benchmark ，kafka 服务器 benchmark

最重要的就是 php 的 profile ，你给出的信息还是太少了

[liuxu]

@yuandj 我不知道为什么你把 swoole 的 worker 16 改成 8 就正常了，据我的经验，你的系统是 io 任务处理不及时导致，如果减少 worker ，或导致 nginx 随机抛出 502 timeout ，因为 swoole 来不及处理所有请求返回，目前来看是很奇怪的

[yuandj]

@liuxu worker 个数和 cpu 核心数一致，可以减少 CPU 切换的 IO

比如 8 核机器，开 16 个 worker ，那么这 8 核需要在 16 个 worker 中来回切换

如果只开 8 个 worker ，一个核对一个 worker ，就减少了 CPU 的切换 io

之所以没有出现 502 ，可能是因为目前的量没到达顶峰。并且到达顶峰后，也不会报 502 ，表现是 worker 处理的慢，接口响应增长，nginx 那边超时断连，会返回 499.

[liuxu]

@yuandj 额。。CPU 切换导致额外的性能消耗，你说的原理是没错。。但是你的实际情况是你 CPU 都没跑满，才 50%，只有负载过了 100%才会逐渐显露上下文切换衰减问题。。

http 的语义，4xx 是客户端错误，worker 处理慢 nginx 超时断开连接，会返回 5xx 服务端错误。qps 上限最开始会返回 502 Bad Gateway ，也就是 timeout ，后面压力越来越大 swoole 彻底崩了后，nginx 一般是返回 503 Service Unavailable 。。

你不跑 profile 再怎么分析都是猜拳，还是希望你自己能早点彻底解决吧