Optimalizálás Linux másodpercenként 1.2 millió JSON kérés feldolgozására

Megjelent egy részletes útmutató a környezet hangolásához. Linux a HTTP kérésfeldolgozás maximális teljesítményének elérése érdekében. A javasolt módszerek lehetővé tették számunkra, hogy Amazon EC2 környezetben (4 vCPU) másodpercenként 224 000 API kérésről növeljük a libreactor könyvtáron alapuló JSON-elemző teljesítményét a standard Amazon-beállítások mellett. Linux A 2-es verzió a 4.14-es kernellel optimalizálás után másodpercenként 1.2 millió kérésre növelte az átviteli sebességet (436%-os növekedés), és 79%-kal csökkentette a kérésfeldolgozási késleltetést. A javasolt módszerek nem a libreactorra jellemzőek, és más HTTP-kiszolgálókkal is működnek, beleértve az nginx-et, az Actix-et, a Netty-t és a Node.js-t (a tesztekben a libreactort használták, mivel az azon alapuló 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 utasításvégrehajtás okozta sebezhetőségek elleni védelem letiltása. A "nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off" kernel boot paraméterek használata 28%-kal növelte a teljesítményt, az átviteli sebesség pedig 347k req/s-ról 446k req/s-ra nőtt. Egyedileg a "nospectre_v1" paraméter (Spectre v1 + SWAPGS elleni védelem) nyeresége 1-2%, a "nospectre_v2" (Spectre v2 elleni védelem) 15-20%, a "pti=off" (Spectre v3/Meltdown) 6%, az "mds=off tsx_async_abort=off" (MDS/Zombieload és TSX aszinkron megszakítás) 6% volt. Az L1TF/Foreshadow támadások elleni védelem beállításait (l1tf=flush), az iTLB multihit, a spekulatív tároló megkerülése és az SRBDS, amelyek nem befolyásolták a teljesítményt, változatlanul hagyták, mivel nem ütköztek a tesztelt konfigurációval (például a következőre jellemzőek: KVM, 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 hozzá tartozó kernel modulok eltávolításával. Az adott szervermegoldásban nem használt tűzfal letiltásának ötletét a profilalkotás eredményei adták, amelyek azt mutatták, hogy az nf_hook_slow függvény az idő 18%-át végrehajtással töltötte. Megjegyzendő, hogy az nftables hatékonyabb, mint az iptables, de az Amazonon... Linux Az iptables továbbra is használatban van. Az iptables letiltása után a teljesítmény 22%-kal nőtt, az átviteli sebesség pedig 495k req/s-ról 603k req/s-ra.
• 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).
• A felesleges hálózati veremzárolásokat okozó rendszerszolgáltatások letiltása. A dhclient letiltása és telepítése IP-címek A feladat manuális végrehajtása 6%-os teljesítménynövekedést eredményezett, az átviteli sebesség 1.06M req/s-ról 1.12M req/s-ra nőtt. A dhclient teljesítményre gyakorolt ​​​​hatásának oka a nyers socketet használó forgalomelemzés.
• 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 kernel frissítés nem befolyásolta a teljesítményt. Linux a 4.19-es és 5.4-es verzióig, 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=1 és clocksource=tsc beállítások kezelésével.
• 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