• 游戏思考26:游戏服务器压力测试文档(最近在忙这个,这个会更新频繁,12/03未完待续)


    一、压力测试关注点

    ①流量
    ②内存
    ③一些主要的功能才做压力测试,比如同时注册最大在线战斗地图移动数据存取等。
    ④2个压力宏观数据保持不变:
    a. 各接口的压力比例不变, 首先从同类型游戏或者本游戏内测阶段,日志插桩,收集各个接口的调用比例;然后,将接口比例转化为场景比例,如同时会有个2%完结登陆、15%玩家战斗、20%玩家拉取好友列表、10%玩家赌博(一个手游场景例子)。
    b.玩家平均每分钟操作频率不变。同样在内测阶段收集玩家平均操作频率。
    因此,压力测试目标就转变成了如何模拟符合ab数据的压力。

    ⑤服务器配置信息

    • 静态信息
    1)CPU核数
    2)内存
    3)操作系统
    4)带宽
    5)网卡
    6)硬盘
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 动态信息
      1)CPU利用率监控
      2)内存监控
      3)内网带宽监控(内网出带宽、内网入带宽、内网出包量、内网入包量、TCP连接数)

    在这里插入图片描述

    ⑥其他指标
    ●吞吐量:固定时间间隔内的处理完毕事务个数。通常是1秒内处理完毕的请求个数,单位:事务/秒(tps)。

    平均吞吐量:一段时间内吞吐量的平均值。无法体现吞吐量的瞬间变化。

    峰值吞吐量:一段时间内吞吐量的最大值。是用来评估系统容量的重要指标之一。

    最低吞吐量:一段时间内吞吐量的最小值。如果最小值接近0,说明系统有“卡”的现象。

    70%的吞吐量集中区间:通过统计15%和85%的吞吐量边界值,计算出70%的吞吐量集中区间。区间越集中,吞吐量越稳定。

    响应时间:一次事务的处理时间。通常指从一个请求发出,到服务器进行处理后返回,再到接收完毕应答数据的时间间隔,单位:毫秒。

    平均响应时间:一段时间内响应时间的平均值。无法体现响应时间的波动情况。

    中间响应时间:一段时间内响应时间的中间值,50%响应时间,有一半的服务器响应时间低于该值而另一半高于该值。

    90%响应时间:一段时间内90%的事务响应时间比此数值要小。反应总体响应速度,和高于该值的10%超时率。是用来评估系统容量的重要指标之一。

    最小响应时间:响应时间的最小值。反映服务最快处理能力。

    最大响应时间:响应时间的最大值。反映服务器最慢处理能力。

    CPU占用率:1-CPU空闲率,表示CPU被使用情况,反映了系统资源利用情况。

    二、计算最耗时的加载操作

    1)从数据库读取数据,对加载的类型进一步划分各种类型,计算最耗时操作

    2)查看CPU随着在线人数的变化所占百分比

    可以看出从晚上8时到次日下午14时,各个服务器CPU变化区间是固定的。

    3)查看内存变化

    这个同样是晚上8时到下午14时,随着机器人数量变化而生成的图表。
    (内存处于一个区间段,说明程序没有内存泄漏。)

    4)备注

    对于具体的内存CPU所占的百分比,各个游戏之间对比是没有任何意义的,设计和数据的存储方式和存储结构都不相同,而这样的测试目的是在于了解 针对本款游戏在线玩家人数与服务器所占内存,CPU之间的一个关系,为了上线更好地控制每个服承载的最大人数做准备。

    三、MMORPG服务器对于压力测试来说,设计的特点

    1)MMORPG共同特点

    ①百分之八十以上的开发成本消耗在正常的逻辑处理上,而百分之八十以上的性能消耗点在和视野有关的模块上。

    • 举例
      比如《御龙在天》,移动包技能包在CPU上的消耗占比之和在30%以上;战斗做的好的《天涯明月刀》在群战时,仅技能逻辑消耗就在50%以上;另一款腾讯在研MMORPG,因为有后台寻路体素判定行为树定义的复杂AI以及分段技能设计,CPU消耗比同类产品要高,统计如下:
    1)场景心跳 75.5%
    2)战斗请求:11.3%
    3)移动请求:3.8%
    4)其他 : 6.6%
    5)剩余客户端请求:2.8%
    
    • 1
    • 2
    • 3
    • 4
    • 5

    2)MMORPG后台的两大驱动力

    • ①消息驱动:
      包含玩家上行协议的驱动和其他server的消息驱动,这部分的主要耗时来源时战斗请求包移动请求包,战斗和移动占这部分80%的性能消耗

    • ②定时器:
      包含各大系统的心跳逻辑以及各个OBJ的心跳逻辑,在承载5000个玩家在线时,怪物和NPC往往要打到10W个之多,因此定时器的主要耗时来源是场景心跳(AI\CD检查\扫敌等),这部分占整个CPU耗时处理的75%左右

    • ③这两部分组成了灰色区域,累计占比高达百分之90%。共同点是有很少的跨场景操作,以及少量公共数据访问(比如邮件、帮会等)。而百分之10%是UI上的各种请求

    3)LuaJIT的备注

    ①LuaJIT有2GB内存的限制(截至目前,官方的最新版本对64位支持是默认关闭的,不建议在release阶段使用),如果线程过多,有可能出现内存不够的情况。
    ②如果在移动、技能、AI的处理上没有过多使用Lua,那么建议还是使用LuaJIT保持效率。
    ③如果多线程逻辑过于依赖Lua,那么使用原生的Lua保持多线程的运行也是不错的选择

    四、各种测试方法的测评

    1)现网数据预估

    • 背景
      现网数据预估是根据压力测试过程中的部分数据,对未来大量用户访问的情况机型预估。图中的横轴代表现吞吐量纵轴代表CPU压力
    • 方法流程
      图中绿色的部分代表当前的服务器压力,当收集一段时间数据之后,可以模拟一条曲线。假设对服务器的上线成本预估是80%,可以通过曲线拟合的方式推测出现网的能力是多少,也从而推断出最大上限是多少。
    • 优缺点
      ①优点:测试结果方便可视
      ②缺点:通常游戏服务器都是比较复杂的,这种方式只适合简单的服务器拟合,复杂服务器数据就不太准确。

    2)真人买量压测

    • 方法流程
      真人压测就是通过邀请一定数量的真实用户来玩游戏,从而对服务器达到一个测试效果。这种方式他最大特点在于用户的行为相对是最真实的,因为用户的使用完全不会受到限制,和线上一个真实用户一样。目前游戏上线过程中的“封测”,就可以被认为是一种真人压测,可以帮助开发者发现一些性能问题。
    • 缺点
      ①暴露出的性能问题有限:许多经过封测的游戏到上线还会产生问题,原因之一就是封测人数通常还是太少,虽然有几百或者几千用户在玩,但是并发并不够,不足以暴露服务端性能问题;
      ②不适合调优:服务器性能测试不光需要暴露服务器的问题,暴露问题之后还需要不断的回归调优,但是真人是无法完全重复这些行为方式的。

    3)接口测试

    • 方法流程
      服务器方面的接口测试与传统意义上的接口测试略有不同,当开发人员需要对一套服务器进行评估,但是又时间不足的情况下,我们可以考虑选择一些具有代表性的功能,以及一些高风险功能进行测试,通过以小见大的方式,来评估整套服务器性能。
    • 缺点
      主要问题就是无法遍历整个服务器的接口,难以避免一些微小的问题。

    4)录制回放

    • 方法流程
      “录制”就是通过抓取数据包的方式,来获取游戏时的协议,比如用户登录游戏时抓取登录包;“回放”即把这些捕获的协议重新发送给服务端,这样理论上就可以通过工具放大协议量级达到性能测试的目的,比如将之前录制的登入协议扩大1w倍给服务器,这样就模拟了1w人同时登入的情况。

    • 缺点
      游戏的协议交互非常复杂,如果只是单纯的放大数据包,对于服务器是产生不了多大的压力的。这类方法比较适合固定输入输出服务类型的测试

    5)机器人测试

    • 方法流程
      机器人模拟测试是对以上各种测试做了一个平衡, 通过高还原真实玩家的用户行为,模拟高并发场景,从而得到类似很多人同时游戏的测试效果。
    • 机器人模拟的优势
      并发性不受限制,从1W到10W,压力能够自主设置;
      可以反复执行,便于性能调优回归;
      ③实现7*24小时不断监控,在开发提交代码之后,版本在自动编译之后就跑新的测试,这样每天都能进行性能监控,在调优方面,完全地进行一个重复性测试,可以不断的进行回归和调优。这个方法的问题就在于机器人模拟需要专人开发,对测试者的开发能力,分析能力都有一个比较高的要求。

    五、linux测试相关命令

    0)铺垫命令及火焰图使用

    • 火焰图介绍及链接
      ①https://blog.csdn.net/gatieme/article/details/78885908
      ②https://zhuanlan.zhihu.com/p/85654612
    • free
    • ping
    • vmstat(VirtualMeomoryStatistics,虚拟内存统计)
    • iostat 用于报告中央处理器(CPU)统计信息和整个系统、适配器、tty 设备、磁盘和 CD-ROM 的
    • 输入/输出统计信息
    • dstat 显示了cpu使用情况,磁盘io情况,网络发包情况和换页情况,输出是彩色的,可读性较强,相对于vmstat和iostat的输入更加详细且较为直观。
    • pidstat 主要用于监控全部或指定进程占用系统资源的情况,如CPU,内存、设备IO、任务切换、线程等。
    • top 命令的汇总区域显示了五个方面的系统性能信息:负载、进程状态、cpu使用率、内存使用、
      交换分区。
    • iotop LINUX进程实时监控工具,界面风格类似top命令
    • htop 是Linux系统中的一个互动的进程查看器,一个文本模式的应用程序(在控制台或者X终端中),需要ncurses。
    • mpstat Report processors related statistics. 报告CPU的统计信息。
    • netstat 用于显示与IP、TCP、UDP和ICMP协议相关的统计数据,一般用于检验本机各端口的网络连接情况。
    • ps 显示当前进程的状态
    • strace Trace system calls and signals。跟踪程序执行过程中产生的系统调用及接收到的信号,帮助分析程序或命令执行中遇到的异常情况。
    • ltrace A library call tracer 跟踪进程调用库函数的情况
    • uptime 能够打印系统总共运行了多长时间和系统的平均负载,uptime命令最后输出的三个数字的含义分别是1分钟,5分钟,15分钟内系统的平均负荷
    • lsof (list open files)是一个列出当前系统打开文件的工具。
    • perf 是Linux kernel自带的系统性能优化工具。优势在于与Linux Kernel的紧密结合,它可以最先应用到加入Kernel的new feature,用于查看热点函数,查看cashe miss的比率,从而帮助开发者来优化程序性能。
    • tcpdump
    • sar
    • blktrace
      在这里插入图片描述

    1)CPU

    • 问题 1:top 输出的利用率信息是如何计算出来的,它精确吗?

    • 问题 2:ni 这一列是 nice,它输出的是 cpu 在处理啥时的开销?

    • 问题 3:wa 代表的是 io wait,那么这段时间中 cpu 到底是忙碌还是空闲?

    (1)平均负载
    (2)CPU上下文切换
    (3)遇到CPU利用率高怎么排查
    (4)相关工具
    • ①vmStat -Sm 1
      r : 表示在这个CPU上正在执行的和等待执行的进程数量
      (r比较高表示CPU处于饱和状态)
    • ②pidstat 1
      对比top能滚动打印每个进程使用CPU的情况,这里的%CPU是可以超过100的,
      %400等于4个%100运行的CPU
    • ③mpstat -p ALL 1
      将每个CPU分解到各个状态的时间打印出来
      ①若用户态的CPU百分比占比高达100%,表明单线程遇到瓶颈
    • ON_CPU火焰图
      (1)使用说明
      ①纵轴代表调用栈的深度(栈桢数),用于表示函数间调用关系:下面的函数是上面函数的父函数。
      ②横轴代表调用频次,一个格子的宽度越大,越说明其可能是瓶颈原因。
      ③不同类型火焰图适合优化的场景不同,比如 on-cpu 火焰图适合分析 cpu 占用高的问题函数,off-cpu 火焰图适合解决阻塞和锁抢占问题
      (2)无意义的事情:
      ①横向先后顺序是为了聚合,跟函数间依赖或调用关系无关;
      ②火焰图各种颜色是为方便区分,本身不具有特殊含义
      (3)使用步骤
      使用步骤:
      ①采集堆栈:perf、System Tap、sample-bt
    查看CPU和内存占用前十的进程
    ps aux|head -1;ps -aux | sort -k3nr | head -n 10 //查看前10个最占用CPU的进程
    ps aux|head -1;ps -aux | sort -k4nr | head -n 10 //查看前10个最占用内存的进程
    
    • 1
    • 2
    • 3

    1、安装perf:我目前的服务器发行版是Ubuntu 16.04.6 LTS因此需要先安装perf才能使用,该工具由linux-tools-common提供,但是它需要安装后面的依赖。

    #ubantu安装
    root@master:~# apt install linux-tools-common linux-tools-4.4.0-142-generic linux-cloud-tools-4.4.0-142-generic -y
    
    root@master:~# perf -v #显示perf的版本
    perf version 4.4.167
    
    #centos安装
    yum install perf
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8

    2、在安装完成时候,我们就可以对上图CPU使用率最高的进程ID为25633的进程进行采样分析。首选我们采集一下该进程的调用栈信息:

    root@master:~# sudo perf record -F 99 -p 25633 -g -- sleep 30
    [ perf record: Woken up 1 times to write data ]
    [ perf record: Captured and wrote 0.039 MB perf.data (120 samples) ]
    
    • 1
    • 2
    • 3

    3、参数说明
    这个命令会产生一个大的数据文件,取决与你采集的进程与CPU的配置,如果一台服务器有16个 CPU,每秒抽样99次,持续30秒,就得到 47,520 个调用栈,长达几十万甚至上百万行。生成的数据采集文件在当前目录下,名称为perf.data

    1)perf record表示记录,命令可以从高到低排列统计每个调用栈出现的百分比
    2)-F 99表示每秒99次,
    3)-p 25633是进程号,即对哪个进程进行分析,
    4)-g表示记录调用栈,
    5)sleep 30则是持续30秒
    
    • 1
    • 2
    • 3
    • 4
    • 5

    可以简单在linux下展示每个调用栈出现的百分比

    root@master:~# sudo perf report -n --stdio
    
    • 1

    在这里插入图片描述

    ②解析数据:statckcollapse/pl(用perf script工具对perf.data进行解析,生成perf.unfold)

    # perf script -i /root/perf.data &> /root/perf.unfold
    或
    perf script -i perf.data &> perf.unfold
    
    • 1
    • 2
    • 3

    用 stackcollapse-perf.pl 将 perf 解析出的内容 perf.unfold 中的符号进行折叠

    #安装stackcollapse
    git clone https://github.com/brendangregg/FlameGraph.git
    #拷贝stackcollapse-perf.pl和flamegraph.pl到目标机器上。
    chmod +x flamegraph.pl
    chmod +x stackcollapse-perf.pl
    
    # ./stackcollapse-perf.pl /root/perf.unfold &> /root/perf.folded  //这里折叠堆栈
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7

    ③生成火焰图: flamegraph.pi

    ./flamegraph.pl /root/perf.folded > /root/perf.svg
    或
    ./flamegraph.pl perf.folded > perf.svg
    
    • 1
    • 2
    • 3

    浏览器打开。

    • ⑤OFF-CPU火焰图

    • ⑥内存火焰图

    • ⑦显示lua堆栈(chatgpt说的,我没试过)

    1. 安装perf工具
    2. 在终端输入以下命令:perf record -g -p $(pgrep lua)
    3. 运行lua程序
    4. 在终端输入以下命令:perf script | stackcollapse-perf.pl | flamegraph.pl > lua.svg
    5. 在浏览器中打开lua.svg文件,即可查看火焰图
      在perf record命令中加入–call-graph dwarf参数,即可在火焰图中看到lua的堆栈信息。修改后的命令如下:
      perf record -g --call-graph dwarf -p $(pgrep lua)
      $(pgrep lua)是一个命令,用于查找正在运行的名为"lua"的进程的进程ID。在这里,它被用作perf record命令的参数,以便perf工具可以记录正在运行的lua程序的性能数据。如果这个进程是C++写的,只是调用接口的时候使用lua,那么在perf工具记录性能数据时,只能看到C++的堆栈信息,无法看到lua的堆栈信息。在perf record命令中加入–call-graph dwarf参数,即可在火焰图中看到lua的堆栈信息。修改后的命令如下:
      perf record -g --call-graph dwarf -p $(pgrep lua)
      -g: 开启调用图(call graph)功能,记录函数调用关系
      –call-graph dwarf: 使用dwarf调试信息来生成调用图
      -p $(pgrep lua): 指定要记录的进程ID,这里使用pgrep命令查找名为"lua"的进程的进程ID

    2)内存

    (1)内存说明:虚拟内存和物理内存
    (2)内存中的buffer和cache
    (3)内存检测工具
    (1)vmstat统计虚拟内存使用情况
      • 使用举例
        1)动态查看内存变化
        在这里插入图片描述
        2)查看内存量和使用量
        在这里插入图片描述
    • 参数意义

    swpd  交换出的内存量
    free 空闲的可用内存
    buff 用于缓冲缓存的内存
    cache 用于页缓存的内存
    si   换入的内存(换页)
    so 换出的内存(换页)
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 注释
      若so和si一直为非0,说明有大量换页的操作,用top或ps可以看每个进程使用的内存

    • 命令

    Usage:
     vmstat [options] [delay [count]]
    
    Options:
     -a, --active           active/inactive memory
     -f, --forks            number of forks since boot
     -m, --slabs            slabinfo
     -n, --one-header       do not redisplay header
     -s, --stats            event counter statistics 输出列表
     -d, --disk             disk statistics
     -D, --disk-sum         summarize disk statistics
     -p, --partition <dev>  partition specific statistics
     -S, --unit <char>      define display unit  ### 单位,按照多少内存对齐k(1000),K(1024),m(1000000),M(1048576) bytes
     -w, --wide             wide output
     -t, --timestamp        show timestamp
    
     -h, --help     display this help and exit
     -V, --version  output version information and exit
     
    For more details see vmstat(8).
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    (2)PSI略过,需要linux版本4.20
    (3)PS 查看进程报错内存使用的细节
    • 使用
      建议用 ps aux
    • 注释
      %MEM 主存使用(物理内存\RSS)占总内存的百分比
      RSS:常驻集合大小(KB),显示内存使用量,包括如系统库在内的共享内存端,可能会被几十个进程映射,这里重复计算了部分共享内存
      VSZ:虚拟内存大小
    root:# ps aux
    
    USER      PID       %CPU    %MEM    VSZ    RSS    TTY    STAT    START    TIME    COMMAND
    
    smmsp    3521    0.0    0.7    6556    1616    ?    Ss    20:40    0:00    sendmail: Queue runner@01:00:00 f
    
    root    3532    0.0    0.2    2428    452    ?    Ss    20:40    0:00    gpm -m /dev/input/mice -t imps2
    
    htt    3563    0.0    0.0    2956    196    ?    Ss    20:41    0:00    /usr/sbin/htt -retryonerror 0
    
    htt    3564    0.0    1.7    29460    3704    ?    Sl    20:41    0:00    htt_server -nodaemon
    
    root    3574    0.0    0.4    5236    992    ?    Ss    20:41    0:00    crond
    
    xfs    3617    0.0    1.3    13572    2804    ?    Ss    20:41    0:00    xfs -droppriv -daemon
    
    root    3627    0.0    0.2    3448    552    ?    SNs    20:41    0:00    anacron -s
    
    root    3636    0.0    0.1    2304    420    ?    Ss    20:41    0:00    /usr/sbin/atd
    
    dbus    3655    0.0    0.5    13840    1084    ?    Ssl    20:41    0:00    dbus-daemon-1 --system
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    (4)TOP查看内存和CPU占比

    常用命令
    -o表示按照什么标准排序

    top -0 %MEM
    top -o %CPU
    
    • 1
    • 2
    (5)pmap 内存映射相关,共享内存相关(略)
    (7)perf工具

    3)文件IO性能监控

    (1)I/O的两种方式(缓存I/O和直接I/O)
    (2)监控磁盘I/O的命令

    4)网络IO性能监控

    (1)性能指标
    (2)网络信息
    (3)相关命令

    5)其他工具

    (1)nmon性能监控
    (2)glances系统监控
    (3)w
    (4)日志监控工具tail和mutitail
    (5)火焰图种类说明

    在这里插入图片描述

  • 相关阅读:
    “深入理解C++类默认成员函数:探索构造、析构与复制“
    【ES笔记01】ElasticSearch数据库之index索引、doc文档、alias别名、mappings映射结构的基本操作
    Anaconda下载安装(全过程详细截图)
    k8s控制器之Deployment第四弹之回滚Deployment
    量化初探: 对称量化以及非对称量化
    MongoDB 常用命令
    通过 Jetbrains GateWay实现Remote Development
    IMX6ULL学习笔记(7)——通过SD卡启动U-Boot
    中小企业数字化转型的痛点分析
    6.12ctf练习
  • 原文地址:https://blog.csdn.net/weixin_43679037/article/details/128164582