关于ejabberd用在webgame中作聊天服务器的问题

[庆亮]

首先声明一下，本人是个菜鸟，所以就产生了这个问题。

情况是这样的：
在我们的应用中，用了ejabberd作为聊天服务器，前端采用的是flex，通过socket连接上服务器。 数据和业务逻辑使用php来处理，当有
消息发给用户时，就把这条消息丢给MemcacheQ。 服务器上另有shell专门从mq中取出消息发给ejabberd，shell中发消息是用这
样的特殊帐号(system******@testdomain.com)，前台flex收到system发来的私聊信息就认为系统消息。这是我们实现
系统消息的方式。

现在的情况是，一旦用户多了，公共频道有时会连接不上，而我们自己实现的系统消息会延迟很多，可能有30秒到1分多钟。查看日志发现，ejabberd
很早就收到了shell发来的消息，但是前端实际收到就是由延迟。

如果用户少，基本上不会出现上面的情况。

看了之前有人讨论的“erlang中的最大问题”，现在猜测是不是用于进程调度问题，导致私聊进程卡住的数据太多了？

环境与配置：

ejabberd-2.0.5 服务器8核 64位， 内存为12G

各位老大，走过路过不要错过，指点一下小弟吧。

[Feng Yu]

每个频道多少用户？你的ejabberd占用多少cpu 多少内存？我可以肯定的时候 ejabberd在万把人一个按照你的机器配置是完全没有问题的 。 你可以用wireshark之类的抓包工具看下你的包发送情况。

专注 高性能 容错 分布服务器的实现（erlang）
http://blog.yufeng.info

[庆亮]

谢谢。

 

每个频道都没有超过1000人，也就7、8百的样子。按照ejabberd的性能描述，在这个级别不可能出现性能的问题。内存平均占用在4-5G左右，CPU 45%上下波动。

 

额，不好意思，关于用wireshark抓包不太明白思路，抓包分析什么数据？ 基本入手点是什么？按说应该不会是网络问题，因为频道不会延迟。 频道不能加入是由于房间人数满了的问题，一旦加入了频道则消息是几乎没有延迟的。

[wolfgang amadeus]

余老大的意思是让你用 Wireshark，分析下数据是不是象你说的在服务器端没及时下发给客户端，还是由于客户端的原因导致消息阻塞，起码分析出问题是在服务器端，还是客户端

Wireshark 用起来还是很简单的，打开设置下抓取哪块网卡的数据包，然后启动，你就看到各种协议的消息包从上面刷刷的，然后设置下filter，过滤下你关心的数据，肯定是TCP协议啦，然后目的端口设置下，就可以分析了

[庆亮]

OK，多谢，我试试。

[庆亮]

确认了一下，客户端的确没有收到，发现服务端dump了，产生了 erl_crash***************.dump
这样的问题，打开之后发现信息量相当多。需要贴出什么信息来判断dump的原因？
--
生命的意义在于不断的追求与学习.
Blog:www.nd21.com

[庆亮]

使用webtool的crashdumpviewer查看到如下信息

Slogan	Kernel pid terminated (application_controller) ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}})
Node name	'nonode@nohost'
Crashdump created on	Mon Sep 28 11:41:53 2009
System version	Erlang (BEAM) emulator version 5.6.5 [source] [64-bit] [smp:8] [async-threads:0] [hipe] [kernel-poll:false]
Compiled	Sat Sep 26 05:36:03 2009
Memory allocated	18023576 bytes
Atoms	4346
Processes	4
ETS tables	0
Funs	234

顺便问一下：[kernel-poll:false] 这个是否为true性能会高一些？

Process Information   Help

Pid	Name/Spawned as	State	Reductions	Stack+heap	MsgQ Length
<0.0.0>	init	Running	3503	4181	1
<0.2.0>	erl_prim_loader	Waiting	25502	2584	0
<0.4.0>	error_logger	Waiting	261	987	0
<0.12.0>	erlang:apply/2	Waiting	29	233	0

Loaded Modules Information   Help

Current code: 1914197 bytes
Old code: 0 bytes

Module	Current size (bytes)	Old size (bytes)
otp_ring0	1240
init	68984
prim_inet	99624
prim_file	43297
zlib	13880
prim_zip	28616
erl_prim_loader	78048
erlang	26664
error_handler	5895
heart	13191
error_logger	12806
gen_event	48961
gen	13083
proc_lib	28640
application_controller	113112
lists	115437
gen_server	43418
application	5549
sys	23843
application_master	20492
kernel	15849
supervisor	55355
dict	33372
rpc	25429
gb_trees	16208
global	121977
inet_db	73369
inet_config	36013
os	12388
inet_udp	4826
inet	57750
inet_parse	45084
erl_scan	43896
erl_parse	226211
inet_hosts	7148
erl_distribution	4651
net_kernel	82749
inet_tcp_dist	22839
erl_epmd	28303
auth	23533
filename	32536
file	40230
inet_tcp	5474
gen_tcp	6625
ets	65155
io_lib	22447

