如何在 CentOS 上扩展 ejabberd 服务器机器以处理 200 K 连接？

Posted 2023-03-15

【中文标题】如何在 CentOS 上扩展 ejabberd 服务器机器以处理 200 K 连接？

【英文标题】：How to scale ejabberd Server machine on CentOS to handle 200 K connections?

【发布时间】：2016-07-11 02:53:38

【问题描述】：

我正在开发一个相当不错的 ejabberd 实例，它有 40 核 CPU 机器和 160 GB RAM。

问题是我无法扩展到 200 K 并行连接。

sysctl 配置如下：

net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 16384 16777216
#http://linux-ip.net/html/ether-arp.html#ether-arp-flux
net.ipv4.conf.all.arp_filter = 1
kernel.exec-shield=1
kernel.randomize_va_space=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.conf.all.accept_source_route=0
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.secure_redirects = 0
net.ipv4.ip_local_port_range = 12000    65535
fs.nr_open = 20000500


fs.file-max = 1000000
net.ipv4.tcp_max_syn_backlog = 10240
net.ipv4.tcp_max_tw_buckets = 400000
net.ipv4.tcp_max_orphans = 60000

net.ipv4.tcp_synack_retries = 3

net.core.somaxconn = 10000

/etc/security/limits.conf 文件条目如下：

*               soft    core            900000
*               hard    rss             900000
*               soft    nofile          900000
*               hard    nofile          900000
*               soft    nproc           900000
*               hard    nproc           900000

当服务器达到大约 112 K 时，机器开始失去连接。

发生在 112 K 左右的事情

CPU 使用率高达 200 ~ 300 %（但这是通常的峰值）

背景 - 当一切正常时，CPU 使用率会飙升至 80%，如下图所示（只有两个 CPU 正在做实际工作）

我无法在机器上工作。我正在使用 top 和 ss 命令来查看服务器上发生了什么。机器此时停止响应，连接开始断开。

一个可取之处在于连接不会突然断开，而是以它们连接的速率断开。

我正在使用 TSUNG 来生成负载。有 4 个负载生成器盒访问 4 个不同的 ip，内部仅映射到一台机器。

非常欢迎任何建议，意见。

【问题讨论】：

@Amiramix：我现在能够达到 200 K 以上。涉及一些更改，将机器更改为 8 核并确保前 4 核处理网络中断。

【参考方案1】：

作为第一个电话，您需要确定您的案例中的瓶颈是什么：

CPU 内存 系统限制（打开的套接字、打开的文件） 应用架构

如果可能，将资源跟踪应用程序添加到您的节点，例如recon。它将允许您检查进程队列的长度、内存碎片等。在我们的生产系统中，由于透明大页面（Transparent Huge Pages），系统报告的 Erlang VM 消耗的内存量与 Erlang VM 本身报告的内存量不同（系统已虚拟化）。使用系统工具检查节点时可能存在其他不明显的问题。

所以我建议：

确定具有最长队列大小的进程 - 它们将导致系统变慢，因为 Erlang VM 在收到消息时需要扫描进程的整个收件箱

确定分配内存最大的进程

确定 Erlang 自己认为分配了多少内存

另外，如果您添加用于启动 Erlang VM 的参数会很好。

加法

忘了提一下，WhatsApp 对其 Erlang 节点进行的调整以处理数十万个同时连接可能值得一看：

The WhatsApp Architecture Facebook Bought For $19 Billion