Archives

All posts for the month November, 2014

项目中的跨(区)服国战功能一直不稳定,之前一直没有上线。这段时间在排查这个问题。

其中有一个严重的隐患昨天才发现。抽象一下是这样的:A, B, C 三个线程,在处理网络消息时对一些共享变量根本不作同步。

这个问题在时间一大,压力一大的时候就会引起各种不稳定问题。

早上躺在床上想了想,A,B,C线程已有的一些锁已经把一些设计搞的很复杂了,如果加上线程间嵌套调用,用锁的话,只会把问题搞的很复杂。

根据实际的情况,目前的想法是:

(1 )把A,B之间的处理都统一到B中处理,A与B做到完全隔离;

(2 )B和C很难完全隔离,用消息队列进行通信。虽然也会用到锁,但是只会锁住队列。

嗯,明天搞起。

项目是个老项目,都有10来年的历史了,我接手的时候已经是全区服大约每天共有4次左右的宕机,直接后果是宕机服务所在地图的玩家会回档几分钟。

据同事和运维的同学反映,自从上半年上了一个资料片以后,宕机的频率就翻了一倍多。

从宕机的core信息来看的话,基本上每次都宕在某些固定函数里,这样的函数一共大概有7,8处。把这些函数相关的一些隐患点重新整理了一遍以后,仍然没有什么成效。

从代码更改的角度入手或许是个好办法,但是这一版的代码改动很多,而且还加上了一个代码库迁移,我们的库又有多个分支:开发的分支,发布的分支。于是写这个资料片的同学们又重新捋了一边,把一些觉得隐患较大的点也做了屏蔽,但是依然没有什么成效。

反反复复的再把这些core分析了一遍,直觉告诉我,很大的问题应该还是内存出错了。

于是用一些工具和设计上的方案来验证和分析,如Valgrind, ElectricFence, tcmalloc,但由于我们使用的Linux系统老旧,所以跑起来也不是很顺畅。

于是,重新一行行的去review相关的代码,以及对新旧库的代码做一些比较,重点在内存的使用上,如memcpy,数组越界等。确实找出了一些很隐蔽,但很严重的隐患。

原本以为这么一捋,大概能解决70%左右的宕机,结果是一条宕机也没有,很开心。

宕机的问题,在设计和实现的时候就应该避免。但是有时候,对吧,你懂的。无论如何,出现这些问题,也应该立即解决才是,拖的越久,解决起来越来越不容易,尤其是那些缺乏基础设施的程序。