[ejabberd] Performances issues with ejabberd+LDAP+PostgreSQL

pitchum pitchum at gramaton.org
Mon May 13 14:06:24 MSK 2019

Hello Holger, thanks for answering.

Le 13/05/2019 à 11:40, Holger Weiß a écrit :
> * pitchum <pitchum at gramaton.org> [2019-05-13 10:06]:
>> Le 10/05/2019 à 11:58, pitchum a écrit :
>>> my ejabberd 18.12 from Debian stretch-backports server has performances
>>> issues since yesterday, when the amount of connected users went from 10
>>> to 250+
>> I've reverted to "default_db=mnesia" and only mod_mam has db_type=sql.
>> The VM now has 8 VCPUs and it's not enough. All CPUs reached 100% load.

> I'd assume some issue with your I/O
> performance and/or something triggering heavy load on the database.

I forgot to mention that all CPU load was on process beam.smp *only*.
PostgreSQL was not loaded at all and our metrology shows that the
maximum IO writes was 65kBs when the first load peak was observed.
No IOWait.

> As a start, I'd suggest switching everything back to PostgreSQL and
> tuning the SQL performance (PostgreSQL's default settings are very
> conservative);

Our Postgresql was already tuned to meet our needs: in particular 2GB
RAM are dedicated to PostgreSQL.
For now I'm pretty sure it does not need more tuning.

Currently, all 8 VCPUs are 100% loaded on beam.smp (still with

ejabberd's logs suggest that the problem is either with mod_pubsub,
mod_shared_roster_ldap or both.
Our LDAP server is not loaded at all and answers to ejabberd queries
very quickly. So LDAP is probably not the bottleneck.

Many clues make me think that the bottleneck is in
mod_shared_roster_ldap but I don't know yet how to debug. In particular
I would like to be able to view the content of the cache.
Can you tell me how to do that?


More information about the ejabberd mailing list