免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
12下一页
最近访问板块 发新帖
查看: 5874 | 回复: 12
打印 上一主题 下一主题

[FreeBSD] [求助]为什么CS服务器CPU占用高! [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2010-06-11 11:41 |只看该作者 |倒序浏览
首先谢谢大家伸出援助之手,我只想解决问题。
纯净FreeBSD 8.0 服务器,Xeno 3.2G两颗,2G内存,219GRaid0,按经典安装来的,重编内核及安装了linux_base f10(FreeBSD7.3的时候安装过fc6),只运行CS服务器(不含任何插件),开启后输入stats命令查看资源使用情况,空置服务器FPS非常稳定1000,22人满后,会从100~1000之间乱跳,服务器有跳PING现象,突然发现CPU占用是99.9%,可我在ssh里top出来的CPU占用空置时0.1%,人满时20%左右,这就让我非常不理解了,为什么用rcon stats出来CPU占用是99.9%,怪不得会跳PING呢,都这么高的占用肯定要跳PING,后来发现,空置服务器时,rcon stats出来的CPU占用也是99.9%,top出来的可不是这样。
郁闷好久了,不要和我说linux端在FreeBSD下如何如何,我都试过了,Debian 5.04安装N遍了,Debian够纯linux了吧,虽然stats出来CPU占用下来了,可是fps非常不稳定,而且PING值比在FreeBSD下要高,不要提Windows,不在考虑范围,虽然我是FreeBSD新手。
不知道别人情况如何,虽然在Debian下CPU占用比较正常,可是我试过了,根本没有在FreeBSD下稳定,被人喷我也认了,主要能帮我找出为什么FreeBSD下stats出来的CPU占用是99.9%就可以了。
再次感谢大家,帮我分析一下!


第二个问题,不另开贴了,浪费资源,虚幻竞技场3,大家应该知道吧,我现在下载了服务端,架一个UT3的服务器,可是奇怪死了,新安装完后第一次运行肯定可以运行起来,但是Ctrl+C完,做出sh启动后,再次启动服务器,就永远也起不来了,然后必须要reboot服务器,还得重新安装一遍,而且得改变目录,还是可以启动一次,可再次启动又无法启动了,郁闷死我了。我的服务器已经让我重装N次了,唉。没办法,只能麻烦大家了,我知道用FreeBSD做游戏服务器的应该是占少数的,但还是希望大家帮帮忙!

论坛徽章:
0
2 [报告]
发表于 2010-06-12 01:49 |只看该作者
查看过steam官方网站论坛,stats出来的数据都说这是错误显示,郁闷了

论坛徽章:
2
技术图书徽章
日期:2013-09-04 15:21:51酉鸡
日期:2013-11-01 21:20:20
3 [报告]
发表于 2010-06-12 17:26 |只看该作者
获取系统状态vmstat比较靠谱些

论坛徽章:
0
4 [报告]
发表于 2010-06-13 10:24 |只看该作者
本帖最后由 myneo 于 2010-06-13 10:28 编辑

找到了问题所在,可我搞不懂怎么回事,大家帮帮忙!
在/boot/loader.conf里kern.hz这个参数上,默认是100吧。
1、按kern.hz=100启动后,CS服务器设定+fps_max 100  +sys_ticrate 1100 不加任何插件纯净启动,服务器的FPS从33~100之间跳。CPU占用 0.1%,和top -P数据一样。
2、按kern.hz=1000启动后,CS服务器设定+fps_max 100  +sys_ticrate 1100 不加任何插件纯净启动,服务器的FPS从333~500之间跳,人满的情况下有时会最低跳到90。CPU占用 20%~40%跳,玩家超过10个人立刻到99.9%,top -P数据空服0.1%,人满20%。
3、按kern.hz=2000启动后,CS服务器设定+fps_max 100  +sys_ticrate 1100 不加任何插件纯净启动,服务器的FPS从333~1000之间跳,人满的情况下有时会最低跳到100。CPU占用 80%~99.9%跳,玩家超过1个人始终99.9,top -P数据空服0.1%,人满20%。
可以这样说,非常的不稳定,难道和硬件有关系吗?我真不明白了!DELL1750的1U机器,双Xeno 3.2G,内存2G,Raid0 219G,和温度有关吗?还是什么!唉!郁闷死了!

论坛徽章:
2
技术图书徽章
日期:2013-09-04 15:21:51酉鸡
日期:2013-11-01 21:20:20
5 [报告]
发表于 2010-06-13 10:36 |只看该作者
kern.hz,是调整tick的,与中断有关联。tick越高,可以响应的中断相当多,消耗的CPU也就越高。分析问题还是看vmstat吧。是否是上下文切换导致的?或者其他IO?

论坛徽章:
0
6 [报告]
发表于 2010-06-13 13:28 |只看该作者
去掉CS里sys_ticrate 1100参数看看。另外FB8 HZ默认是1000,不是100。

论坛徽章:
0
7 [报告]
发表于 2010-06-13 18:39 |只看该作者
mirnshi

这是top -P的
last pid:  4452;  load averages:  0.00,  0.00,  0.00    up 0+16:44:50  18:29:53
26 processes:  1 running, 25 sleeping
CPU 0:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU 1:  0.8% user,  0.0% nice, 12.8% system,  0.0% interrupt, 86.5% idle
Mem: 91M Active, 461M Inact, 188M Wired, 36K Cache, 112M Buf, 1263M Free
Swap: 4062M Total, 4062M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME    CPU COMMAND
3516 root        1  50    0   233M 94812K select  1  33:26  0.10% hlds_i686
3517 root        1  44    0   233M 94812K select  1   3:20  0.00% hlds_i686

这是rcon stats的
18:29:46 stats
18:29:46 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00     491    60  217.34       0

这是vmstat的
myneo# date
Sun Jun 13 18:31:09 CST 2010
myneo# vmstat
procs      memory      page                   disk   faults         cpu
r b w     avm    fre   flt  re  pi  po    fr  sr am0   in   sy   cs us sy id
0 0 0    363M  1262M    12   0   0   0    13   0   0   14 12415 4158  1  6 93

基本在同一时间截的,都有时间


macafee

去掉sys_ticrate参数后,
18:35:44 stats
18:35:44 CPU   In    Out   Uptime  Users   FPS    Players
         26.67  0.00  0.00       0     0   90.19       0
18:35:50 sys_ticrate
18:35:50 "sys_ticrate" is "100.0"

kern.hz值均是2000的情况下,出来的结果!

论坛徽章:
0
8 [报告]
发表于 2010-06-13 18:45 |只看该作者
macafee

这是把sys_ticrate也改成2000的样子
18:41:21 stats
18:41:21 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0 1000.00       0
18:41:22 stats
18:41:22 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  711.74       0
18:41:22 stats
18:41:22 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0 1000.00       0
18:41:22 stats
18:41:22 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  832.64       0
18:41:23 stats
18:41:23 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  713.27       0
18:41:23 stats
18:41:23 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0 1000.00       0
18:41:23 stats
18:41:23 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  927.64       0
18:41:23 stats
18:41:23 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  862.81       0
18:41:23 stats
18:41:23 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0 1000.00       0
18:41:24 stats
18:41:24 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0 1000.00       0
18:41:24 stats
18:41:24 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  854.70       0
18:41:24 stats
18:41:24 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  783.70       0
18:41:24 stats
18:41:24 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0 1000.00       0
18:41:24 stats
18:41:24 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0 1000.00       0
18:41:24 stats
18:41:24 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  648.51       0
18:41:25 stats
18:41:25 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0 1000.00       0
18:41:25 stats
18:41:25 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  667.11       0
18:41:25 stats
18:41:25 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0 1000.00       0
18:41:25 stats
18:41:25 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0 1000.00       0
18:41:25 stats
18:41:25 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  500.00       0
18:41:26 stats
18:41:26 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0 1000.00       0
18:41:26 stats
18:41:26 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  992.06       0
18:41:26 stats
18:41:26 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  741.84       0
18:41:26 stats
18:41:26 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0 1000.00       0
18:41:26 stats
18:41:26 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  712.76       0
18:41:26 stats
18:41:26 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  786.16       0
18:41:27 stats
18:41:27 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  761.04       0
18:41:27 stats
18:41:27 CPU   In    Out   Uptime  Users   FPS    Players
         99.90  0.00  0.00       1     0  500.25       0

郁闷死了,非常不稳定。
我编译过内核,加入过sysctl.conf,loader.conf,其它什么都没改,用的经典安装,只同步ports和src,连minimal都没选,linux_base-f10是在同步完ports后用ports安装的。

论坛徽章:
0
9 [报告]
发表于 2010-06-13 18:52 |只看该作者
这是sysctl.conf
#security.bsd.see_other_uids=0
compat.linux.osrelease=2.6.16
net.inet.tcp.sendspace=32768
net.inet.tcp.recvspace=65536
net.inet.udp.maxdgram=65536
kern.ipc.maxsockbuf=524288
kern.maxfiles=65536
kern.maxfilesperproc=32768
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=1
net.inet.ip.redirect=0
net.inet.icmp.icmplim=200
net.inet.tcp.msl=2500
net.inet.tcp.blackhole=2
kern.ipc.somaxconn=32768
kern.coredump=0
这是loader.conf
autoboot_delay="1"
kern.dfldsiz="2147483648"
kern.hz="2000"
kern.maxdsiz="2147483648"
kern.maxusers="256"
kern.ipc.maxsockets="65535"
kern.ipc.nmbclusters="32768"
kern.ipc.nmbufs="65535"
kern.ipc.nsfbufs="2496"
内核太多了,我就不发了,我只保留了我的网卡驱动,SCSI,RAID,fireware等,其他的全去了,我记的6.2的时候有个machine  type  i386的,7.3和8.0都没这条了,还有只留了cpu        I686_CPU

我现在手头找不到p47协议的 HLDS3651服务端了,我现在开始怀疑是p48协议的问题了。

我在Debian下测试的时候,rcon stats出来的CPU占用就不是这样,难道还和linux_base有关?Debian 5.04我记不清是2.6.20多还是30多了。

论坛徽章:
0
10 [报告]
发表于 2010-06-13 19:47 |只看该作者
很显然你的CPU承受不起sys_ticrate 2000这样不切实际的参数。这个参数要根据CPU的能力来调整,不顾一切的调大没有任何用处。估计依你的CPU能力能在20人下维持250桢左右就很不错了。建议sys_ticrate调整为260-280。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP