关于游戏服务器性能问题的几点思考(1)

对于一个服务器程序来说,性能指标无非有CPU负载、内存消耗、I/O回写压力、网络包的流量等,目前测试组的测试都是在公司内网来做的,所以,网络包的流量不是瓶颈,但从测试的结果来说,这块恰好是我们的短板。我在想,有几个地方可能是我们可以优化的地方:

(1)字节序的转换问题:游戏服务器的内部架构与部署一般有二层或三层,即一个游戏大区包含若干台游戏逻辑服务器。在实际运营时,这些物理机器一般都是x86的,这样网络消息包在服务器内部进行传递时,可以省掉字节序转换这个步骤了,而经测试证明,这步往往消耗较大的CPU;

(2)消息包的加解包与内存拷贝问题:服务器程序在发送消息包时,尽量减少不必要的内存拷贝,能通引用填充的尽量应用同一内存空间引用来完成;

(3)视野广播消息的定制问题:广播消息包是比较消耗下行流量的,所以可以根据实际业务需求来定制广播包的数量,而不要统一全部广播玩家视野里所有对象,因为这样会造成下发无谓的消息包,比如:玩家视野里所有的怪物是不需要发送任何消息包的,另外,视野中的某些特定的玩家也不需要收到广播包;

先总结这几点吧!

感受大师风范——侯捷谈程序人生

去年有幸在公司一睹侯大师风采,有同事把演讲精要记录下来,这里摘录一份,以常自励之!

杂谈——将相本无种,男儿当自强。忠于内心,忠于兴趣,把吃苦当作兴趣。

兴趣/热情——众里寻她千百度。
执着——不信青春换不回,不容青史尽成灰(后二句:低回海上酬功宴,万里江山酒一杯。出自于右任,国民党大佬,玉山顶曾为他立碑而高3尺)。
毅力——人生是一场马拉松,不是百米匆匆(表浮躁)。
专业——为学当如金字塔,要能深来要能广(语出胡适,延伸意偶不是很聪明的人,是个比较笨的人)弱水三千,取一瓢饮(求深)。勿在浮砂筑高台(基础扎实)
用功——台上一分钟,台下十年功。
态度——宁拙勿巧,宁下勿高,宁远勿近,宁繁勿略(朱熹)。超越先天局限,是大勇者。
问道——山不走来,我向山走去。大扣大鸣,小扣小鸣,不扣不鸣(多请教)。
勤勉——读过千赋亦能赋,观过千剑亦能剑。
不怕与人异——The Road Not Taken.
品格——期许自己是“贵族”(扶弱济贫)。

The Road Not Taken
By Robert Frost
Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;
Then took the other, as just as fair,
And having perhaps the better claim,
Because it was grassy and wanted wear;
Though as for that the passing there
Had worn them really about the same,
And both that morning equally lay
In leaves no step had trodden black.
Oh, I kept the first for another day!
Yet knowing how way leads on to way,
I doubted if I should ever come back.
I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I-
I took the one less traveled by,
And that has made all the difference.

Linux性能评测工具之nmon

1. nmon概述

1.1. 概述

nmon是收集AIX或Linux主机的性能数据并分析的工具,使用简单易用。主要有两个,一个是nmon采集数据的工具,一般名称为nmon_**,例如nmon_aix5.3,另一个是分析结果的工具,它是一个excel的文件,名称为:nmon analyser v33A.xls。

nmon在一个屏幕上显示所有重要的性能优化信息,并动态地对其进行更新。还可以将相同的数据捕获到一个文本文件,便于以后对报告进行分析和绘制图形。

nmon_analyser 工具以 NMON 性能工具生成的文件作为输入,然后将它们转换为 Microsoft Excel 电子表格,并自动地生成相应的图形。

nmon 工具可以为 AIX 和 Linux 性能专家提供监视和分析性能数据的功能,其中包括:

l CPU 使用率

l 内存使用情况

l 内核统计信息和运行队列信息

l 磁盘 I/O 速度、传输和读/写比率

l 文件系统中的可用空间

l 磁盘适配器

l 网络 I/O 速度、传输和读/写比率

l 页面空间和页面速度

l 消耗资源最多的进程

l 计算机详细信息和资源

