想问问大家关于 daphne 启动 agsi 处理 websocket 请求导致响应“卡顿”的问题

[zhoudaiyu]

我们用的是 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 的影响，问题基本确定在我们的平台。现在不知道这个从哪查启，大家遇到过这种问题吗？或者有啥排查思路吗？

[ericls]

runserver 用的 也是 daphen, wsgi 是处理不了 asgi 请求的 而 channels 的 websocket 走的是 asgi.
你看看关于连接 open 和 close 的处理是不是有问题，
是不是有些时候创建了 task 没有等返回也没有取消？

[wenqiang1208]

可以把 daphen 启动 asgi 的命令发出来，或者发一个简化版的 websock 终端访问 k8s 的代码 看看 有啥问题

[wenqiang1208]

最近也搞了这个，也没发现啥大问题

[zhoudaiyu]

@wenqiang1208
启动脚本 <a href="https://sm.ms/image/DoYrH5MRAuQVasE" target="_blank"><img src="https://i.loli.net/2021/04/28/DoYrH5MRAuQVasE.png" ></a>

核心代码 <a href="https://sm.ms/image/9qhGHe4byF6DL1Q" target="_blank"><img src="https://i.loli.net/2021/04/28/9qhGHe4byF6DL1Q.png" ></a>
<a href="https://sm.ms/image/Zg8D14Y7Mz5jncQ" target="_blank"><img src="https://i.loli.net/2021/04/28/Zg8D14Y7Mz5jncQ.png" ></a>

[dayeye2006199]

很好奇老哥你们是做什么产品的

[zhoudaiyu]

@dayeye2006199 和运维沾边的都做…

[wenqiang1208]

@zhoudaiyu 我是这样写的