[ejabberd] mod_muc_odbc performance/memory issues with room with massive set of affiliations

Michael Amundson 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 
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!


More information about the ejabberd mailing list