IBM 没有提供对该工具的正式支持,并且您在使用它的时候必须自己承担相应的风险,但是您可以从中获得大量有价值的性能统计信息。其中,nmon for linux版本已经在2009年7月27日开放源码。

1.2. 适用范围

本文档为使用nmon作为性能测试中监控linux服务器的应用,提供使用规范和帮助。

1.3. 词汇表

词汇 解释
Nmon 性能数据收集分析工具
Nmon analyser 性能数据分析工具,excel文件
nmon_x86_sles10 Nmon在x86_sles10下二进制执行文件

 

1.4. 参考资料

Nmon在IBM的官方网站

http://www.ibm.com/developerworks/wikis/display/WikiPtype/nmon

nmon for linux的官方网站

http://nmon.sourceforge.net/pmwiki.php

文章一:《nmon 性能:分析 AIX 和 Linux 性能的免费工具》

http://www.ibm.com/developerworks/cn/aix/library/analyze_aix/

文章二:《nmon analyser——生成 AIX 性能报告的免费工具》

http://www.ibm.com/developerworks/cn/aix/library/nmon_analyser/index.html

1.5. 获取该工具

下载nmon工具的可执行文件nmon_x86_sles10。

http://nmon.sourceforge.net/pmwiki.php?n=Site.Download

也可以下载源码自己编译特定的版本。(推荐这个)

http://nmon.sourceforge.net/pmwiki.php?n=Site.CompilingNmon

下载nmon Analyser V3.3

http://www.ibm.com/developerworks/wikis/display/Wikiptype/nmonanalyser

 

下载nmon Consolidator

http://www.ibm.com/developerworks/wikis/display/WikiPtype/nmonconsolidator

ibm的其他性能测试工具

http://www.ibm.com/developerworks/wikis/display/WikiPtype/Performance+Other+Tools

2. nmon

2.1. 安装

该工具是一个独立的二进制文件(不同的 AIX 或 Linux 版本中该文件也有所不同)。安装过程非常简单:

1. 将 nmon_x86_sles10文件复制到计算机,rz—>在弹出框选择nmon_x86_sles10。

2. 修改nmon_x86_sles10的文件权限,chmod 777 ./nmon_x86_sles10

3. 要启动 nmon 工具,输入 ./ nmon_x86_sles10。

2.2. 运行

Nmon可以交互式运行

l 启动该工具 ./ nmon_x86_sles10

l 使用单键命令来查看您所需要的数据。例如,要获取 CPU、内存和磁盘统计信息,启动 nmon 并输入: c m d

l 获取相关的帮助信息,按 h 键。

 

使用下面这些键来切换显示状态:

c = CPU l = CPU Long-term  – = Faster screen updates

m = Memory j = Filesystems + = Slower screen updates

d = Disks n = Network V = Virtual Memory

r = Resource N = NFS v = Verbose hints

k = kernel t = Top-processes . = only busy disks/procs

h = more options q = Quit

2.3. 捕获数据到文件

捕获数据到文件,只要运行带 -f 标志的 nmon 命令。执行nmon –f ***后,nmon 将转为后台运行。要查看该进程是否仍在运行,可以输入: ps -ef | grep nmon。

 

示例:

每1秒捕获数据快照,捕获20次

nmon –f -s 1 -c 20

每30秒捕获数据快照,捕获120次,包含进程信息

nmon –ft -s 30 -c 120

命令将在当前目录中创建输出文件,其名称为: <hostname>_date_time.nmon。该文件采用逗号分隔值 (CSV) 的格式,并且可以将其直接导入到电子表格中,可进行分析和绘制图形

Linux性能评测工具之gprof

这些天自己试着对项目作一些压力测试和性能优化,也对用过的测试工具作一些总结,并把相关的资料作一个汇总,以便以后信手拈来!

1 简介

改进应用程序的性能是一项非常耗时耗力的工作,但是究竟程序中是哪些函数消耗掉了大部分执行时间,这通常都不是非常明显的。GNU 编译器工具包所提供了一种剖析工具 GNU profiler(gprof)。gprof 可以为 Linux平台上的程序精确分析性能瓶颈。gprof精确地给出函数被调用的时间和次数,给出函数调用关系。

gprof 用户手册网站 http://sourceware.org/binutils/docs-2.17/gprof/index.html

2 功能

Gprof 是GNU gnu binutils工具之一,默认情况下linux系统当中都带有这个工具。

1. 可以显示“flat profile”,包括每个函数的调用次数,每个函数消耗的处理器时间,

2. 可以显示“Call graph”,包括函数的调用关系,每个函数调用花费了多少时间。

3. 可以显示“注释的源代码”--是程序源代码的一个复本,标记有程序中每行代码的执行次数。

3 原理

通过在编译和链接程序的时候(使用 -pg 编译和链接选项),gcc 在你应用程序的每个函数中都加入了一个名为mcount ( or  “_mcount”  , or  “__mcount” , 依赖于编译器或操作系统)的函数,也就是说你的应用程序里的每一个函数都会调用mcount, 而mcount 会在内存中保存一张函数调用图,并通过函数调用堆栈的形式查找子函数和父函数的地址。这张调用图也保存了所有与函数相关的调用时间,调用次数等等的所有信息。

4 使用流程

1. 在编译和链接时 加上-pg选项。一般我们可以加在 makefile 中。

2. 执行编译的二进制程序。执行参数和方式同以前。

3. 在程序运行目录下 生成 gmon.out 文件。如果原来有gmon.out 文件,将会被重写。

4. 结束进程。这时 gmon.out 会再次被刷新。

5. 用 gprof 工具分析 gmon.out 文件。

5 参数说明

l -b 不再输出统计图表中每个字段的详细描述。

l -p 只输出函数的调用图(Call graph的那部分信息)。

l -q 只输出函数的时间消耗列表。

l -e Name 不再输出函数Name 及其子函数的调用图(除非它们有未被限制的其它父函数)。可以给定多个 -e 标志。一个 -e 标志只能指定一个函数。

l -E Name 不再输出函数Name 及其子函数的调用图,此标志类似于 -e 标志,但它在总时间和百分比时间的计算中排除了由函数Name 及其子函数所用的时间。

l -f Name 输出函数Name 及其子函数的调用图。可以指定多个 -f 标志。一个 -f 标志只能指定一个函数。

l -F Name 输出函数Name 及其子函数的调用图,它类似于 -f 标志,但它在总时间和百分比时间计算中仅使用所打印的例程的时间。可以指定多个 -F 标志。一个 -F 标志只能指定一个函数。-F 标志覆盖 -E 标志。

l -z 显示使用次数为零的例程(按照调用计数和累积时间计算)。

一般用法: gprof –b 二进制程序 gmon.out >report.txt

6 报告说明

Gprof 产生的信息解释:

  %time Cumulative

seconds

Self

Seconds

Calls Self

TS/call

Total

TS/call

name
该函数消耗时间占程序所有时间百分比 程序的累积执行时间

(只是包括gprof能够监控到的函数)

该函数本身执行时间

(所有被调用次数的合共时间)

函数被调用次数 函数平均执行时间

(不包括被调用时间)

(函数的单次执行时间)

函数平均执行时间

(包括被调用时间)

 

(函数的单次执行时间)

函数名

Call Graph 的字段含义:

Index %time Self Children Called Name
索引值 函数消耗时间占所有时间百分比 函数本身执行时间 执行子函数所用时间 被调用次数 函数名

注意:

程序的累积执行时间只是包括gprof能够监控到的函数。工作在内核态的函数和没有加-pg编译的第三方库函数是无法被gprof能够监控到的,(如sleep()等)

Gprof 的具体参数可以 通过 man gprof 查询。

7 共享库的支持

对于代码剖析的支持是由编译器增加的,因此如果希望从共享库中获得剖析信息,就需要使用 -pg 来编译这些库。提供已经启用代码剖析支持而编译的 C 库版本(libc_p.a)。

如果需要分析系统函数(如libc库),可以用 –lc_p替换-lc。这样程序会链接libc_p.so或libc_p.a。这非常重要,因为只有这样才能监控到底层的c库函数的执行时间,(例如memcpy(),memset(),sprintf()等)。

gcc example1.c –pg -lc_p -o example1

注意要用ldd ./example | grep libc来查看程序链接的是libc.so还是libc_p.so

8 用户时间与内核时间

gprof 的最大缺陷:它只能分析应用程序在运行过程中所消耗掉的用户时间,无法得到程序内核空间的运行时间。通常来说,应用程序在运行时既要花费一些时间来运行用户代码,也要花费一些时间来运行 “系统代码”,例如内核系统调用sleep()。

有一个方法可以查看应用程序的运行时间组成,在 time 命令下面执行程序。这个命令会显示一个应用程序的实际运行时间、用户空间运行时间、内核空间运行时间。

如 time ./program

输出:

real    2m30.295s

user    0m0.000s

sys     0m0.004s

9 注意事项

1. g++在编译和链接两个过程,都要使用-pg选项。

2. 只能使用静态连接libc库,否则在初始化*.so之前就调用profile代码会引起“segmentation fault”,解决办法是编译时加上-static-libgcc或-static。

3. 如果不用g++而使用ld直接链接程序,要加上链接文件/lib/gcrt0.o,如ld -o myprog /lib/gcrt0.o myprog.o utils.o -lc_p。也可能是gcrt1.o

4. 要监控到第三方库函数的执行时间,第三方库也必须是添加 –pg 选项编译的。

5. gprof只能分析应用程序所消耗掉的用户时间.

6. 程序不能以demon方式运行。否则采集不到时间。(可采集到调用次数)

7. 首先使用 time 来运行程序从而判断 gprof 是否能产生有用信息是个好方法。

8. 如果 gprof 不适合您的剖析需要,那么还有其他一些工具可以克服 gprof 部分缺陷,包括 OProfile 和 Sysprof。

9. gprof对于代码大部分是用户空间的CPU密集型的程序用处明显。对于大部分时间运行在内核空间或者由于外部因素(例如操作系统的 I/O 子系统过载)而运行得非常慢的程序难以进行优化。

10. gprof 不支持多线程应用,多线程下只能采集主线程性能数据。原因是gprof采用ITIMER_PROF信号,在多线程内只有主线程才能响应该信号。但是有一个简单的方法可以解决这一问题:http://sam.zoy.org/writings/programming/gprof.html

11. gprof只能在程序正常结束退出之后才能生成报告(gmon.out)。

a) 原因: gprof通过在atexit()里注册了一个函数来产生结果信息,任何非正常退出都不会执行atexit()的动作,所以不会产生gmon.out文件。

b) 程序可从main函数中正常退出,或者通过系统调用exit()函数退出。

10 多线程应用

gprof 不支持多线程应用,多线程下只能采集主线程性能数据。原因是gprof采用ITIMER_PROF信号,在多线程内只有主线程才能响应该信号。

采用什么方法才能够分析所有线程呢?关键是能够让各个线程都响应ITIMER_PROF信号。可以通过桩子函数来实现,重写pthread_create函数。

 

//////////////////// gprof-helper.c////////////////////////////

#define _GNU_SOURCE

#include <sys/time.h>

#include <stdio.h>

#include <stdlib.h>

#include <dlfcn.h>

#include <pthread.h>

static void * wrapper_routine(void *);

/* Original pthread function */

static int (*pthread_create_orig)(pthread_t *__restrict,

__const pthread_attr_t *__restrict,

void *(*)(void *),

void *__restrict) = NULL;

 

/* Library initialization function */

void wooinit(void) __attribute__((constructor));

 

void wooinit(void)

{

pthread_create_orig = dlsym(RTLD_NEXT, “pthread_create”);

fprintf(stderr, “pthreads: using profiling hooks for gprof/n”);

if(pthread_create_orig == NULL)

{

char *error = dlerror();

if(error == NULL)

{

error = “pthread_create is NULL”;

}

fprintf(stderr, “%s/n”, error);

exit(EXIT_FAILURE);

}

}

/* Our data structure passed to the wrapper */

typedef struct wrapper_s

{

void * (*start_routine)(void *);

void * arg;

pthread_mutex_t lock;

pthread_cond_t  wait;

struct itimerval itimer;

} wrapper_t;

/* The wrapper function in charge for setting the itimer value */

static void * wrapper_routine(void * data)

{

/* Put user data in thread-local variables */

void * (*start_routine)(void *) = ((wrapper_t*)data)->;start_routine;

void * arg = ((wrapper_t*)data)->;arg;

 

/* Set the profile timer value */

setitimer(ITIMER_PROF, &((wrapper_t*)data)->;itimer, NULL);

/* Tell the calling thread that we don’t need its data anymore */

pthread_mutex_lock(&((wrapper_t*)data)->;lock);

pthread_cond_signal(&((wrapper_t*)data)->;wait);

pthread_mutex_unlock(&((wrapper_t*)data)->;lock);

/* Call the real function */

return start_routine(arg);

}

