Ejabberd 正在使用所有可用的 CPU，如何调试
Ejabberd is using all available CPU, how to debug
我的 ejabberd 安装有问题，我正在努力弄清楚发生了什么。
几分钟（15-20 分钟）后，我的 CPU 使用率飙升至 100%。我找不到明显的原因。从那以后，它一直保持完整 CPU。我已尝试升级服务器的硬件，但仍然无法让它处理负载。该服务器是一个非常现代的服务器，具有 Xeon 进程 KVM 虚拟化。 8 核和 32GB RAM，无其他工作负载。
我已经尝试 运行 etop 但它不起作用：
root@collaboration:/# ./usr/lib/erlang/lib/observer-2.9.4/priv/bin/etop -node ejabberd@localhost
Erlang/OTP 23 [erts-11.0.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1]
Eshell V11.0.3 (abort with ^G)
(etop@collaboration)1> {"init terminating in do_boot",{{badmatch,{error,nxdomain}},[{etop_tr,reader,1,[{file,"etop_tr.erl"},{line,62}]},{etop,init_data_handler,1,[{file,"etop.erl"},{line,146}]},{etop,start,1,[{file,"etop.erl"},{line,129}]},{init,start_em,1,[]},{init,do_boot,3,[]}]}}
init terminating in do_boot ({{badmatch,{error,nxdomain}},[{etop_tr,reader,1,[{},{}]},{etop,init_data_handler,1,[{},{}]},{etop,start,1,[{},{}]},{init,start_em,1,[]},{init,do_boot,3,[]}]})
Crash dump is being written to: erl_crash.dump...done
我的错误日志中有很多内容奇怪的条目。我怀疑我的数据库基本上不处于健康状态。数据库已有 10 年历史，进行了多次升级，因此出现问题的可能性很高。可在此处下载 error.log：https://fil.email/u1U0Y1wu
Pastebin extracts from error.log: https://pastebin.com/umpf51aU
最近我升级到 ejabberd 20.07，我尝试应用所有 MySQL 模式更新等。这不能像我希望的那样工作，因为日志中有问题的痕迹。这个至少失败了：https://docs.ejabberd.im/admin/upgrade/from_19.05_to_19.08/
root@:~# mysql -u ejabberd ejabberd -p << EOF
ALTER TABLE users MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE last MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE rosterusers MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE rostergroups MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE sr_group MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE sr_user MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE spool MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE archive MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE archive_prefs MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE vcard MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE vcard_search MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE privacy_default_list MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE privacy_list MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE private_storage MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE roster_version MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE muc_room MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE muc_registered MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE muc_online_room MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE muc_online_users MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE motd MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE sm MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE route MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE push_session MODIFY server_host varchar(191) NOT NULL;
ALTER TABLE mix_pam MODIFY server_host varchar(191) NOT NULL;
EOF
Enter password:
ERROR 1054 (42S22) at line 1: Unknown column 'server_host' in 'users'
由于我不太明白为什么我们会遇到所有 CPU 问题，所以我正在考虑删除数据库并在新安装的服务器上导入备份。我将如何导出尽可能多的健康数据并将其导入到新数据库中？最好至少导出具有密码和名册的用户。没有 MUC 房间或类似房间。如果可能的话，应该迁移 SSL 证书 (ACME)，因为 letsencrypt 对一直请求新证书不太满意。如果您对此问题有任何类型的指导，我将非常高兴！
仅供参考，上面的日志和负载我有 155 个在线用户，12500 个注册用户。
来自您的日志：
exception exit: {undef,
[{xmpp_stream_out,stop_async,[<0.4108.0>],[]},
这里erlang报告有一个未定义的函数（未在源代码中定义）。
查看源代码，该函数是在 xmpp 1.4.6 中定义的：
https://github.com/processone/xmpp/commit/c23e66ebac8fdec4aa08c8926091b0dcf6dacf22
并且它的用法在ejabberd 20.04中被添加到ejabberd中
https://github.com/processone/ejabberd/commit/1bd560f3f25d0a644bac3d06904ca97e20a6f7d9
所以，最初看起来你好像是 运行 ejabberd 20.04 或更新版本，但使用的是 xmpp早于 1.4.6
的库
根据@Badlop 的回复，问题已通过安装新的 erlang-p1-xmpp 解决。出于某种原因，apt 存在依赖性问题，认为安装的软件包比不稳定存储库中的软件包更新。
root@collaboration:~/download# dpkg -i
erlang-p1-xmpp_1.4.9-1_amd64.deb dpkg: warning: downgrading
erlang-p1-xmpp from 1:1.2.8-0.1~afa100 to 1.4.9-1 (Reading database
... 105425 files and directories currently installed.) Preparing to
unpack erlang-p1-xmpp_1.4.9-1_amd64.deb ... Unpacking erlang-p1-xmpp
(1.4.9-1) over (1:1.2.8-0.1~afa100) ... Setting up erlang-p1-xmpp
(1.4.9-1) ...
我会看看是否可以为 debian 中的代表制作一个错误报告来解决这个问题。
我的 ejabberd 安装有问题，我正在努力弄清楚发生了什么。
几分钟（15-20 分钟）后，我的 CPU 使用率飙升至 100%。我找不到明显的原因。从那以后，它一直保持完整 CPU。我已尝试升级服务器的硬件，但仍然无法让它处理负载。该服务器是一个非常现代的服务器，具有 Xeon 进程 KVM 虚拟化。 8 核和 32GB RAM，无其他工作负载。
我已经尝试 运行 etop 但它不起作用：
root@collaboration:/# ./usr/lib/erlang/lib/observer-2.9.4/priv/bin/etop -node ejabberd@localhost Erlang/OTP 23 [erts-11.0.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1]
Eshell V11.0.3 (abort with ^G) (etop@collaboration)1> {"init terminating in do_boot",{{badmatch,{error,nxdomain}},[{etop_tr,reader,1,[{file,"etop_tr.erl"},{line,62}]},{etop,init_data_handler,1,[{file,"etop.erl"},{line,146}]},{etop,start,1,[{file,"etop.erl"},{line,129}]},{init,start_em,1,[]},{init,do_boot,3,[]}]}} init terminating in do_boot ({{badmatch,{error,nxdomain}},[{etop_tr,reader,1,[{},{}]},{etop,init_data_handler,1,[{},{}]},{etop,start,1,[{},{}]},{init,start_em,1,[]},{init,do_boot,3,[]}]})
Crash dump is being written to: erl_crash.dump...done
我的错误日志中有很多内容奇怪的条目。我怀疑我的数据库基本上不处于健康状态。数据库已有 10 年历史，进行了多次升级，因此出现问题的可能性很高。可在此处下载 error.log：https://fil.email/u1U0Y1wu
Pastebin extracts from error.log: https://pastebin.com/umpf51aU
最近我升级到 ejabberd 20.07，我尝试应用所有 MySQL 模式更新等。这不能像我希望的那样工作，因为日志中有问题的痕迹。这个至少失败了：https://docs.ejabberd.im/admin/upgrade/from_19.05_to_19.08/
root@:~# mysql -u ejabberd ejabberd -p << EOF
ALTER TABLE users MODIFY server_host varchar(191) NOT NULL; ALTER TABLE last MODIFY server_host varchar(191) NOT NULL; ALTER TABLE rosterusers MODIFY server_host varchar(191) NOT NULL; ALTER TABLE rostergroups MODIFY server_host varchar(191) NOT NULL; ALTER TABLE sr_group MODIFY server_host varchar(191) NOT NULL; ALTER TABLE sr_user MODIFY server_host varchar(191) NOT NULL; ALTER TABLE spool MODIFY server_host varchar(191) NOT NULL; ALTER TABLE archive MODIFY server_host varchar(191) NOT NULL; ALTER TABLE archive_prefs MODIFY server_host varchar(191) NOT NULL; ALTER TABLE vcard MODIFY server_host varchar(191) NOT NULL; ALTER TABLE vcard_search MODIFY server_host varchar(191) NOT NULL; ALTER TABLE privacy_default_list MODIFY server_host varchar(191) NOT NULL; ALTER TABLE privacy_list MODIFY server_host varchar(191) NOT NULL; ALTER TABLE private_storage MODIFY server_host varchar(191) NOT NULL; ALTER TABLE roster_version MODIFY server_host varchar(191) NOT NULL; ALTER TABLE muc_room MODIFY server_host varchar(191) NOT NULL; ALTER TABLE muc_registered MODIFY server_host varchar(191) NOT NULL; ALTER TABLE muc_online_room MODIFY server_host varchar(191) NOT NULL; ALTER TABLE muc_online_users MODIFY server_host varchar(191) NOT NULL; ALTER TABLE motd MODIFY server_host varchar(191) NOT NULL; ALTER TABLE sm MODIFY server_host varchar(191) NOT NULL; ALTER TABLE route MODIFY server_host varchar(191) NOT NULL; ALTER TABLE push_session MODIFY server_host varchar(191) NOT NULL; ALTER TABLE mix_pam MODIFY server_host varchar(191) NOT NULL; EOF Enter password: ERROR 1054 (42S22) at line 1: Unknown column 'server_host' in 'users'
由于我不太明白为什么我们会遇到所有 CPU 问题，所以我正在考虑删除数据库并在新安装的服务器上导入备份。我将如何导出尽可能多的健康数据并将其导入到新数据库中？最好至少导出具有密码和名册的用户。没有 MUC 房间或类似房间。如果可能的话，应该迁移 SSL 证书 (ACME)，因为 letsencrypt 对一直请求新证书不太满意。如果您对此问题有任何类型的指导，我将非常高兴！
仅供参考，上面的日志和负载我有 155 个在线用户，12500 个注册用户。
来自您的日志：
exception exit: {undef,
[{xmpp_stream_out,stop_async,[<0.4108.0>],[]},
这里erlang报告有一个未定义的函数（未在源代码中定义）。
查看源代码，该函数是在 xmpp 1.4.6 中定义的： https://github.com/processone/xmpp/commit/c23e66ebac8fdec4aa08c8926091b0dcf6dacf22
并且它的用法在ejabberd 20.04中被添加到ejabberd中 https://github.com/processone/ejabberd/commit/1bd560f3f25d0a644bac3d06904ca97e20a6f7d9
所以，最初看起来你好像是 运行 ejabberd 20.04 或更新版本，但使用的是 xmpp早于 1.4.6
的库根据@Badlop 的回复，问题已通过安装新的 erlang-p1-xmpp 解决。出于某种原因，apt 存在依赖性问题，认为安装的软件包比不稳定存储库中的软件包更新。
root@collaboration:~/download# dpkg -i erlang-p1-xmpp_1.4.9-1_amd64.deb dpkg: warning: downgrading erlang-p1-xmpp from 1:1.2.8-0.1~afa100 to 1.4.9-1 (Reading database ... 105425 files and directories currently installed.) Preparing to unpack erlang-p1-xmpp_1.4.9-1_amd64.deb ... Unpacking erlang-p1-xmpp (1.4.9-1) over (1:1.2.8-0.1~afa100) ... Setting up erlang-p1-xmpp (1.4.9-1) ...
我会看看是否可以为 debian 中的代表制作一个错误报告来解决这个问题。