新产品上市，你准备好了吗：关于服务器性能、安全、稳定的全面监控
大宝(sodme)
公司在每一个新产品上市的时候，能向这个新产品派驻一两个富有经验的技术人员，以指导、协助他们完成产品上市前应该作的准备，但是，很可惜，直到我们成
长为一个相对成熟的运营产品之后，我们都没有得到过任何这方面的帮助，一直是自己摸索，痛苦而又漫长。
好吧，我希望同样的事，不要一而再、再而三的在更多同行身上重演了，所以，我想聊一些新产品上市所应该准备的事情，供大家参考，也留存我们自己的记
忆。
以我们自己的项目为例，我把产品上市前，服务器的性能监控内容分成这样几类：
1. 服务器内存使用、回收的统计、分析机制，更详细的，要统计到各类对象、各玩法、各系统的分别占用情况；
2. 网络流量（含收发包双向流量）的监控、统计、分析机制；
3. CPU使用率的统计、分析机制（结合逻辑架构，细分到各系统、各功能的具体占用）；
4. 数据库存取效率、存取流量，数据内容大小的统计、分析机制
以上是哪些内容应该作监控，至于如何作监控，无非是：尽可能详细、具体的统计出是哪些环节、哪个步骤、哪些系统占用了具体多少的系统资源。统计的工具，
可以采用一些已有的工具，也可以完全自己内建监控体系，我们采用的是后者：自建完整的服务器性能内部监控体系。
具体来说：
在内存使用上，我们尽可能的使用内存池技术来管理引擎层对象的内存使用，对脚本层的内存管理则采用基本内存池的buddy算法（脚本用的是lua），采
用内存池一是方便查证内存泄漏，二是可以给策划一个紧箍咒，方便双方商定各类资源的上限（比如怪的数量）；
在网络流量的统计上，我们分别统计单个玩家上下行各类型网络包单位时间内的包数量、包大小、某场景的玩家聚集数，发现问题后，通过两个方法优化流量：减
少收发包个数，减少单包大小；
在CPU使用率上，我们在帧轮询机制内和服务器运行的大循环内，对各主要系统进行CPU耗用时间监控，各大系统内又会有更细粒度的耗用时间记录，以此逐
层定位性能消耗点；
在数据库操作的效率上，会统计各操作的前后耗用时间，涉及到的数据内容，注意：这里主要是针对逻辑点而言的，而不纯粹是单个的SQL操作时间。
对于一款商业运营的网游产品而言，服务器至少应该保证连续稳定运行一周的时间，这是很多新产品需要跨过的第一道槛，什么时候你作到了连续运行一周不出问
题、稳定、高效，什么时候才算是在技术层面真正过了关，注意，这个一周，一定指的是完完整整的至少7天，差一天都不能成为一款合格的商业产品。
我们产品对以上四个方面内容的监控，并不是一次性全部建完了的，是慢慢摸索出来的。当人数压力越来越大时，总会发现系统一些新的不稳定和异常因素，比如
刚开始并没有这么严格的监控各类型包的数量、大小，但运行了一段时间后发现网络包突然多了，流量突然变大了，于是就会找原因，在找原因的过程中也就会不
断的把各种机制逐渐建立了起来。所幸的是，同行的新产品，在看到这个贴子后，可以不用经历我们的摸索期，而先行建立这样的机制了。:)
我们都知道，网游新产品上市时，普遍面对的一个问题都是新人涌入很多，玩家过于集中，服务器性能各方面的压力都将很大。这时，出于技术人员的本能反应，
我们都会强烈建议策划调整新手进入路线，减少玩家聚集度，以缓解服务器压力。嗯，这种想法严格来说很正当，但是，作为一个想有所作为的产品而言，我给的
建议仍然是，使劲吃奶的力气你都要尽可能的优化下去，中国玩家普遍都喜欢凑热闹，越是热闹的地方越是愿意去，越是热闹的产品越愿意玩，如果一个产品当新
玩家上线时，举目望去凄凄凉凉，空无一人，也会直接影响到玩家对一款产品是否够火的判断。从产品层面来说，我们应该欢迎热闹，而不是相反去拒绝热闹。技
术人员辛辛苦苦作几年，为的就是产品能成功，能赢利，为的也就是这一回，所以，尽管到时会背负很大的压力，也要坚持把性能尽可能的优化下去。
除了性能压力之外，我认为，面向玩家服务而言，我们最应该作的是，不管采用什么方法，都要尽可能完整的确保玩家数据安全。稍微慢一点，挤一点还不伤大
雅，但如果频繁发生数据丢失、回档之类的运营事故，对官方形象和玩家信心的打击将是致命的。但是，安全和稳定，是具体到每一天开发内容之中的，是需要根
植到每一个开发者思想深处的。如果是等到产品已经上市的时候再提安全，可能已经有点晚了。通常情况下，每一个新产品在开始测试时，几乎都会发生服务器异
常当机，相应的，就会发生玩家的数据丢失。
所以，对待玩家的数据安全，我们应该从以下几个方面着手去作：
1. 在研发期，就应该加强开发者的安全教育，安全编码不仅仅是一种习惯，更是一种工作态度，要把玩家数据安全放在第一位，如果有必要，有时宁愿牺牲掉
一些小性能来保证安全；
2. 要建立完整的针对于核心系统代码审核、发布的流程，重要代码由放心的人来作，次要代码能全面监控（自查，互查，流程及代码review）；
3. 所有重要的玩家数据，其获取、流通、消耗的全过程，都应该有尽可能完整的留下日志记录，以便于当发生数据丢失时能帮玩家找回数据，不要偷懒；
4. 要建立能迅速根据core dump文件来定位当机原因的机制，不管是符号表编译、反汇编分析、日志分析、玩法重现中的哪一种，只要能越快定位原
因就用哪一种，甚至可以多管齐下，多人并行定位。
新产品上市，是一场战役，很真实的战役，真实到，可以决定你这几年青春到底价值几何。
好吧，也希望能看到更多朋友聊一聊大家各自在新产品上市时所作的事，或者说一些趣事分享一下经验也挺好的。
femto Zheng
2009/12/1 大宝 <sodm...@gmail.com>:
xiliu tang
Lei Gu
大宝(sodme)
或者，这就是理想与现实之间的差距吧。
很多事，在当时，不是想不到，而是作不到。
而作不到，又是因为没时间作，没经验作，没能力作等等各种各样的原因，总之，不管是哪样的原因，最终导致了很多本来应该作的事而没有作。可惜的是，我们
总在每次的事后才想起有些事早应该作。但我们能把握得太少，不管你如何准备，总会存在一些需要在最短的时间之内需要最快速度解决的问题，呵呵，所以，闻
且闻之，作且作之，而结果到底如何，就只能到时再应对了。
On Dec 1, 4:38 pm, Lei Gu <jackf...@gmail.com> wrote:
> 非常感谢。有个疑问，你们上线前没有一些checklist吗？我想应该有若干个checklist，基本就是包含你列的这些项，通过了，才允许上线运营。按说 你们已经有几款成功的产品了，有些经验应该固化成流程来搞。
>
> 2009/12/1 大宝 <sodme....@gmail.com>
Hailong Shu
对于大规模的应用来说，常常会遇见很多稀奇古怪的问题。这种时候通过代码逻辑是难以分析出什么结论的。尤其是内存操作，对C或者C++不用内存池是难以做出一个7×24的应用了。不能OS的资源回收机制想的很健全。
2009/12/1 大宝 <sodm...@gmail.com>:
Lei Gu
Kasicass
个人的感受就是，游戏开发相对其他软件产品，需求变化还是太快了，对于一个团队应该如何形成自己的开发流程，只能靠团队内部的成员自己摸索并实践。
比如说要做 scrum，那晨会怎么开，聊些什么内容，这样的细节，也需要大家沟通、讨论后慢慢确定。否则生搬硬套其实无意义。
大宝(sodme) 写道:
--
Best regards！
Kasicass/汤泽江
<kasicass_at_gmail_dot_com>
<kasicass_at_163_dot_com>
jie li
jiang li
有几个问题。对服务器的各方面的监控一定会涉及到写日志的，对于一个多进程/线程的服务器，日志模块一般都是怎么设计的呢？是多个进程向同一个文件中写吗，这样会不会造成性能上的损失？我之前用过log4cxx库，但不知道是否还有更好的解决方案？
还有，如果对系统的方方面面都进行监控，那么对于整体的性能大概会有多大的影响呢，会不会得不偿失啊？
大宝(sodme)
1. 使用日志队列管理所有待写日志，主逻辑线程将待写日志丢入队列，写日志文件的线程从队列取数据写入实际文件；
2. 不同类型的日志写入不同文件，比如物品系统、交易系统、任务系统等是写到不同文件，这样不仅可以控制文件大小而且也方便运营时的日志查询；
3. 日志文件的总量控制上，采用循环日志与非循环日志两种方式。循环日志是指开若干个同类型的日志文件，以编号作区别，比如
trace01.log~trace10.log，每个日志文件记录的行数相对固定，写满一个后再写后一个，写到第10个时再回头写第1个。记录很频
繁、量很大、非永久性的日志，可写入循环日志，比如性能追踪的相关日志等。非循环日志，是指需要长久保存的日志，比如玩家的交易记录等。
4. 严格控制非循环日志的总量，适时调整循环日志与非循环日志的内容，写的频率的非循环日志要看看能不能调整到循环日志中。我们的日志记录比较详细，
其输出量相对来说现在不算小，一周一个服会输出文本类的日志将近7G，我们只会保存最近两个月的相关日志，更远时间的日志视备份系统的硬盘大小决定适时
删除。也就是说，对于客服方面的运营问题，我们只提供最近2个月以内的行为记录确认服务。
5. 日志方面的性能，对于我们服务器性能方面的整体影响来说，不算很大，但也要看日志的输出频率，还是要控制好日志的输出频率和输出量，影响大小不是
首要的，首要的是要建立一套可伸缩的日志输出体系，可以让你适时调整相关的性能影响比例。
On Dec 2, 11:52 pm, jiang li <li.jian...@gmail.com> wrote:
> 好文章，拜读了。
>
> 有几个问题。对服务器的各方面的监控一定会涉及到写日志的，对于一个多进程/线程的服务器，日志模块一般都是怎么设计的呢？是多个进程向同一个文件中写吗，这样 会不会造成性能上的损失？我之前用过log4cxx库，但不知道是否还有更好的解决方案？
> 还有，如果对系统的方方面面都进行监控，那么对于整体的性能大概会有多大的影响呢，会不会得不偿失啊？
>
> 2009/12/1 大宝 <sodme....@gmail.com>
lin_style
大宝(sodme)
2. 对于错误的日志跟踪，与异步不异步无关。重要的是，尽可能全的找到那些关键的数据，并将其记录下来。放到日志队列时，那些可以追踪的关键数据已被
记录，至于何时写到真正的日志文件并不重要。
On Dec 3, 9:15 am, lin_style <0xtiger2...@gmail.com> wrote:
> 您好。LZ是直接写文本吗？还是写数据库。还有个，日志为什么这里是用异步的？为了效率吗？但是在一些错误的日志跟踪上，用异步可能会影响你的判断
>
> 2009/12/3 大宝 <sodme....@gmail.com>
zhihua che
大宝(sodme)
On Dec 3, 9:26 am, zhihua che <zhihua....@gmail.com> wrote:
> 我觉得LZ说的应该是主线程将日志丢入日志线程，但日志线程是以先入先出的方式写，这样并不影响日志发生的时间顺序，这样对跟踪没什么影响吧？
>
> 2009/12/3 lin_style <0xtiger2...@gmail.com>
>
>
>
> > 您好。LZ是直接写文本吗？还是写数据库。还有个，日志为什么这里是用异步的？为了效率吗？但是在一些错误的日志跟踪上，用异步可能会影响你的判断
>
> > 2009/12/3 大宝 <sodme....@gmail.com>
> >> > > 因就用哪一种，甚至可以多管齐下，多人并行定位。...
>
> read more >>
lin_style
再请教个问题
“1. 服务器内存使用、回收的统计、分析机制，更详细的，
1。这么健全的模块监视，用了多少时间开发呢？
2。服务器宕的时候，LZ是怎么快速定位到错误的？除了日志那边记录堆栈的信息，日志的一些关键数据，还有其他方法可以分享吗？
谢谢
大宝(sodme)
果集中时间添加，我想基本的机制大概最多一两个月就可以完全搭完，更重要的是后期的持续跟进和调整。其实，关键的是，有了这套基本的机制之后，你的心里
就不会发虚了。
2. 定位服务器当机的方法，我们常用的是：使用gdb对core dump文件的反汇编、堆栈调用、寄存器及变量值的分析，当机前后的日志分析。前面
这些是精准分析，剩下的方法就是一些推测类的分析了，比如尝试故障现场的重现，查看最近的代码更新内容，了解来自于玩家的一些异常报告之类。还有最后一
招，不是所有人都能用得上，就是：直觉。它来自于长期产品运营的经验和直观感受，有时没啥特别的原因，就是偶然一个念头想到了可能是某部分的原因，于是
就会去求证，我想很多开发者也都经历过这样的情况。呵呵。
On Dec 3, 9:31 am, lin_style <0xtiger2...@gmail.com> wrote:
> 谢谢LZ回答。是我想多了，呵呵。
>
> 再请教个问题
> "1. 服务器内存使用、回收的统计、分析机制，更详细的，
> 要统计到各类对象、各玩法、各系统的分别占用情况
> "
> 1。这么健全的模块监视，用了多少时间开发呢？
> 2。服务器宕的时候，LZ是怎么快速定位到错误的？除了日志那边记录堆栈的信息，日志的一些关键数据，还有其他方法可以分享吗？
>
> 谢谢
>
> 2009/12/3 大宝 <sodme....@gmail.com>
> > > >> 在研发期，就应该加强开发者的安全教育，安全编码不仅仅是一种习惯，更是一种工作态度，要把玩家数据安全放在第一位，如果有必要，有时宁愿牺牲掉...
>
> read more >>
zhihua che
你们现在服务器的是彻底从底层（我说的socket方面）自己建立网络IO模式，还是会使用一些框架，比如ACE，或者轻量的libevent之类。你们最常使用的IO模式是怎么样的？
我们最喜欢用的是用异步socket，轮询响应玩家请求。不过这样有一个很明显的问题，我们经常在一个场景中有20个玩家左右进行频繁操作的话（比如PK)，会明显出现卡的现象。
希望得到诸如IOCP模式等方面的指点。
阿杜
大宝(sodme)
zhihua che
大宝(sodme)
还是选择这些已经成熟的网络通信模型。
网络模型的选型，还是要根据实际项目的网络架构、用户规模、逻辑数据的处理特点等来定，不是简单地说可以用这个，不可以用那个，这玩意没有什么绝对的概
念。事实上，在我们的产品中，网络层关于通信的性能是很小的一块，完全没有构成对整体性能的关键性影响。
网络上已有的框架可以参照，但要考虑到驾奴能力。基本上，我们产品对于开发模型的选择思路都是选择自建，这是根据我们的实际情况作出来的：
1. 我需要短时间内对这些内容作到完全可控，我认为再好的第三方库，也没有自己写的知根知底；
2. 方便以后对其进行灵活改造。
当然，这也并不就是所有新团队和新人都要选择的道路，看项目紧迫度、看团队成员的已有技术水平、看项目未来的用户规模等等。
On Dec 3, 9:58 am, zhihua che <zhihua....@gmail.com> wrote:
> 我想在网络IO等性能方面有些进步，可以做点什么了？最近我在研究libevent，memchaced等库，不过一直没机会在实际项目中使用，希望能有帮助和 进步。
>
> 2009/12/3 阿杜 <leabersoc...@gmail.com>
>
>
>
> > 很多东西是来自于执著和坚持的产物，这里面经验是一方面，态度是一方面。
>
> > 2009/12/3 大宝 <sodme....@gmail.com>
> >> 我们都知道，网游新产品上市时，普遍面对的一个问题都是新人涌入很多，玩家过于集中，服务器性能各方面的压力都将很大。这时，出于技术人员的本能反应，...
>
> read more >>
zhihua che
张高崇
sislcb
不过网游开发真的很庞大，逻辑也很多需要注意的。不仅仅是基础架构方面。
不断学习中。。
poe....@gmail.com
我们现在困恼没有好的办法对整个集群进行端口级、进程级的流量异动监控。
大宝(sodme)
JoeCen
如果要做估计要使用sniff之类的方法才能实现，用这些的话对系统的性能也会有耗损的，感觉意义也不大。进程级的做cpu和内存的监控就好。
大宝(sodme)
cacti的总体监控，配上产品内置的细节监控，我认为总体上已经完全可以满足运营需求。
cacti提供了相对完善的外部扩展方法，如果想针对进程监控流量，只要形成流量日志即可，cacti可以将此日志再以图形化的方式表现出来。
On Dec 3, 3:03 pm, JoeCen <joe...@gmail.com> wrote:
> cacti是没有做端口或者进程级别的流量监控的。
> 如果要做估计要使用sniff之类的方法才能实现，用这些的话对系统的性能也会有耗损的，感觉意义也不大。进程级的做cpu和内存的监控就好。
>
> 2009/12/3 <sodme....@gmail.com>
Xu Yong
非常感谢。有个疑问，你们上线前没有一些checklist吗？我想应该有若干个checklist，基本就是包含你列的这些项，通过了，才允许上线运营。按说你们已经有几款成功的产品了，有些经验应该固化成流程来搞。
2009/12/1 大宝 <sodm...@gmail.com>
我们都会强烈建议策划调整新手进入路线，减少玩家聚集度，以缓解服务器压力。嗯，这种想法严格来说很正当，但是，作为一个想有所作为的产品而言，我给的
建议仍然是，使劲吃奶的力气你都要尽可能的优化下去，中国玩家普遍都喜欢凑热闹，越是热闹的地方越是愿意去，越是热闹的产品越愿意玩，如果一个产品当新
玩家上线时，举目望去凄凄凉凉，空无一人，也会直接影响到玩家对一款产品是否够火的判断。从产品层面来说，我们应该欢迎热闹，而不是相反去拒绝热闹。技
术人员辛辛苦苦作几年，为的就是产品能成功，能赢利，为的也就是这一回，所以，尽管到时会背负很大的压力，也要坚持把性能尽可能的优化下去。
除了性能压力之外，我认为，面向玩家服务而言，我们最应该作的是，不管采用什么方法，都要尽可能完整的确保玩家数据安全。稍微慢一点，挤一点还不伤大
雅，但如果频繁发生数据丢失、回档之类的运营事故，对官方形象和玩家信心的打击将是致命的。但是，安全和稳定，是具体到每一天开发内容之中的，是需要根
植到每一个开发者思想深处的。如果是等到产品已经上市的时候再提安全，可能已经有点晚了。通常情况下，每一个新产品在开始测试时，几乎都会发生服务器异
常当机，相应的，就会发生玩家的数据丢失。
所以，对待玩家的数据安全，我们应该从以下几个方面着手去作：
1. 在研发期，就应该加强开发者的安全教育，安全编码不仅仅是一种习惯，更是一种工作态度，要把玩家数据安全放在第一位，如果有必要，有时宁愿牺牲掉
一些小性能来保证安全；
2. 要建立完整的针对于核心系统代码审核、发布的流程，重要代码由放心的人来作，次要代码能全面监控（自查，互查，流程及代码review）；
3. 所有重要的玩家数据，其获取、流通、消耗的全过程，都应该有尽可能完整的留下日志记录，以便于当发生数据丢失时能帮玩家找回数据，不要偷懒；
4. 要建立能迅速根据core dump文件来定位当机原因的机制，不管是符号表编译、反汇编分析、日志分析、玩法重现中的哪一种，只要能越快定位原
因就用哪一种，甚至可以多管齐下，多人并行定位。
Xu Yong
poe....@gmail.com
题。是基础架构的平台产品。我试试看各位提供的工具。
poe....@gmail.com
1、sflow受限于某些设备，在我们的环境中，无法全覆盖；
2、netflow能满足需求，大型集群网络中，条目太多，硬件条件不允许，并且只能在3层以上设备中才可使用，如果能在2层设备使用，就不存在问
题；
3、cacti已经在我们的网络流量监控上用了，但是无法满足我们对TCP端口、进程这种颗粒度的需求。
莫非只有DIY了？
On 12月4日, 上午1时17分, Xu Yong <tjuxuy...@gmail.com> wrote:
> 推荐一下sflow和netflow的东东。
>
> 2009/12/3 poe.y...@gmail.com <poe.y...@gmail.com>
非狐外传
感觉你们肯定考虑过，但后来排除了，是什么原因呢？
> > > 好吧，也希望能看到更多朋友聊一聊大家各自在新产品上市时所作的事，或者说一些趣事分享一下经验也挺好的。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
Xu Yong
Xu Yong
Lei Gu
Xu Yong
gogoplayer
Suman Deng
冬虫草
大宝(sodme)
On Dec 7, 2:53 pm, Suman Deng <sumand...@gmail.com> wrote:
> 多谢分享， 我能转到我的空间里吗？
>
> 2009/12/4 gogoplayer <gogopla...@163.com>