nmon续集
对于nmon的后续使用中
第一:sz $filename 命令
只能在该文件的目录下进行;
sz命令只能传输文件,不能传输文件夹(即如果有多个文件必须单个传输),所以如果出现大的文件包,还是只能用xftp;
第二:在使用nmon analyser v55
对应的数据找寻的位置:
e.g.
CPU平均(%):ez one
java内存占用(M):查gc.log解析
平均网络输出(K/S):3909.3
最大网络输出(K/S):4192.6
平均网络输入(K/S):961.3
最大网络输入(K/S):1032.3
平均磁盘IO(w/r):403.7/4.1
最大磁盘IO(w/r):1136.6/1372.4
补充:
使用NMON统计硬件性能;
通过GCViewer工具分析GCLog:https://gceasy.io/
第三:采集数据分析
$ nmon -s 10 -c 60 -f -m /home/
-s10 每 10 秒采集一次数据
-c60 采集 60 次,即为采集十分钟的数据
-f 生成的数据文件名中包含文件创建的时间
-m 生成的数据文件的存放目录
$ nmon -f -s 10 -c 720 -m /home
-s10 每 10 秒采集一次数据
-c720 采集 720 次,即为采集2小时的数据
第四:nmon script使用
$ mkdir 断线重连
$ ls
$ cd 断线重连/
$ nmon
-bash: nmon: command not found
这次我们使用nmon script:
$ cd work
$ ls
script
$ cd script
$ ls
bp3_install_zabbix_.sh del_javadump.sh deploy.py history_backup.sh iptables_check.sh nmon
$ ./nmon -f -s 10 -c 720 -m /home/zhangsunqian/test/断线重连
(Linux中运行文本用 ./ )
检查nmon进程:
$ ps -ef | grep nmon
name+ 1165 29856 0 15:36 pts/2 00:00:00 grep --color=auto nmon
name+ 32693 1 0 15:33 pts/2 00:00:00 ./nmon -f -s 10 -c 720 -m /home/zhangsunqian/test/断线重连
这里nmon采集的是我们data server上的cpu性能;
第五:Linux 文件复制与tail -f 和cat查error log
]$ cp -rf /data/bp3/GameServer_1003/gc.log
cp: missing destination file operand after ‘/data/bp3/GameServer_1003/gc.log’
命令格式:cp sourceFile destFile;
$ cp /data/bp3/GameServer_1003/gc.log /home/name/test/断线重连/
[name@VM-0-21-centos 断线重连]$ ls
gc.log VM-0-21-centos_210118_1533.nmon
使用指令 cp 将当前目录 test/ 下的所有文件复制到新目录 newtest 下,输入如下命令:
$ cp –r test/ newtest
接下来,查错时间:
e.g. 需要通过查机器人是否被部署上去,如果没有,相当于白测,这个是主要观测的地方;
这种报错有可能是因为配置的原始数据问题,起初在代码中找到supersdk显示报错,结果发现是因为配置的channelID为空导致getContent为空,所以call back object = null;
JSONObject jsonObject = ((JSONObject) JSON.parse(getContent())).getJSONObject("user");
(如图为部署成功后日志反馈)
第六:report
首先报告中需要说明本次压测的具体目的以及测试指标:
我们这次测试主要是针对登录,测试压力上限为5000人分配与场景中,一个场景4个机器人共1250个机器人,然后每一个人分配200只怪,共计1250*200=2,5000含碰撞体积。
如果是要调试人数压力:
- 减少压力(人数):
ps -ef |grep java
root 13007 1 52 16:03 ? 00:23:42 java -server -Xms2048m -Xmx2048m -Xss1024K -XX:MetaspaceSize=1024m -XX:MaxMetaspaceSize=1024m -verbose:gc -Xloggc:gc.log -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Dsun.reflect.noInflation=true -cp resources:BPTest-1.jar com.game2sky.bp.test.MainTest
root 13072 1 48 16:03 ? 00:22:08 java -server -Xms2048m -Xmx2048m -Xss1024K -XX:MetaspaceSize=1024m -XX:MaxMetaspaceSize=1024m -verbose:gc -Xloggc:gc.log -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Dsun.reflect.noInflation=true -cp resources:BPTest-1.jar com.game2sky.bp.test.MainTest
root 13152 1 49 16:04 ? 00:22:19 java -server -Xms2048m -Xmx2048m -Xss1024K -XX:MetaspaceSize=1024m -XX:MaxMetaspaceSize=1024m -verbose:gc -Xloggc:gc.log -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Dsun.reflect.noInflation=true -cp resources:BPTest-1.jar com.game2sky.bp.test.MainTest
root 13222 1 50 16:04 ? 00:22:43 java -server -Xms2048m -Xmx2048m -Xss1024K -XX:MetaspaceSize=1024m -XX:MaxMetaspaceSize=1024m -verbose:gc -Xloggc:gc.log -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Dsun.reflect.noInflation=true -cp resources:BPTest-1.jar com.game2sky.bp.test.MainTest
5000人,一个服上1250个,一共5条进程,kill -9 一条就是250人;e.g. 上边一共1000人;
- 增加压力(人数):
$ cd test1/
[name@VM_0_85_centos test1]$ ls
BPTest-1.jar BPTest.properties gc.log hs_err_pid15508.log hs_err_pid4724.log nohup.out resources start.sh
手动在各个test文件中起机器人,一个里面250人,一共5个test file;
补充:观察卡顿出现在服务器还是客户端的技巧,砍怪看反馈,如果没有反馈,卡顿出现在服务器,反之;
接下来是测试硬件环境:
本服是数据收集,客户端环境就是做压测的位置;
下面是查服务器内核info(之前提过)以及cpu的information
[name@VM_0_85_centos script]$ uname -a
Linux VM_0_85_centos 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[name@VM_0_85_centos script]$ ./nmon
[name@VM_0_85_centos script]$ cat /proc/cpuinfo
还有就是过程中几个个Linux命令的使用:
-
rm -rf $package(直接删除文件夹内all以及文件夹)
-
rm $fileName (和sz很像,只能是单个文件而且要在对应目录下)
-
find $keyWord (只能在~目录下搜索)
-
find / -name example.txt : 在根目录下开始寻找example.txt (不太好用,建议用locate)
-
find -name test.file:查找test.file (不太好用,建议用locate)
-
locate $fileName (同样只能是单一文件)
$ find test
$ locate start.sh