排查资料对不上问题

回顾问题现象

robot压力测试时,DB的 gdd_log 和 sandbox 的 spin 记录对不上的问题.以下三张表:

  • gdd_log.server_debuglog_new
  • sandbox.prob_spin_request
  • sandbox.prob_spin_result

理论上三张表记录的数据应该是一致的. 实际表现是 当压测量过大时, 三张表的记录量核对不上, 且没有规律可循.

排查过程记录

1. 复现

按照毅信提供的当时出问题的配置参考
sandbox项目有点问题,进行修复.


机器人量:50 , Spin频率:1次/1s , 8核200M带宽:

服务 cpu 流量(in) 流量(out)
gateway 2 n n
game 2 n n

偶尔会报错:

SendRequestToGatewayServer() time out 6.3046658s
12:35:27.667550   16448 [player.go:690] SendRequestToGatewayServer() time out 4.4502964s
2021/11/03 12:35:27.767892 ERROR RESTY Post "http://192.168.0.152:6000/api/player/batchrequest": net/http: timeout awaiting response headers (Client.Timeout exceeded while awaiting headers), Attempt 1
2021/11/03 12:35:27.908471 ERROR RESTY Post "http://192.168.0.152:6000/api/player/batchrequest": net/http: timeout awaiting response headers (Client.Timeout exceeded while awaiting headers), Attempt 1

经排查是因为gate处理请求是单线程方式(之前有提到过). 于是修改为并发模式.
然后反复压测,较低概率会出现数据不一致问题(可能是因为我的开发电脑配置比较高?).

2. 埋点

添加各种埋点日志分析出问题的原因,并且逐渐提高压力量级

机器人量:50 , Spin频率:1次/700ms , 8核200M带宽:

服务 cpu 流量(in) 流量(out)
gateway 2 n n
game 2 n n
  • 现象1:偶尔DB出现报错, timeout, invalid connect 之类 (虚拟机性能跟不上).
  • 现象2:数据对不上的出现概率稍微增加, 但是并没有其他明显错误发生.

3. 搭配Redis进行数据对照

在每次记录日志的时候,同时在redis中也进行记录,核对DB的结果跟Redis的结果一致性.

机器人量:80 , Spin频率:1次/700ms , 8核200M带宽:

服务 cpu 流量(in) 流量(out)
gateway 2 n n
game 2 n n
  • 现象1:DB出现报错, timeout, invalid connect 之类 (虚拟机性能跟不上).
  • 现象2:数据对不上的出现概率相对容易出现.
  • 现象3:3中资料在redis中的统计总是一致的. 但是DB中偶尔确有不一致性(开始怀疑是DB的连接有问题).

4. 调整代码搭配Redis进行数据对照(严格)

在每次记录日志(SQL)的地方,同时在redis中也进行记录,核对DB的结果跟Redis的结果一致性.
排查 DB binlog

机器人量:80 , Spin频率:1次/700ms , 8核200M带宽:

服务 cpu 流量(in) 流量(out)
gateway 5 n n
game 6 n n
  • 现象1:偶尔DB出现报错, timeout, invalid connect 之类 (虚拟机性能跟不上).
  • 现象2:DB的连接数过大(上面现象的原因).
  • 现象3:3中资料在redis中的统计总是一致的. 但是DB中偶尔确有不一致性(确信是DB的连接有问题).
  • 现象4:通过排查binlog,发现本该只出现一条的记录竟然出现了两条一模一样的记录(重点)

5. 调整资料记录相关的代码

现有的代码,存在写入性能不佳,浪费连接问题.进行调整.

机器人量:100 , Spin频率:1次/700ms , 8核200M带宽:

服务 cpu 流量(in) 流量(out)
gateway 6% n n
game 7% n n

  • 现象1:偶尔DB出现报错, timeout, invalid connect 之类 (虚拟机性能跟不上).
  • 现象2:3中资料在redis中的统计总是一致的. DB记录的出错概率下降(偶尔).
  • 现象4:DB的有效连接数明显比之前减少(DB的处理性能得到优化)

