了解Ejabberd生成的Erlang崩溃日志

了解Ejabberd生成的Erlang崩溃日志,erlang,ejabberd,Erlang,Ejabberd,我无法理解Erlang崩溃和重新启动的原因。我正在运行Ejabberd服务器,它的日志文件夹总是充满了erl_crash_xxxx.dump文件。如何调试此问题 下面是erlang.log文件的一小部分: =CRASH REPORT==== 4-Sep-2013::19:44:51 === crasher: initial call: ejabberd_http:init/2 pid: <0.15614.15> registered_name: []

我无法理解Erlang崩溃和重新启动的原因。我正在运行Ejabberd服务器,它的日志文件夹总是充满了erl_crash_xxxx.dump文件。如何调试此问题

下面是erlang.log文件的一小部分:

=CRASH REPORT==== 4-Sep-2013::19:44:51 ===
  crasher:
    initial call: ejabberd_http:init/2
    pid: <0.15614.15>
    registered_name: []
    exception exit: {normal,
                        {gen_fsm,sync_send_all_state_event,
                            [<0.15454.15>,
                             {http_put,2020093061,
                                 [{"xmlns",
                                   "http://jabber.org/protocol/httpbind"},
                                  {"rid","2020093061"},
                                  {"sid",
                                   "26820e4cd7d331de864b857d1ef3351caf7dbac5"}],
                                 [],115,1,[],
                                 {{49,205,148,16},56132}},
                             30000]}}
      in function  gen_fsm:sync_send_all_state_event/3
      in call from ejabberd_http_bind:http_put/7
      in call from ejabberd_http_bind:handle_http_put/7
      in call from ejabberd_http:process/2
      in call from ejabberd_http:process_request/1
      in call from ejabberd_http:process_header/2
      in call from ejabberd_http:receive_headers/1
    ancestors: [ejabberd_http_sup,ejabberd_sup,<0.37.0>]
    messages: []
    links: [<0.274.0>,#Port<0.1519795>]
    dictionary: []
    trap_exit: false
    status: running
    heap_size: 2584
    stack_size: 24
    reductions: 1082
  neighbours:

这些“崩溃”可能完全无关。您在日志文件中看到的“=CRASH REPORT=”属于“正常”或预期的崩溃,因此由主管处理。您发布的消息是,在创建或发送响应时,HTTP调用处理程序内部发生崩溃,该响应可能会以某种不可预见的情况结束(例如,当发送进程不再存在时,但对此不确定)。Erlang的构建和设计可以优雅地处理此类崩溃。换句话说,您的ejabberd仍在运行并愉快地为请求提供服务


另一个是由Erlang运行时的实际崩溃导致的崩溃转储。例如,如果托管运行时的计算机内存不足,可能会发生这种情况。在您的情况下,这似乎是一个配置错误,节点根本无法正确引导。我想向其他人解释如何解释一个崩溃转储——考虑遵循指南并用一个有用的堆栈跟踪来改进你的问题,但是即使SECKD崩溃也会一直保持EJABBER节点。只是日志目录中有很多崩溃转储文件,它一直在工作。我还看到ejabberd beam消耗了非常高的CU。这些崩溃文件很可能是由ejabberd试图启动的其他实例创建的。你知道,为什么会发生这种情况吗?我没有手动启动另一个实例,并且有很多崩溃转储文件,并且随着ejabberd的运行时间,此类文件的数量不断增加。
=erl_crash_dump:0.1
Tue Sep  3 16:31:47 2013
Slogan: Kernel pid terminated (application_controller) ({application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}})
System version: Erlang R14B04 (erts-5.8.5) [source] [64-bit] [rq:1] [async-threads:0] [hipe] [kernel-poll:false]
Compiled: Wed Oct  5 17:25:18 2011
Taints:
Atoms: 4699
=memory
total: 21498768
processes: 556368
processes_used: 541208
system: 20942400
atom: 322177
atom_used: 302233
binary: 18216
code: 2165726
ets: 53736
=hash_table:atom_tab
size: 3203
used: 2471