[ejabberd] ejabberd leaking and crashing
skupko.sk at gmail.com
Fri Dec 11 12:45:49 MSK 2009
> 1. moved roster and roster_version to disc_only_copies
That is fine.
2. moved last_activity to disc_only_copies but quickly moved it back because
> IO activity went through the roof (our users disconnect and connect 10-20
> times a day)
That was not good idea. There are a lot of changes in last_activity and it
should remain in memory.
1. is 600K the max number of registered users ejabberd can handle on an 8GB
> ram when roster is enabled?
It depends on how many users are still active and how many active concurrent
sessions are on your server.
> 2. ejabberd is now running fine and taking under 2G of memory, but as
> roster regenerates itself, will we have this problem again and how do we
> avoid it?
I do not think that roster is the most problematic module. But of course
within user log on user's roster must be transferred to his new session and
thus selected from the roster mnesia table.
> 3. why did we get those 'resend_subscription_requests_hook' errors after we
> did "mnesia:change_table_copy_type(roster, node(), disc_only_copies)."?
I do not know. But we have this table set with disc_only_copies option and
it is working well for us.
This could probably help you:
I remember that I was playing with the copies option on mnesia tables and
ejabberd was not able to run within some tables set to
disk_only_copies/ram_copies - but not sure which tables.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ejabberd