@timothyye 看看黑五吧，应该有

我一年的成本$30 ，hosthatch 的 2H8G 配置，洛杉矶的服务器

巧了，差不多，不过我的 ssl 是 cf 的，http 回源，而且不是 DO 的 k8s ，是自建 k3s

我记得雅黑探针有些 function 在 php7 不支持，注释掉后少一点东西，两三年前用的时候发现的，现在不知道什么情况

换 debian 吧，你的所有开发和生产需求都会有支持

@Evilk

圣人云，获罪于天，无所祷也。孤天命已尽，安可救乎？

然我赵日天，我命由我不由天！

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

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

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

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

@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 ，你给出的信息还是太少了

@Phishion PHP 曾经是最好的语言，未来有一天一定还会再成为最好的语言。

笑死了，他这个是 jekyll+webstack 模板，改了下样式，我也在用，https://linux.plus/

弄一个出来玩玩儿，好玩我也帮你堆代码

@Donahue 你这个价格上 5600x 也香

@10935336
红帽：centos steam 的小白鼠们真好用

红帽牛逼，我用 debian

@yuandj 突然想起来，如果你没能通过 Timer 解决问题，我建议你再次从 kafka/mysql/redis 阻塞分析，原因是你 kafka 使用的是协程而不是异步任务，协程只能解决单线程 io 阻塞问题，只是能让程序并行处理多个任务，并不能让单个请求的时间减少（并不是多线程执行，请求的线程把任务扔给任务线程后直接返回请求 response ）

如果你 kafka 节点有问题的话，一个请求中，协程依然会等待任务执行完（等待途中 yield 让别的请求执行），等待结束继续处理这个请求，然后返回请求。如果你的框架请求一开始就创建了 mysql 和 redis 连接而没有主动释放，kafka 的阻塞会导致 swoole 维持它们，所有 kafka/mysql/redis 连接数都多。因为 swoole 执行慢，所以 nginx 连接维持时间长，连接看上去也会多

当然还是希望是 Timer 问题，事情就简单很多

@yuandj 根据你#17 的信息，我也觉得可能是 timer 的业务问题，由于 linux 内核的调度器频繁把 cpu 切到定时间的线程执行任务，导致影响了接口主线程执行。但是你的 cpu 负载并没有满，只用了 50%左右，这很奇怪，会有这么大的影响么。还是说你的定时器任务和接口中的代码有关联，导致接口需要等待定时器的任务结果。

如果 swoole 方面不好解决，可以把 nginx 的负载均衡改成最小连接数应急，不过这个方案你应该也知道

我先给出问题的结论：
你的 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 接口慢，这就都解释通了。