loop in codes

Kevin Lynx BLOG

谈谈我们的游戏逻辑服务器实现(二)

上一篇谈了一些关键技术的实现方案。本篇描述一些遇到的问题。

在策划制作完了几个职业后(主要是技能制作),大概去年年底公司内部进行了一次混战测试。30个角色在一个场景进行混战,测试结果从技术上来说非常不理想。首先是客户端和服务器都巨卡无比。服务器CPU一直是满负载状态。而客户端又频繁宕机。

我们关注的主要问题,是服务器CPU满负载问题。最开始,我通过日志初步定位为网络模块问题,因为逻辑线程表现不是那么差。然后考虑到技能过程中的特效、动作都是通过服务器消息驱动,并且本身特效和动作就比一般网游复杂,通过逐一屏蔽这一部分功能,最终确认确为网络模块导致。然后团队决定从两方面努力:重写网络模块,改善性能;改善技能实现机制,将表现类逻辑移到客户端。

至于网络模块,在后来才发现,虽然网络流量过高,但导致网络线程CPU满的原因竟然是网络模块自身的流量限制导致。而技能实现机制的改善,考虑到改动的成本,最终使用了一种RPC机制,让服务器脚本可以调用客户端脚本,并且支持传入复杂参数。然后策划通过一些关键数据在客户端计算出特效、动作之类。

此外,程序将更多的技能属性广播给客户端,一个客户端上保存了周围角色的技能数据,从而可以进行更多的客户端逻辑。这一块具体的修改当然还是策划在做(我们的脚本策划基本就是半个程序员)。后经测试,效果改善显著。

在策划制作了一个PVP竞技副本后,服务器在10V10测试过程中又表现出CPU负载较高的情况。这个问题到目前为止依然存在,只不过情况略微不同。

首先是触发器生命周期的问题。触发器自身包含最大触发次数、存留时间等需求,即当触发一定次数,或超过存留时间后,需要由程序自动删除;另一方面,触发器可以是定时器类型,而定时器也决定了触发器的生命周期。这一块代码写的非常糟糕,大概就是管理职责划分不清,导致出现对象自己删除自己,而删除后还在依赖自己做逻辑。

但这样的逻辑,最多就是导致野指针的出现。不过,这种混乱的代码,也更容易导致BUG。例如,在某种情况下触发器得不到自动删除了。但这个BUG并不是直接暴露的,直接暴露的,是CPU满了。我们的怪物AI在脚本中是通过定时器类触发器驱动的,每次AI帧完了后就注册一个触发器,以驱动下一次AI帧。由于这个BUG导致触发器没有被删除,从而导致服务器上触发器的数量急剧增加。但,这也就导致内存增长吧?

另一个巧合的原因在于,在当时的版本中,触发器是保存一个表里的,即定时器类触发器、属性类触发器、移动类触发器等都在一个表里。每次任意触发器事件发生时,例如属性改变,都会遍历这个表,检查其是否触发。

基于以上原因,悲剧就发生了。在这个怪物的AI脚本里,有行代码设置了怪物的属性。这会导致程序遍历该怪物的所有触发器。而这个怪物的触发器数量一直在增长。然后就出现了在很多游戏帧里出现过长的遍历操作,CPU就上去了。

找到这个问题了几乎花了我一天的时间。因为脚本代码不是我写的,触发器的最初版本也不是我写的。通过逐一排除可能的代码,最终竟然发现是一行毫不起眼的属性改变导致。这个问题的查找流程,反映了将大量逻辑放在脚本中的不便之处:查起问题来实在吃力不讨好。

修复了这个BUG后,我又对触发器管理做了简单的优化。将触发器列表改成二级表,将触发器按照类型保存成几个列表。每次触发事件时,找出对应类型的表遍历。

改进

除了修改触发器的维护数据结构外,程序还实现了一套性能统计机制,大概就是统计某个函数在一段时间内的执行时间情况。最初这套机制仅用于程序,但考虑到脚本代码在整个项目中的比例,又决定将其应用到脚本中。

这个统计需要在函数进入退出时做一些事情,C++中可以通过类对象的构建和析构完成,但lua中没有类似机制。最初,我使用了lua的调试库来捕获函数进入/退出事件,但后来又害怕这种方式本身存在效率消耗,就取消了。我们使用lua的方式,不仅仅是全局函数,还包括函数对象。而函数对象是没有名字标示的,这对于日志记录不是什么好事。为了解决这个问题,我只好对部分功能做了封装,并让策划显示填入函数对于的字符串标示。

除此之外,因为触发器是一种重要的敏感资源,我又加入了一个专门的触发器统计模块,分别统计触发器的类型数量、游戏对象拥有的触发器数量等。

END

到目前为止,导致服务器CPU负载过高,一般都是由BUG导致。这些BUG通常会造成一个过长的列表,然后有针对这个列表的遍历操作,从而导致CPU负载过高。更重要的,我们使用了这么多的脚本去开发这个游戏,如何找到一个更有效合理的监测方法,如何让程序框架更稳定,则是接下来更困难而又必须去面对的事情。

Comments