[Server-devel] Ejabberd CPU/RAM Spike - Crashes
Here is another example after it has been running all night. http://pastebin.com/m11537281 As you can see, these runaway beam processes vary greatly in there RAM usage. Also, they are always using 100% of the cpu. I will try to clear the DB now and see what happens. On Fri, Dec 18, 2009 at 12:51 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Fri, Dec 18, 2009 at 1:37 PM, Devon Connolly dev...@gmail.com wrote: Anyway, back on topic... Here is that script slightly modified running on a fresh boot. I'm going to leave this looping and post the file to pastebin. Here is an initial output after only like 10 minutes. It will get more interesting over time. I'll paste another later this afternoon. outrageous. beam should have only ~40MB in use, total. if you 'clear' the mnesia db as i suggested (keep a copy for forensics!), does it get better? m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Ejabberd CPU/RAM Spike - Crashes
Changing the domain, I still get the following error when it tries (and
fails to shutdown ejabberd).
___
Crash dump was written to: erl_crash.dump
Kernel pid terminated (application_controller)
({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}})
{error_logger,{{2009,12,19},{12,19,16}},Protocol: ~p: register error:
~p~n,[inet_tcp,{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},{net_kernel,start_protos,4},{net_kernel,start_protos,3},{net_kernel,init_node,2},{net_kernel,init,1},{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}]}
{error_logger,{{2009,12,19},{12,19,16}},crash_report,[[{pid,0.20.0},{registered_name,net_kernel},{error_info,{exit,{error,badarg},[{gen_server,init_it,6},{proc_lib,init_p_do_apply,3}]}},{initial_call,{net_kernel,init,['Argument__1']}},{ancestors,[net_sup,kernel_sup,0.8.0]},{messages,[]},{links,[#Port0.84,0.17.0]},{dictionary,[{longnames,false}]},{trap_exit,true},{status,running},{heap_size,610},{stack_size,23},{reductions,505}],[]]}
{error_logger,{{2009,12,19},{12,19,16}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{'EXIT',nodistribution}},{offender,[{pid,undefined},{name,net_kernel},{mfa,{net_kernel,start_link,[[ejabberdctl,shortnames]]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]}
{error_logger,{{2009,12,19},{12,19,16}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfa,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]}
{error_logger,{{2009,12,19},{12,19,16}},crash_report,[[{pid,0.7.0},{registered_name,[]},{error_info,{exit,{shutdown,{kernel,start,[normal,[]]}},[{application_master,init,4},{proc_lib,init_p_do_apply,3}]}},{initial_call,{application_master,init,['Argument__1','Argument__2','Argument__3','Argument__4']}},{ancestors,[0.6.0]},{messages,[{'EXIT',0.8.0,normal}]},{links,[0.6.0,0.5.0]},{dictionary,[]},{trap_exit,true},{status,running},{heap_size,233},{stack_size,23},{reductions,123}],[]]}
{error_logger,{{2009,12,19},{12,19,16}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]}
{Kernel pid
terminated,application_controller,{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]
Crash dump was written to: erl_crash.dump
Kernel pid terminated (application_controller)
({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}})
__
Beam is still consuming 100% of the cpu after a few minutes. I'm going to
leave that script running to see what it does over the next few hours.
I imagine I now have to re-register all XO's?
On Sat, Dec 19, 2009 at 10:59 AM, Devon Connolly dev...@gmail.com wrote:
Here is another example after it has been running all night.
http://pastebin.com/m11537281
As you can see, these runaway beam processes vary greatly in there RAM
usage. Also, they are always using 100% of the cpu.
I will try to clear the DB now and see what happens.
On Fri, Dec 18, 2009 at 12:51 PM, Martin Langhoff
martin.langh...@gmail.com wrote:
On Fri, Dec 18, 2009 at 1:37 PM, Devon Connolly dev...@gmail.com wrote:
Anyway, back on topic... Here is that script slightly modified running
on
a fresh boot. I'm going to leave this looping and post the file to
pastebin. Here is an initial output after only like 10 minutes. It
will
get more interesting over time. I'll paste another later this
afternoon.
outrageous. beam should have only ~40MB in use, total.
if you 'clear' the mnesia db as i suggested (keep a copy for
forensics!), does it get better?
m
--
martin.langh...@gmail.com
mar...@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] XO 1.5 to XS-onXO1 behavior
Hi Sameer, that's expected, unfortunately. The XS-on-XO runs an active antenna / mesh gateway in the sense of 802.11s. As the current XO-1.5 drivers/firmware don't talk 802.11s, it won't work. In that sense, the XO-1.5 is the same as any other 802.11a/b/g device. There are two paths to address this - get the hostap / thinfirm driver+firmware combo working again. It was last seen working on a 2.6.17 i think. - get 802.11s on XO-1.5 going. this is not trivial... cheers, m On Sat, Dec 19, 2009 at 12:00 AM, Sameer Verma sve...@sfsu.edu wrote: I haven't had much time to look into XS-on-XO1.5 (will look into it as soon as Fall semester finishes) but I have a XS-on-XO1 running at home and when a XO1 associates with it, the XO1 gets a 172.18.xxx.xxx address (school mesh portal). When the XO1.5 associates with school-mesh-0 (I have to click on it in the Neighborhood view) the association happens, but the XO1.5 gets 169.254.xxx.xxx address, and beyond that the network is unusable. Thought I'd pass that along. Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor, Information Systems Director, Center for Business Solutions San Francisco State University http://verma.sfsu.edu/ http://cbs.sfsu.edu/ http://is.sfsu.edu/ ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Ejabberd CPU/RAM Spike - Crashes
On Sat, Dec 19, 2009 at 1:31 PM, Devon Connolly dev...@gmail.com wrote: Beam is still consuming 100% of the cpu after a few minutes. I'm going to leave that script running to see what it does over the next few hours. That's really abnormal. - Is there any disk anomaly? (Reboot forcing a fsck?) - Is there any problem in the binaries? If you run rpm with the 'verify' options, it'll check that no binaries have been corrupted on-disk... It's normal to see some config files changed, but no binaries should be different from the rpms. I imagine I now have to re-register all XO's? Nope. The DB gets rebuilt automagically for you, 100%, on XS-0.6 . cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
