linux - tutorial - ¿Cómo escalar el servidor ejabberd en CentOS para manejar conexiones de 200 K?

instalar ejabberd

Question

Estoy trabajando en una instancia de ejabberd considerablemente buena con 40 CPU de núcleo y 160 GB de RAM.

El problema es que no puedo escalar hasta 200 K conexiones paralelas.

La configuración de sysctl es la siguiente:

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

Las entradas del archivo /etc/security/limits.conf son las siguientes:

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

La máquina comienza a perder conexiones cuando el servidor alcanza alrededor de 112 K.

Cosas que suceden alrededor de 112 K

1. El uso de la CPU sube a 200 ~ 300% (pero es el pico habitual)

Información general: cuando todo es normal, el uso de la CPU se dispara hasta un 80% como se ve a continuación (solo dos CPU están trabajando realmente)

2. No puedo trabajar en la máquina. Estoy usando comandos top y ss para ver qué está pasando en el servidor. La máquina simplemente deja de responder en este punto y las conexiones comienzan a disminuir.

Lo que es una gracia salvadora es que las conexiones no caen abruptamente, sino que caen a la velocidad a la que están conectadas.

Estoy usando TSUNG para generar la carga. Hay 4 cajas de generador de carga que golpean 4 ips diferentes mapeados a una sola máquina internamente.

Cualquier sugerencia, opinión es bienvenida.

Answer 1

Como primera llamada, necesitaría establecer cuál es el cuello de botella en su caso:

• UPC
• Memoria
• Límites del sistema (enchufes abiertos, archivos abiertos)
• Arquitectura de aplicaciones

Si es posible, agregue una aplicación de seguimiento de recursos a su nodo, por ejemplo, recon . Le permitirá verificar la longitud de las colas de procesos, la fragmentación de memoria, etc. En nuestro sistema de producción, la cantidad de memoria consumida por Erlang VM fue diferente cuando el sistema la informó, en comparación con la misma máquina virtual de Erlang debido a las páginas enormes transparentes ( el sistema fue virtualizado). Puede haber otros problemas que pueden no ser obvios al inspeccionar el nodo utilizando las herramientas del sistema.

Entonces yo propondría:

1. Determine los procesos con los tamaños de cola más largos: serán responsables de desacelerar el sistema porque Erlang VM necesita escanear toda la bandeja de entrada de un proceso cuando recibe un mensaje.

2. Determine los procesos con la mayor cantidad de memoria asignada

3. Determine la cantidad de memoria que Erlang piensa que está asignada

Además, sería bueno si agregó los parámetros utilizados para iniciar la máquina virtual de Erlang.

Adición

Se olvidó de mencionar que puede valer la pena ver la sintonía que WhatsApp hizo a sus nodos Erlang para manejar cientos de miles de conexiones simultáneas:

El Facebook de WhatsApp Architecture comprado por $ 19 mil millones