各位帮忙看看上面的信息是否能够得出一点有用的结论？

这个是top的信息，比较稳定
  PID USER      PR  NI %CPU    TIME+  %MEM  VIRT  RES  SHR S COMMAND 
10326 root      22   0   20 390:54.07 49.2 8797m 5.8g 3080 S beam.smp

[Feng Yu]

kpoll竟然是false 这个性能影响非常大， 而且内存达到4-5G， 这个本身就很不正常。

kpoll极大的降低cpu的使用率，一点要打开。

你的erlang的版本是R12B5， 改用R13B02很大性能改进。

你上面的问题 可以断定是cpu 过高， 服务端响应太慢的问题。

专注 高性能 容错 分布服务器的实现（erlang）
http://blog.yufeng.info

[Feng Yu]

ejabberd上面总的多少用户？

专注 高性能 容错 分布服务器的实现（erlang）
http://blog.yufeng.info

[庆亮]

非常感谢余老大，总的注册用户3W，在线用户在1K左右，所有用户全部加在一个room中了。然后每1/3的用户又各自加入一个room，总共四个room，一个大的，三个稍微小点的。

[Feng Yu]

总共才不到4千用户是吧， 你发消息的频度是？几秒一个？

专注 高性能 容错 分布服务器的实现（erlang）
http://blog.yufeng.info

[庆亮]

system888@testdomain这样的账号发私聊消息给用户大概在1-2秒一次， room中就是正常的聊天了。 因为关掉了日志，所有没有很详细的解释。

 

重新编译了erlang，用的是 13B02-1 ，加上了k-poll，但是奇怪的是 ejabberd中带上 -K  true 启动参数，启动后依然是 kernel-poll 为false， 使用 + K true启动erl命令行则kernel-poll 为true， 但是ejabberd中使用+K true依然是 kernel-poll  为 false。

[庆亮]

上面说的理解错误。 1K在线，假设服务器发给用户的消息为5-10秒一条，则每秒需要发出100 - 200 条消息。

[Feng Yu]

-K  true  是+K true  你自己改下启动文件。
按照你说的规模 cpu应该在15%以下才正常， 我不知道你什么环节有问题了

专注 高性能 容错 分布服务器的实现（erlang）
http://blog.yufeng.info

[庆亮]

启动文件修改了无效（修改成+K true），beam.smp文件的cpu内存从开始的 10% 1G左右到后来慢慢就百分之三四十， 4、5G了。不知道哪里导致某个进程卡住了，之前这个列表不是讨论过关于进程公平调度的问题了么？ 是不是这里也是由于system这样的JID发送了过多的信息，但是又得不到充分的cpu时间导致的？

--
生命的意义在于不断的追求与学习.
Blog:www.nd21.com

[庆亮]

统计了一下具体的数量，每秒140条消息发出。

--
生命的意义在于不断的追求与学习.
Blog:www.nd21.com

[夏一平]

才这么点啊 erlang效率这么低啊

[Feng Yu]

不可能 一定是什么地方搞错了

专注 高性能 容错 分布服务器的实现（erlang）
http://blog.yufeng.info

2009/9/28 夏一平 <drea...@gmail.com>

[庆亮]

现在确定是由于进入房间过于频繁导致大量的for循环发presence信息从而严重的影响性能。由于我们的应用的特殊性，我们决定修改代码来适应我们的需要。


--
生命的意义在于不断的追求与学习.
Blog:www.nd21.com

[庆亮]

进过昨晚的努力，这个问题已经搞定，针对我们的情况对ejabberd的源码修改了一下，主要是对presence部分的代码。 谢谢余老大的指导和热心的swingbach的帮忙。
--
生命的意义在于不断的追求与学习.
Blog:www.nd21.com

[jiangzhx]

学习了，我们最近也要做聊天这样的应用。

我从网上搜到关于ejabberd的MUC介绍如下：

This module supports clustering and load balancing. One module can be started per cluster node. Rooms are distributed at creation time on all available MUC module instances. The multi-user chat module is clustered but the rooms themselves are not clustered nor fault-tolerant: if the node managing a set of rooms goes down, the rooms disappear and they will be recreated on an available node on first connection attempt.

我没有太看明白，MUC到底是分布式的，还是不是？

The multi-user chat module is clustered but the rooms themselves are not clustered nor fault-tolerant

这句话怎么翻译。

还有一个问题是，每个房间的最大承载量是多少？我看到网上一些介绍，说是达到400+以上，就会在分发的时候有很大的延迟。就是以下的代码，他就是把每一条消息，通过foreach的方式分发到各个用户。

   lists:foreach(

     fun({_LJID, Info}) ->

     ejabberd_router:route(

jlib:jid_replace_resource(

 StateData#state.jid,

 FromNick),

Info#user.jid,

Packet)

     end,

     ?DICT:to_list(StateData#state.users)),

在 2009年9月29日星期二UTC+8上午11时33分46秒，庆亮写道：