/* Our wrapper function for the real pthread_create() */

int pthread_create(pthread_t *__restrict thread,

__const pthread_attr_t *__restrict attr,

void * (*start_routine)(void *),

void *__restrict arg)

{

wrapper_t wrapper_data;

int i_return;

/* Initialize the wrapper structure */

wrapper_data.start_routine = start_routine;

wrapper_data.arg = arg;

getitimer(ITIMER_PROF, &wrapper_data.itimer);

pthread_cond_init(&wrapper_data.wait, NULL);

pthread_mutex_init(&wrapper_data.lock, NULL);

pthread_mutex_lock(&wrapper_data.lock);

/* The real pthread_create call */

i_return = pthread_create_orig(thread,

attr,

&wrapper_routine,

&wrapper_data);

/* If the thread was successfully spawned, wait for the data

* to be released */

if(i_return == 0)

{

pthread_cond_wait(&wrapper_data.wait, &wrapper_data.lock);

}

pthread_mutex_unlock(&wrapper_data.lock);

pthread_mutex_destroy(&wrapper_data.lock);

pthread_cond_destroy(&wrapper_data.wait);

return i_return;

}

///////////////////

然后编译成动态库 gcc -shared -fPIC gprof-helper.c -o gprof-helper.so -lpthread -ldl

使用例子:

/////////////////////a.c/////////////////////////////

#include <stdio.h>;

#include <stdlib.h>;

#include <unistd.h>;

#include <pthread.h>;

#include <string.h>;

void fun1();

void fun2();

void* fun(void * argv);

int main()

{

int i =0;

int id;

pthread_t    thread[100];

for(i =0 ;i< 100; i++)

{

id = pthread_create(&thread[i], NULL, fun, NULL);

printf(“thread =%d/n”,i);

}

printf(“dsfsd/n”);

return 0;

}

void*  fun(void * argv)

{

fun1();

fun2();

return NULL;

}

void fun1()

{

int i = 0;

while(i<100)

{

i++;

printf(“fun1/n”);

}

}

void fun2()

{

int i = 0;

int b;

while(i<50)

{

i++;

printf(“fun2/n”);

//b+=i;

}

}

///////////////

gcc -pg a.c  gprof-helper.so

运行程序:

./a.out

分析gmon.out:

gprof -b a.out gmon.out

MMORPG游戏在技能战斗中的位置同步问题

这里列举在技能战斗系统开发中,碰到的两个与位置同步相关的问题

(一)

在MMORPG游戏中,对于那些同时拥有近攻和远程系等多种职业的游戏,策划一般都会对近攻类的职业,加上冲锋类的技能,以便平衡远程类职业在攻击距离上的优势。在client看到的效果,是玩家边播放冲锋动作,然后快速接近目标,并对目标一个伤害,而对server而言,该技能与其它技能在处理的不同之处在于,施法玩家在施法的同时,也作一个位置的变更。一般server的处理流程是,先检查冲锋直线路径是否合法(有无阻挡)和其它施法条件,若通过,则告诉client可以施法,并同时设置当前玩家坐标为冲锋后的坐标(该坐标由client带上来)。

由于server移动系统在对client发过来的移动数据作检验时,需要检查本次移动的起步点,是否为上次移动的结束点,即作线段端点合法检查,而冲锋到达的目标点并未在上次移动的路径栈信息中,所以,server技能系统在设置冲锋位置时,需要先清除原路径栈信息(如调用MoveStop接口),以便确认本次冲锋为一次全新的移动。

(二)

两个玩家同时使用冲锋技能时(目前client在做技能时,采用先表现的方式),出现一个玩家(冲锋目标client)停在冲锋途中的现象,原因为server广播技能施法时,没有带目标主动位移的信息(client在处理冲锋位置时,对于使用冲锋技能的client,因为它知道冲锋到达的位置,所以它的处理没有问题,而另一个冲锋目标client,由于它不知道对方要冲到哪里,则client处理时就是选择冲锋路径上的一点,这样就会看到停在冲锋途中了)所致。解决办法是,要么在协议中下发目标位移信息,要么在策划规则上,只允许同一时刻一个玩家冲锋,如:冲锋加晕眩debug等;