Ejabberd: How to clean up caps_features

[licaon-kter]

Environment

• ejabberd version: 20.03.xx
• Erlang version: 10.2.4
• OS: Debian Buster arm64
• Installed from: source

Jitsi Meet has the bad habit of creating and destroying a room every 10 seconds which is annoying for the logs but whatever.

Now, I'm looking at my DB size and it just balooned:

ejabberd=# \dt+
                               List of relations
 Schema |      Name     | Type  |  Owner   |    Size    |
--------+---------------+-------+----------+------------+
 public | archive       | table | ejabberd | 97 MB      | 
 public | caps_features | table | ejabberd | 219 MB     | 

...with ejabberd/db going crazy, as every 10 seconds a new entry is added:

http://www.process-one.net/en/ejabberd/ HPfX98vYid8OeIH43MWXhi0+aVw=    vcard-temp      2020-04-14 00:55:54.142218
http://www.process-one.net/en/ejabberd/ HPfX98vYid8OeIH43MWXhi0+aVw=    http://jabber.org/protocol/muc  2020-04-14 00:55:54.142218
http://www.process-one.net/en/ejabberd/ HPfX98vYid8OeIH43MWXhi0+aVw=    http://jabber.org/protocol/disco#info   2020-04-14 00:55:54.142218
http://www.process-one.net/en/ejabberd/ HPfX98vYid8OeIH43MWXhi0+aVw=    http://jabber.org/protocol/disco#items  2020-04-14 00:55:54.142218
http://www.process-one.net/en/ejabberd/ HPfX98vYid8OeIH43MWXhi0+aVw=    muc_public      2020-04-14 00:55:54.142218
http://www.process-one.net/en/ejabberd/ HPfX98vYid8OeIH43MWXhi0+aVw=    muc_temporary   2020-04-14 00:55:54.142218
http://www.process-one.net/en/ejabberd/ HPfX98vYid8OeIH43MWXhi0+aVw=    muc_open        2020-04-14 00:55:54.142218
http://www.process-one.net/en/ejabberd/ HPfX98vYid8OeIH43MWXhi0+aVw=    muc_semianonymous       2020-04-14 00:55:54.142218
http://www.process-one.net/en/ejabberd/ HPfX98vYid8OeIH43MWXhi0+aVw=    muc_moderated   2020-04-14 00:55:54.142218
http://www.process-one.net/en/ejabberd/ HPfX98vYid8OeIH43MWXhi0+aVw=    muc_unsecured   2020-04-14 00:55:54.142218

I'm looking at https://docs.ejabberd.im/admin/configuration/modules/#mod-caps to try to clean this up.

All those cache options are used for what exactly? I see caps from 2018 in the DB, when/how is this table cleaned up?

/PS: I guess I can just clean up the table in the DB, but _"The plugin that implements PEP (XEP-0163: Personal Eventing via Pubsub) is enabled in the default ejabberd configuration file, and it requires mod_caps."_ so I'm not sure what side effects that would have.

/LE: so maybe I've dreamed of a command then

[vanitasvitae]

I can confirm that jitsi meet trashes my ejabberd database. I just deleted 1.6m caps entries from the database manually through mariadb.

Unrelated, but also an issue with jitsi meet is that it also creates lots of muc rooms as well, so you should check those tables as well.

[licaon-kter]

PostgreSQL:

ejabberd=# DELETE FROM caps_features WHERE node='http://www.process-one.net/en/ejabberd/';
DELETE 1926812

...hope nothing broke :)

/LE: Also don't forget to VACUUM (FULL, ANALYZE) caps_features; after that. _(or whatever the equivalent for your DB of choice)_
And of course, add the cleanup process to cron, because you'll get ~80k new entries daily.

[vanitasvitae]

I wonder why prosody doesn't seem to suffer from this. Do they delete/not persist MUC caps entries?

[prefiks]

Hello,
It seems that we have separate entry for each room because we include room description in disco info reply (and that means that each room will have different caps hash). I am checking if we really are using those muc responses anywhere, and see if we can skip those.

[weiss]

I guess the question is which clients make use of that. I remember us adding us various things to caps due to client developer requests over the past 1–2 years ...

[licaon-kter]

The health check logs look like this:

10:17:53.588 [info] <0.2428.2>@mod_muc_room:init:281 Created MUC room org.jitsi.jicofo.health.[email protected] by [email protected]/focus259924058684616
10:18:03.497 [info] <0.2425.2>@mod_muc_room:close_room_if_temporary_and_empty:1320 Destroyed MUC room org.jitsi.jicofo.health.[email protected] because it's temporary and empty
10:18:03.504 [info] <0.2425.2>@mod_muc_room:terminate:874 Stopping MUC room org.jitsi.jicofo.health.[email protected]

So, a room is temporary, empty and then destroyed, are caps still needed?

[prefiks]

I disabled storing room caps info in commit 6320dfd34ead314f08856e1a8279ed4e14cc7649.

I don't think this should broke clients, we still should send same information to clients, caps cache i believe is only used internally (i think mostly to determine what pep/pubsub should send, but i don't think it should matter in this case), and having/not having entry in it doesn't change what we sent to clients.

[licaon-kter]

@prefiks my OP question stays unanswered, what's up with the cache options? They default to 1h as the docs say? If so why weren't they cleaned up? Or did I misunderstood that?

[weiss]

I disabled storing room caps info in commit 6320dfd.

I don't think this should broke clients, we still should send same information to clients, caps cache i believe is only used internally (i think mostly to determine what pep/pubsub should send, but i don't think it should matter in this case), and having/not having entry in it doesn't change what we sent to clients.

Ah, indeed. Thanks!

[prefiks]

@licaon-kter This is for in memory cache (so instead of reading entries from disk on each access, we can do cheaper lookup from just memory).

[licaon-kter]

@prefiks For Mnesia, with your fix, how do I clean them up?

[badlop]

@licaon-kter For Mnesia, with your fix, how do I clean them up?

If the question is "how to clean the caps_features mnesia table", the answer is simple: in ejabberd's Web Admin -> Nodes -> your node -> Database -> caps_features -> Delete content -> Submit

[Neustradamus]

@badlop: There is not a command line too?

[badlop]

@badlop: There is not a command line too?

ejabberdctl modules_update_specs
ejabberdctl module_install mod_shcommands
ejabberdctl execute_erlang "mnesia:clear_table(caps_features)."