我们用的是 django-channels2 + channels-redis2 + daphne2 的框架处理 ws 连接。我们的应用场景是比较简单的，我们平台主要是提供一个进入容器后能和 k8s api-server 实时交互（敲命令）的功能。我们前端通过在 xterm 提供的命令行敲一些命令，并 websocket 连接去连接我们的平台，我们的平台做的就是除了一些简单的初始化后（主要是和 k8s 建立连接，只在连接时做，后面转发就不做了），直接把数据透传给 k8s 的 api-server，然后我们平台收到 k8s 的响应后在透传给前端，展示数据。
这里讲点前序，我们之前采用的是 runserver 的方式启动一个 wsgi 去处理 ws，运行几天后也会卡顿，查看 CPU 大概有 150%，查看线程后发现有 1000 多个线程，但是 tcp 连接没几个，而且有 n 天前进程重启后就创建的线程，后来看 channels 的 issue 得知这是一个没有修复的 bug，然后看了一下文档，好像 dephne 是专门处理 ws 连接的。于是我们改用 dephne 处理 ws 。但是现在的问题是当 daphne 进程启动 2 天以后，我们发现敲命令又开始有点卡顿了（敲键盘后到收到响应大概要 1-2 秒），登陆机器后发现 daphne 进程占用 cpu 大概 180%（ 8C 的机器），线程有 100+个，内存使用正常，连接也正常（ 20 个左右）。线程还有一些一天前创建的，感觉没有释放。跟踪所有线程系统调用发现有很多 futex EAGAIN (Resource temporarily unavailable)的信息，这个查了一下好像在是线程获取锁失败了。daphene 看了也没有报错日志。
为了排查是不是某套 k8s 的 api-server 慢导致的响应慢，我们特意换了其他 k8s 集群做测试，一样卡顿，所以基本排除 api-server 的影响，问题基本确定在我们的平台。现在不知道这个从哪查启，大家遇到过这种问题吗？或者有啥排查思路吗？
这里讲点前序，我们之前采用的是 runserver 的方式启动一个 wsgi 去处理 ws，运行几天后也会卡顿，查看 CPU 大概有 150%，查看线程后发现有 1000 多个线程，但是 tcp 连接没几个，而且有 n 天前进程重启后就创建的线程，后来看 channels 的 issue 得知这是一个没有修复的 bug，然后看了一下文档，好像 dephne 是专门处理 ws 连接的。于是我们改用 dephne 处理 ws 。但是现在的问题是当 daphne 进程启动 2 天以后，我们发现敲命令又开始有点卡顿了（敲键盘后到收到响应大概要 1-2 秒），登陆机器后发现 daphne 进程占用 cpu 大概 180%（ 8C 的机器），线程有 100+个，内存使用正常，连接也正常（ 20 个左右）。线程还有一些一天前创建的，感觉没有释放。跟踪所有线程系统调用发现有很多 futex EAGAIN (Resource temporarily unavailable)的信息，这个查了一下好像在是线程获取锁失败了。daphene 看了也没有报错日志。
为了排查是不是某套 k8s 的 api-server 慢导致的响应慢，我们特意换了其他 k8s 集群做测试，一样卡顿，所以基本排除 api-server 的影响，问题基本确定在我们的平台。现在不知道这个从哪查启，大家遇到过这种问题吗？或者有啥排查思路吗？
Select Language