1 votes

Serveur Linux ne permettant pas plus de 2048 connexions simultanées

J'ai essayé de faire un test de charge sur MQTT à partir de mon MACOS, et j'ai réussi à atteindre plus de 12k connexions jusqu'à ce que ma bande passante soit épuisée.

J'ai essayé de faire le même test sur la machine GCP et j'ai obtenu une exception de dépassement de délai de connexion une fois que les ports ouverts ont atteint 2048, et 2048 connexions avec le courtier MQTT.

Lors de la connexion, mon ConnectionTimeout est de 100s (attente de la conack) et KeepAlive = 300s (une fois la connexion établie).

Ce problème se produit quel que soit le logiciel de test de charge, c'est-à-dire mzbench, jmeter et emqtt-bench. Je pense donc que ce problème est lié au serveur linux.

Je ne cherche pas à atteindre 1 million de connexions ouvertes, mais au moins 30 000 connexions ouvertes.

J'ai déjà essayé de modifier l'ulimit et voici mes configurations d'ulimit

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63887
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 102400
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 200000
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

cat on proc donne également le nombre maximum de fichiers ouverts à 102400

Ce sont également les valeurs définies dans mon sysctl

fs.file-max = 200000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_mem = 50576   64768   98152
net.core.netdev_max_backlog = 2500

Edit : Ajout des détails de la machine et de la mire

Type de machine : n2-highcpu-16 (16 vCPUs, 16 GB de mémoire)

Résultat de lscpu

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                16
On-line CPU(s) list:   0-15
Thread(s) per core:    2
Core(s) per socket:    8
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 85
Model name:            Intel(R) Xeon(R) CPU
Stepping:              7
CPU MHz:               2800.200
BogoMIPS:              5600.40
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              1024K
L3 cache:              33792K
NUMA node0 CPU(s):     0-15
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat avx512_vnni md_clear arch_capabilities

Modèle de test : Ouverture de 200 connexions par seconde et attente de conack à un rythme constant.

1voto

Dhruv Sehgal Points 121

J'ai pu résoudre ce problème grâce aux commentaires ci-dessus.

J'ai touché l'IP publique du LoadBalancer à partir de ma VM de test. Cependant, GCP limite à 2048 le nombre de connexions d'une VM à l'IP publique. Une fois que j'ai changé cela en IP privée, j'ai pu atteindre près de 65k connexions.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X