自己写的GO服务在跑了几天后会出现所有携程无法服务, 表现在业务携程TCP建立后无法接收TCP recv_q的数据,处理信号的协成无法处理信号,pprof端口在的进程也无法响应。TCP 接受队列堆积
但是 进程还显示100%左右的CPU的占用,
有什么方法进行定位么?
有疑问加站长微信联系(非本文作者)

自己写的GO服务在跑了几天后会出现所有携程无法服务, 表现在业务携程TCP建立后无法接收TCP recv_q的数据,处理信号的协成无法处理信号,pprof端口在的进程也无法响应。TCP 接受队列堆积
但是 进程还显示100%左右的CPU的占用,
有什么方法进行定位么?
有疑问加站长微信联系(非本文作者)
入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889
`单行代码`
服务停掉,再启动,过段时间还会这样?试试 strace,也可以用 gops 试试
现在的感觉是在调度器部分死锁了 gdb进去调试
然后strace 时 显示这样 目前GO 版本是1.6 ,debian
我试试gops ,感觉是不行的。。
有可能是死循环了,查一下所有的for
看看你的 协程里面用到的管道 可能是你的管道卡住了 ===
单一的管道卡主,不会造成所有的协成无法调度 ,看到官方ISSUE里面有提到,目前升级版本没有复现问题。
看到官方ISSUE,有类似的问题,目前升级版本解决》。。。
能否发代码上来看看
https://github.com/xuewindy/dbatman 这个不过不太好看,是个mysql proxy,出问题的环境有几十个库再跑,不知道怎么飞到那里去的 ,有兴趣可以看看。。
被动关闭一方会处于close_wait状态, 没有调用close函数,导致大量的close_wait!
后续这个解决了吗?
数据量太大了吧,处理不过来了