游戏终于走到了付费测试阶段啦，头几天遇到了一些奇奇怪怪的问题，记录一下

首先是内存问题，压测没有测到反复登录的情况，线上发现内存占用逐渐上升，到了一个玩家 40M 的惊人水平。正想着手查哪个模块耗的内存多，涛神下来讨论问题，让我先看一下 uniqtask 的返回，结果好家伙，基本上每个 agent 服务上都挂了 400 多个协程在上面，review 下代码发现每个协程都拿着一个角色，导致内存没法释放。兹事体大，没有立即解决挂起的协程了，先热更修复这个代码的问题，然后降低 agent 的复用次数，等玩家自然退出，销毁 agent 来释放内存试试。这里暴露出几个问题：

  1. 对 agent 内模块的内存占用，目前没有分析手段
  2. 协程管理不够完善，玩家下线的时候没有强制关停所有挂起的协程
  3. 原有的 agent 释放机制是按接待的玩家数量来的，达到 limit 后退役对应 agent，面对模拟器一直挂机的玩家会失效，需要重新考量

其次也还是内存问题，轮到 goscon 了 …… 上篇文章 提到 goscon 的良好实现，没有写就不会读，但是线上出现的是可以写，但是没有 ack =_= 看系统内存占用，goscon 的机器才用了 30% 的内存，但是阿里云的告警电话居然打过来了，喊上阿里云的小伙伴一起看，短时间内也没看出个由头。运维同学果断摘掉机器流量，再慢慢抓包查了，排查到最后发现是 goscon 的 Send-Q 偏高，这部分内存不算在进程上，所以容器和进程监控都没报警，用 top 看 goscon 的内存占用也很小。后续监控要加上 Recv-Q 和 Send-Q 这两个指标了。到这里才发现之前压测的时候没理解清楚，我以为现有心跳会超时踢人，结果发现不会，后续要加上踢人的；系统这种奇怪的表现回头也得看看，TCP 连接没有断，滑动窗口也还能写，写出一个巨大的值，对端还会一直没 ack