[erlang-questions] How to deal with Mnesia core files

[Brian Acton]

Thanks guys. The mention of mnesia_lib:vcore/1 was a good one that I had not
yet found.

Overall, my expectation would be that I would not have to govern mnesia for
load (as Paul M recommends in his prior post to this thread). The reason is
that the range of activity in some applications can be quite dynamic and it
would be hard to identify one key characteristic that would cause mnesia to
tip over. Instead, my expectation would be that mnesia would return service
failures akin to the EBUSY / EAGAIN errno of unix kernels, thus allowing
applications to decide on what to do.

For completeness sake, I've included the top part of the output from
mnesia_lib:vcore/1 in case anyone is curious.

--b

***** Mnesia core: "MnesiaCore.node@REDACTED"

*****
***** crashinfo *****
mnesia_recover crashed: {system_limit,
                            [{ets,new,
                                 [mnesia_transient_decision,
                                  [{keypos,2},set,public]]},
                             {mnesia_recover,create_transient_decision,0},
                             {mnesia_recover,do_allow_garb,0},
                             {mnesia_recover,handle_cast,2},
                             {gen_server,handle_msg,5},
                             {proc_lib,init_p_do_apply,3}]} state: {state,

<6403.61.0>,

undefined,

undefined,

undefined,

7262,true,
                                                                    []}
***** time *****
{{2010,3,1},{0,54,54}}
***** self *****
[{registered_name,mnesia_recover},
 {current_function,{mnesia_lib,mkcore,1}},
 {initial_call,{proc_lib,init_p,5}},
 {status,running},
 {message_queue_len,0},
 {messages,[]},
 {links,[<6403.95.0>,<6403.61.0>]},
 {dictionary,[{'$ancestors',[mnesia_kernel_sup,mnesia_sup,<6403.58.0>]},
              {'$initial_call',{mnesia_recover,init,1}}]},
 {trap_exit,true},
 {error_handler,error_handler},
 {priority,normal},
 {group_leader,<6403.57.0>},
 {total_heap_size,2675793},
 {heap_size,2629425},
 {stack_size,39},
 {reductions,247240},
 {garbage_collection,[{min_bin_vheap_size,46368},
                      {min_heap_size,233},
                      {fullsweep_after,65535},
                      {minor_gcs,4}]},
 {suspending,[]}]


On Mon, Mar 1, 2010 at 9:33 PM, Chandru <
chandrashekhar.mullaparthi@REDACTED> wrote:

> Hi Brian,
>
> On 2 March 2010 03:33, Brian Acton <acton@REDACTED> wrote:
> > Hi guys,
> >
> > I'm running R13B04 on FreeBSD 7.3-Current and I've been doing some load
> and
> > performance testing. During times of heavy load, Mnesia starts getting
> > stressed and I start seeing messages in the logs like this:
> >
> >  ** WARNING ** Mnesia is overloaded: {dump_log,   write_threshold}
>
> Mnesia uses a few log files to record changes to the tables as it goes
> along, and periodically dumps the entire table to disk. You can tweak
> this behaviour using the two mnesia parameters:
> dump_log_write_threshold
> dump_log_time_threshold
>
> >
> > After a while, Mnesia starts getting more stressed and I see this error
> > message:
> >
> > ** Too many db tables **
>
> Mnesia uses temporary ets tables for transactions. A new ets table is
> created during the execution and deleted when the transaction
> finishes. If you have too many transactions starting, it will hit the
> default ETS table limit of 1400. See
> http://erlang.org/doc/efficiency_guide/advanced.html#id2266338
>
> >
> > And then mnesia basically barfs and leaves a file like:
> >
> > MnesiaCore.node@REDACTED
> >
> > I completely understand that software under heavy load may decide to exit
> > but I am a little surprised that the process dumps core. Is this by
> design
> > or this unintentional? More importantly, is there any means of
> interpreting
> > the core files using some debug tool? If so, any tips on the magic
> commands
> > to make that happen?
>
> You can use mnesia_lib:vcore/1 to view the mnesia core file.
>
> cheers
> Chandru
>