Linux optimalizálás másodpercenként 1.2 millió JSON-kérés kezelésére

Részletes útmutatót tettek közzé a Linux-környezet hangolásáról a HTTP-kérések feldolgozásának maximális teljesítménye érdekében. A javasolt módszerek lehetővé tették a libreactor könyvtáron alapuló JSON processzor teljesítményének növelését az Amazon EC2 környezetben (4 vCPU) a másodpercenkénti 224 ezer API-kérésről az Amazon Linux 2 szabványos beállításai mellett 4.14-es kernellel 1.2 millió kérésre per másodperc második az optimalizálás után (436%-os növekedés), és a kérelmek feldolgozási késedelmei is 79%-kal csökkentek. A javasolt módszerek nem specifikusak a libreactorra, és más http-kiszolgálók használatakor működnek, beleértve az nginx-et, az Actix-et, a Netty-t és a Node.js-t (a tesztekben a libreactor-t használtuk, mert az arra épülő megoldás jobb teljesítményt mutatott).

Alapvető optimalizálás:

• A libreactor kód optimalizálása. A Techempower készlet R18 opcióját vették alapul, amelyet a kód eltávolításával javítottak a felhasznált CPU magok számának korlátozása érdekében (az optimalizálás 25-27%-kal gyorsította fel a munkát), és GCC-ben szerelték össze a „-O3” opciókkal. (5-10%-os növekedés) és a "-march-native" (5-10%), az olvasási/írási hívások felváltása/küldése (5-10%), valamint a pthread használatakor a többletköltség csökkentése (2-3%) . A teljes teljesítménynövekedés a kódoptimalizálás után 55%-os volt, és a teljesítmény 224 347 rekv/s-ról XNUMX XNUMX rekv/s-ra nőtt.
• A spekulatív végrehajtási biztonsági rések elleni védelem letiltása. A „nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off” paraméterek használata a kernel betöltésekor 28%-kal növelte a teljesítményt, és az átviteli sebesség 347 446 req/s-ról 1 1 req/s-ra nőtt. Külön-külön a növekedés a „nospectre_v1” paramétertől (védelem a Spectre v2-től + SWAPGS) 2-2%, „nospectre_v15” (védelem a Spectre v20-től) - 3-6%, "pti=off" (Spectre v6/Meltdown) - 1%, "mds=off tsx_async_abort=off" (MDS/Zombieload és TSX aszinkron megszakítás) - 1%. Az LXNUMXTF/Foreshadow (lXNUMXtf=flush), az iTLB multihit, a Speculative Store Bypass és az SRBDS támadások elleni védelem beállításai változatlanok maradtak, ami nem befolyásolta a teljesítményt, mivel nem keresztezik a tesztelt konfigurációt (például KVM-specifikus, beágyazott). virtualizáció és más CPU modellek).
• Az auditálási és rendszerhívás-blokkoló mechanizmusok letiltása az "auditctl -a never,task" paranccsal, és a "--security-opt seccomp=unconfined" beállítás megadása a docker-tároló indításakor. A teljes teljesítménynövekedés 11%-os volt, a teljesítmény pedig 446 495 rekv/s-ról XNUMX XNUMX rekv/s-ra nőtt.
• Az iptables/netfilter letiltása a kapcsolódó kernelmodulok eltávolításával. A tűzfal letiltásának ötletét, amelyet egy adott szervermegoldásban nem használtak, a profilalkotási eredmények szülték, amelyek alapján az nf_hook_slow függvény végrehajtása az idő 18%-át vette igénybe. Megjegyzendő, hogy az nftables hatékonyabban működik, mint az iptables, de az Amazon Linux továbbra is használja az iptables-t. Az iptables letiltása után a teljesítménynövekedés 22%-os volt, az átviteli sebesség pedig 495 603 rekv/s-ról XNUMX XNUMX rekv/s-ra nőtt.
• Csökkentett kezelők migrációja a különböző CPU magok között a processzor gyorsítótár használatának hatékonyságának javítása érdekében. Az optimalizálás mind a libreactor-folyamatok CPU-magokhoz kötésének szintjén (CPU Pinning), mind a kernel hálózati kezelőinek rögzítésén keresztül (Receive Side Scaling) megtörtént. Például az irqbalance le van tiltva, és a sor affinitása a CPU-hoz explicit be lett állítva a /proc/irq/$IRQ/smp_affinity_list fájlban. Ahhoz, hogy ugyanazt a CPU magot használja a libreactor folyamat és a bejövő csomagok hálózati sorának feldolgozásához, egyéni BPF-kezelőt használnak, amely a SO_ATTACH_REUSEPORT_CBPF jelző beállításával kapcsolódik a socket létrehozásakor. A kimenő csomagok sorainak a CPU-hoz kötéséhez a /sys/class/net/eth0/queues/tx- beállítások megváltoztak. /xps_cpus. A teljes teljesítménynövekedés 38%-os volt, a teljesítmény pedig 603 834 rekv/s-ról XNUMX XNUMX rekv/s-ra nőtt.
• A megszakítások kezelésének és a lekérdezés használatának optimalizálása. Az adaptív-rx mód engedélyezése az ENA illesztőprogramban és a sysctl net.core.busy_read manipulálása 28%-kal növelte a teljesítményt (834k req/s-ról 1.06M req/s-ra nőtt, a késleltetés pedig 361 μs-ról 292 μs-ra csökkent).
• Olyan rendszerszolgáltatások letiltása, amelyek szükségtelen blokkoláshoz vezetnek a hálózati veremben. A dhclient letiltása és az IP-cím manuális beállítása 6%-os teljesítménynövekedést eredményezett, az átviteli sebesség pedig 1.06 millió rekv/s-ról 1.12 millió rekv/s-ra nőtt. Az ok, amiért a dhclient befolyásolja a teljesítményt, a nyers socket használatával végzett forgalomelemzésben keresendő.
• Fighting Spin Lock. A hálózati verem „noqueue” módba állítása a sysctl „net.core.default_qdisc=noqueue” és „tc qdisc csere a dev eth0 root mq” használatával 2%-os teljesítménynövekedést eredményezett, és az átviteli sebesség 1.12 millió req/s-ról 1.15 millióra nőtt. igény/s
• Utolsó kisebb optimalizálások, mint például a GRO (Generic Receive Offload) letiltása az „ethtool -K eth0 gro off” paranccsal, és a kockaméretű torlódáskezelési algoritmus lecserélése reno-ra a sysctl „net.ipv4.tcp_congestion_control=reno” használatával. A teljes termelékenységnövekedés 4% volt. Az áteresztőképesség 1.15 millió rekv/s-ról 1.2 millió rekv/s-ra nőtt.