总结

1. 业务逻辑
由于我用redis进行详细的同步统计,从这一点可以证明,我们的业务逻辑代码流程是没有问题的.

2. Gateway并发性能
我虽然把gateway的请求由单线程处理修改为并发处理,但是安全性并为评估. 由于gate性能较低,老是会失败,可能会拖累Game的性能. 就算改成并发,再压力为100时,也会偶尔出现 retry 问题. (这个不是Game的问题暂时不管)

3. DB的性能问题
经过调整这三个table写入的相关代码,减少了DB的有效连接,提高了日志写入的吞吐量.DB模块性能得到提升, 所以 现在按100的量级, 资料已经很少出现不对等的情况.

3. 问题的本质
本质原因还是DB的处理性能跟不上,当内存或者CPU存在压力时,出现的异常现象,主要表现为:
1 记录有漏的现象.且有报错
2 记录没有漏, 但是有报错.
3 记录有重复, 但是没报错.

降低DB压力稳定性测试

机器人 虚拟机(DB) 虚拟机 CPU 虚拟机 MEM 流量 服务器 Spin次/机器人 资料一致性 备注
50 本机 200% 60% 60% 本机 100 一致 压测量不大
80 司帅 200% 84% 80% 本机 100 概率不一致 虽然分担了我本机的计算压力,但是DB的压力依然是存在的,并且流量却增加了,随后调整方案
50 司帅+本机 10% 43% 60M 70% 本机 100 一致 按此配置进行了多轮测试,结果均一致.
80 司帅+本机 10% 70% 120M 100% 本机 200 一致 按此配置进行了多轮测试,结果均一致.
90 司帅+本机 15% 84% 130M 100% 本机 500 一致 按此配置进行了多轮测试,结果均一致.
100 司帅+本机 15% 85% 135M 100% 本机 100 一致 按此配置进行了多轮测试,结果均一致.
120 司帅+本机 15% 86% 135M 100% 本机 100 一致 按此配置进行了多轮测试,结果均一致.
150 司帅+本机 15% 86% 135M 100% 本机 100 一致 按此配置进行了多轮测试,结果均一致.
180 司帅+本机 15% 86% 140M 100% 本机 100 一致 按此配置进行了多轮测试,结果均一致.

稳定性总结

  • 刚开始用小量级(50)的机器人测试本机环境,结果都是正常的一致性.

  • 开始使用司帅的虚拟机分担我本机性能压力, 再测试压力量为70-80的时候, 出现了不一致性问题. 因为新的虚拟机分担的并非是DB压力,而是DB压力转移到了新的虚拟机上面,所以触发了不一致性. 同样增加了不少DB之间的流量.

  • 于是采用了 本机虚拟机+新虚拟机 组合的方式 来共同分担DB压力的测试策略.

  • 新的组合方式的确分担了DB的性能压力, 在120量级以内的测试条件中, 测试结果均呈现一致性. 在数据方面:

    • 大约>=90量级的时候的,本机的流量指标已经到达满载状态,后面再增加的时候变化已不大.
    • 大约>=90量级的时候的,虚拟机DB的数据内存指标接近 80%, 后面也没有增幅的空间 .
    • 虽然DB的压力得到分摊,那台新的虚拟机是主DB部分. 上面这个表里面的cpu指标没有统计到(不准确).
  • 后面为了节省测试时间, 把 ‘Spin次/机器人’ 调整为 100.

  • 今天的压测量级只达到150, 目前来看结果表现良好.

  • 从以上测试数据可以证明昨天的结论预测是正确的. 在没有达到DB的性能瓶颈之前, 我们的数据资料结果是高度一致的.

  • 面向AWS的RDS测试时,由于网络问题,不具备测试条件, 未进行测试. 如果真要进行压力测试的话需要起一个新的课题,成本较高,可放到以后再进行.