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

Evgeniy Khramtsov 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 
> raising.
>
> 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.

-- 
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram at jabber.ru.



More information about the ejabberd mailing list