[ejabberd] mod_muc_odbc performance/memory issues with room with massive set of affiliations
michael at echobit.com
Sat Nov 17 08:57:46 MSK 2012
Hi again, and apologies for all these ODBC-related questions I keep raising.
I have a MUC with a rather large number of affiliations associated with
it (around 95,000). 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
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!
More information about the ejabberd