[ejabberd] mod_muc_odbc performance/memory issues with room with massive set of affiliations
xramtsov at gmail.com
Sat Nov 17 14:26:15 MSK 2012
On 17.11.2012 14:57, Michael Amundson wrote:
> Hi again, and apologies for all these ODBC-related questions I keep
> I have a MUC with a rather large number of affiliations associated
> with it (around 95,000).
95k affiliations in a single room?
> While migrating to mod_muc_odbc, I've noticed that adding new
> affiliations to this MUC take around 12 to 15 seconds to complete,
> during which the CPU is spinning at nearly 100%. Additionally, RAM
> usage increases by around 200MB for each new affiliation added and
> doesn't seem to go back down. Looking at Postgres' log, it appears the
> actual update query for the MUC entry in the muc_rooms table only
> takes about 140ms to execute, so I'm inclined to think the slowdown
> isn't database related as much as it's related to some inefficient
> code path in mod_muc_odbc.
> While I'm planning on changing how my system works such that no MUC
> room winds up with such a large number of affiliations, I'm curious
> what on earth ejabberd is doing and whether it can be improved to
> avoid the above problem. I'm also curious whether mod_muc_odbc might
> be modified to split affiliation data into rows in a separate table,
> as it seems like a better idea than to constantly serialize and
> deserialize the affiliations as part of the opts column.
> Any insight is greatly appreciated!
You can provide your sql data (select * from muc_room where
blah-blah-blah), I'll load it into my db and will check the bottle-neck.
Evgeniy Khramtsov, ProcessOne.
xmpp:xram at jabber.ru.
More information about the ejabberd