C++游戏服务器的性能优化

以下是最近某个项目的一次经历,最终并没有按照这样的方案来优化,但对思路确实是一个提高,所以记录在此。

-------------------------------------------------------------------------------------------------------------------

项目D为单机服务器,据说在线达到1500后,会很卡,于是想仔细分析了其中的原因。

整体来说:C++服务器+mysql数据库,多线程。但是是单服。

请教了前同事,在他的一步步询问下,理清了服务器的当前架构。

同事指导,对于服务器性能分析,要从内存分配多线程两个方面入手。

修改内存分配策略不但能降低内存,还能减少碎片,最终势必会提高游戏性能(分配阻塞导致性能低)。

使用多线程,将复杂的逻辑异步到不同的线程去计算,减少了主逻辑的等待,也必然提高了流畅性。

 

线程方面:

1 一个socket负责监听所有客户端的session。使用了完成端口的概念,起了3个线程,负责收消息,收到后,将消息放入一个全局的队列revQueue中,这个队列包含所有玩家的所有消息。

2 全局的session管理类,管理所有客户端的session。每个玩家发送消息时,写入自己的发消息队列ownSendQueue中。

3 一个单独的数据库操作队列dbQueue,负责所有对数据库的读取。

4 启动游戏时,开了一个线程,专门负责内部逻辑的刷新。包括各种timer,数据库队列dbQueue的分发,全局收消息队列revQueue的分发(每次轮询到时,会将队列中的所有消息都分发出去),每个session的发消息队列ownSendQueue,其它游戏内的各种update(血量体力等各种恢复)。

内存分配:

1 会频繁使用到标准库的map,vector,string对象。

2 对自定义的类,有内存池的管理策略。当前策略:

  • 每种自定义对象,第一次请求内存时,由内存池多分配32个可保存此类型的地址。
  • 以后每次请求,从预先分配的地址中直接获取。
  • 直到预分配的地址使用完,再重新分配32个,依次循环。
  • 对象销毁时,不真正将对象交还操作系统,而是插入到可用的预分配表中。

 

再来看下服务器当前的配置,在线人比较多的一个区服务器,包括三组服务器:

32G内存+10个CPU,每组在线约300人。cpu使用7%左右,内存使用17%左右。

 

这一系列的分析出来,问题相对而言就明显了。

内存没有达到有效的使用。

逻辑全在一个线程,应该就是整个瓶颈所在了。

 

针对问题提出的优化策略:

1.内存分配方法

对于已有的内存池策略:

  • 是否可在程序启动时,直接分配固定的内存数(比如3000,可根据在线人数确定)。占用一定内存开销,提高运行时效率。需要数据验证可行性。
  • 每次增长的数(目前32)是否可优化为更大,或者修改为梯形增长方式,或者以每次2倍的速度增长?需要数据验证可行性。

彻底的接管内存分配

  • 使用gperftools的tcmalloc组件彻底接管内存分配。配置很方便,编译时增加一个链接选项即可。(https://my.oschina.net/u/877348/blog/272066)

  初步测试,接入tcmalloc后,内存占用由原来的107448降为67108,提高大约40%,可验证对在线的影响。

2.并行计算

  • 修改完成端口启动的线程数目,提高CPU 使用率,可有效提高网络通信的吞吐量。目前为3,一般设置为CPU数*2。
  • 目前所有玩家的逻辑都在一个线程处理,考虑使用多线程的可行性。

 

以上是在不改变当前单服的状态下,可做出的优化。毕竟单服总有上限,如果以上的优化都不能达到想要的效果,就要拆分服务器了。

  • 增加LoginServer

Gate和Master之间增加LoginServer,或者Gate本身增加LoginServer的功能。

负责:登陆验证、创角、角色列表、删角、 封禁IP过滤等处理,其它逻辑交给Master。

  • 增加LogServer

增加LogServer,监听Master传送的消息,专门负责和logDB的交互。

  • 其它

上述修改完成后,如果在线依然无法满足,可根据统计数据,逐步拆分出GameGate,GMGate,ChatServer,TaskServer,DBServer。

 

 -------------------------------------------------------------------------------------------------------------------

再次重复下,以上只是某个项目的一次经历,最终并没有按照这样的方案来优化,但对思路确实是一个提高,所以记录在此。

 

posted @ 2017-03-11 15:39  彼岸Elan  阅读(3390)  评论(1编辑  收藏  举报