Dubbo调优经历
原型阶段,主要影响如下:
服务的日志I/O 会影响性能。
数据库的I/O 会严重影响性能。
服务的部署情况 会影响性能。
原型优化:
1.优化数据库,尝试使用内存,增大内存buff。
2.调整服务部署,服务间调用,由于该宿主机器的cpu占用率不同和磁盘I/O网络等不同,需要不断的尝试服务部署机器之间的分配,要将需求资源大的服务部署在较好的环境,并且竞争较少的情况可以提升tps。
3. 服务本身耗时极低,几乎忽略。
4.将调用者和被调用者尽量部署在同一宿主机,可以降低一部分耗时。
5.将所有服务部署在一台非常好的机器 32U 128G机器上,CPU /内存皆没达到瓶颈,将数据库部署在另外一台这样的PC物理机上,延迟会大大降低,但是依然存在RPC调用在400并发下8-10秒的耗时。(后续可以优化这个RPC耗时)
过程:
使用工具:
Linux 常用工具包
Jemeter http post请求
涉及中间件:
Zookeeper
Redis
原型阶段:
共涉及服务10个,涉及数据库5个。内部协议 dubbo 对外协议:rest
部署大致如下:
3台pc机,3台宿主机,超分,每个虚机上部署一个服务。大致是宿主机4颗8核2GHz *2、4颗6核心1.87GHx *1、4C8G PC机8台。
部署完后直接使用jemeter跑出结果 1700TPS。
现象:各服务和数据库的cpu都不高,三台数据库io很高,相关应用服务出现网络阻塞等待。
分析结果:三台数据库插入操作多,数据库服务器的磁盘io达到瓶颈
改动1:因为资源有限,无法顾及I/O问题,顾临时修改数据库为内存写,不落盘。TPS提升
但是查看到redis内存消耗不足,redis服务器内存达到瓶颈
此时tps:2400
改动2: 将Redis移至主频和内存高的pc机,资源有限,将原本pc机上的服务移至虚机。
Tps提示至2800
资源有限,没有进一步测试。
后将服务的分布调整更合理之后,并将数据库部署在本地PC机上,磁盘IO 单线程10M/s的情况下,并发数400达到TPS 3800.
Duboo单服务调用,使用rest接口,TPS 1W9(关掉日志等IO影响)(开启日志1W3 达到写日志磁盘I/O瓶颈 写等待出现队列 utils 90%)