A bevált optimalizálás mellett a cikk olyan módszereket is tárgyal, amelyek nem vezettek a várt teljesítménynövekedéshez. Például a következők hatástalannak bizonyultak:

• A libreactor külön futtatása teljesítményében nem különbözött a konténerben való futtatástól. A writev lecserélése send-re, a maxeventek növelése az epoll_wait-ban, valamint a GCC-verziókkal és zászlókkal való kísérletezésnek nem volt hatása (a hatás csak a „-O3” és „-march-native” jelzőknél volt észrevehető).
• A Linux kernel frissítése 4.19 és 5.4 verzióra, a SCHED_FIFO és SCHED_RR ütemezők használatával, a sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=tc nem befolyásolta a teljesítményt.
• Az ENA illesztőprogramban az Offload módok engedélyezése (szegmentálás, szóródás-gyűjtés, rx/tx checksum), a „-O3” jelzővel történő építés, valamint az ena.rx_queue_size és ena.force_large_llq_header paraméterek használata nem járt hatással.
• A hálózati veremben történt változtatások nem javították a teljesítményt:
  • Az IPv6 letiltása: ipv6.disable=1
  • VLAN letiltása: modprobe -rv 8021q
  • A csomagforrás-ellenőrzés letiltása
    • net.ipv4.conf.all.rp_filter=0
    • net.ipv4.conf.eth0.rp_filter=0
    • net.ipv4.conf.all.accept_local=1 (negatív hatás)
  • net.ipv4.tcp_sack = 0
  • net.ipv4.tcp_dsack=0
  • net.ipv4.tcp_mem/tcp_wmem/tcp_rmem
  • net.core.netdev_budget
  • net.core.dev_weight
  • net.core.netdev_max_backlog
  • net.ipv4.tcp_slow_start_after_idle=0
  • net.ipv4.tcp_moderate_rcvbuf=0
  • net.ipv4.tcp_timestamps=0
  • net.ipv4.tcp_low_latency = 1
  • SO_PRIORITY
  • TCP_NODELAY

  Forrás: opennet.ru