问题整理（此文档来自于24年8月份整理的，对应目前OB版本稍旧）

1.旧OB集群网络问题

8C16G *6
ping 延迟很高（平均5ms）且不稳定会丢包，最大RTT达到53ms

2000并发时监控

事务响应时间300ms，主要是在网络延迟中损耗
经过排查，是物理机CPU过高导致

1500并发时监控—正常

2.新OB集群磁盘问题

22c64g *3

SQL平均响应时间30ms，磁盘性能不足，磁盘使用率达到80%导致，转储导致数据库性能下降

1500并发时监控—正常

使用OB压测工具测试

读写

插入

3.使用MySQL对比（敏感数据不提供截图）

在代码中分片，使用三台MySQL（16c32g，每台可承担700-800并发），可以达到2000并发，平均推送到下游的时间600ms

解决方案

4.提升OB集群硬件

1）OBProxy不要使用虚拟化运行，直接运行在物理机上（和OBServer一样）
2）加OBServer节点
如果是应对突发流量，加内存是非常有效的，因为数据会先存内存和redo盘，后续再转储。如果是长时间的大流量，则数据库就需要多台OBServer，保证转储期间没有性能瓶颈。
另一方面，如果从业务考虑，业务一次事务操作数据库表数量有多个，因此需要的QPS是很大的（业务2000TPS需要数据库8W QPS），而且SQL响应时间如果是30ms，则一笔订单至少需要1.4秒处理时间。

5.下一步的方案

1）升级OB硬件配置
2）目前已使用MySQL验证数据库节点越多业务并发越高。使用现有OB资源测试1500并发，后续业务达到1500再增加OB硬件资源
3）业务代码优化改方案，考虑内存数据库或MySQL数据库分片，减少硬件成本。