zinx icon indicating copy to clipboard operation
zinx copied to clipboard

CPU百分百-不懂就问系列

Open Woodswu opened this issue 2 years ago • 3 comments

不懂就问: 不太了解如何调用,于是干脆把代码整个复制,我们是通过NGINX转发到 ZINX -TCP-SERVER上面的,也设了超时时间,每天交易笔数上万笔, 有的时候会CPU暴增,由于pprof没玩明白,只能靠现象盲猜,再某一时刻 突然会阻塞,CPU暴增300%,单独重启TCP服务无效,只能重启NGINX,再重启 TCP SERVER才能好使,看了下整个链路,盲猜可能是handler阻塞导致的 伪代码如下

func (c *Connection) CloseConn() {
	c.Lock()
	defer c.Unlock()
	if c.isClosed == true {
		return
	}
	// 关闭socket链接
	_ = c.Conn.Close()
	//将链接从连接管理器中删除
	c.TCPServer.GetConnMgr().Remove(c)
	c.isClosed = true
}
func (this *InitHandlerRouter) Handle(request ziface.IRequest) {
         //调用了自己的一套协议解决年报组包分包的东西
	defer func() {
		if err := recover(); err != nil {
			request.GetConnection().CloseConn()
                        //此处不知道有没有用反正我return了
			return
		}
	}()
  
       //请求另外一个TCP 服务 。。。。这个地方可能会超时 60秒
        
       //返回报文信息,关闭连接
      request.GetConnection().CloseConn()
}

那么问题来了,CPU暴增的原因,是否是和这个超时有关系,从表现上来看一出现超时,就会出现CPU暴增的情况

有没有好的解决办法,或者优化方案,客户端并非一直长连服务器,发送报文,接受报文连接就关闭了

Woodswu avatar Feb 22 '23 06:02 Woodswu

handler如果真是阻塞,顶多是文件描述符占满,无法再建立链接,但是不应该出现cpu 暴增的情况,阻塞本来就不会占用cpu,而是释放cpu。所以你得看看是否某些业务或者地方出现了循环导致,这种cpu暴增,多数是因为循环或者递归。

aceld avatar Feb 24 '23 02:02 aceld

单独重启TCP服务,tcp连接所占用资源是没有经过释放的。当重启ng后,tcp才会真正断开释放资源; Handle方法隶属于线程池,是接收数据的地方,这个地方你应该做异步处理,不能阻塞哦,不然就阻塞了线程池里面某个线程; 你有上万连接,如果同时接收数据,cpu暴增300%非常合理哦~

xxl6097 avatar Mar 29 '23 08:03 xxl6097

线程阻塞最先崩掉的应该是内存,每个线程的处理channel会塞满,channel长度越大,占用内存越多。

最大内存 = MaxPacketSize * MaxMsgChanLen* WorkerPoolSize

GStones avatar Jun 15 '23 02:06 GStones