我先给出问题的结论：
你的 kafka 集群中，存在某个单节点写入过慢 /负载过高。而且你的 kafka 负载均衡被连接后会固定写入某个到了某个节点。



首先和你的内核参数关系不大，qps 600 只要 ulimit -n 调大一点，就一切 ok 。

根据你提供的信息，我整理下现状：
1. 有问题的服务器 php 和 ruby 的 cpu 占用都大，但是 cpu 使用率都没有达到 100%。
2. 有问题的服务器 swap 占用过多，但不明显，只有 100MB 。
3. 有问题的服务器存在大量 connection 存在 dose not exists 。
4. nginx 是轮询 php 后端。
5. php 业务链接 kafka/mysql/redis 。
6. 有问题的 swoole 对 kafka 有多 1 倍的连接数，对 nginx 的连接数比正常的少 20%。
7. 只有 3 台固定的 swoole 有以上问题。
8. 有问题的 swoole 请求时间过长。




下面说下问题解析，如果以上信息没有提供错误的话，可以得到以下结论：

一、 主要现象是 php 接口过慢。所以一下现象可以正常解释：
1. 会出现大量 connection 错误。因为接口慢，所有 client 等不及关掉连接，或者刷新。
2. php 、ruby(fluentd)、supervisord 的 cpu 过高，但是 ruby 内存占用小。因为大量 connection 错误，所以 swoole 频繁写入日志，从而导致 fluentd 频繁调起读取日志发送或写入 buffer 。而日志都是 connnect 错误，字符少，所有内存占用少。同时我可以推测你的 fluentd 是 supervisord 管理的，所以 supervisord 频繁调起 fluentd ，导致它自己的 cpu 也高。

二、另一个现象是 3 台固定的 swoole 有问题。这个问题可以排除和定位问题：
1. nginx 没问题。虽然我推测可能是 nginx 负载均衡算法问题，或者说 nginx 轮询没有真实的运行，但是这个是解释不通的。首先 nginx 基本不可能出问题，有问题也极难遇到，当然我说的是你用的 stable 版。即使是 nginx 问题，那么出现 3 台固定 swoole 有问题，只有可能是有人用固定几个 ip 在 cc 攻击，才会导致 nginx 转发到这 3 台 swoole 。但是你 600 的 qps ，能 cc 0.6k 我还没见过这么抠的。
2. swoole 业务代码自身没问题。如果是 woole 业务代码逻辑问题，那么问题应该是随机出现在不同 swoole 服务器上，而不是固定 3 台。
3. swoole 所在物理服务器没问题。可能是内存颗粒有问题，导致处理业务数据过慢。但是我想你用的应该是 kvm 云服务器。而 3 台都落在一台云服务物理服务器可能性不大，即使存在云服务商应该能检查出来，会即使通知你，并更换内存条。当然也有极微可能是这个问题。
4. swoole 所在屋里服务器随机 io 满负荷。这个是有可能的，可能是你这 3 台 swoole 由于 connnection 错误日志太多，php 写入和 fluentd 读取导致 io 爆满。但是你的是 8H8G 的服务器，而且只有 600qps ，所有基本不可能。

三、为什么我推测是 kafka 单节点有问题。
1. 不是 mysql 问题，如果是 mysql 问题，例如业务 sql 读取大量数据，问题应该是随机出现在不同 swoole 服务器上。
2. 不是 redis 问题，原因如上。
3. kafka 情况有点不同，我推测你的 swoole 和 kafka 之间是 swoole 启动时和 kafka 创建的长连接，所以这 3 台固定写入到某个节点，而这个节点写入过慢，写入过慢所以 swoole 会维持连接，你看到的连接数就会更多。同时写入过慢所以你的 php 接口慢，这就都解释通了。