Linux optimizācija, lai apstrādātu 1.2 miljonus JSON pieprasījumu sekundē

Ir publicēts detalizēts ceļvedis par Linux vides regulÄ“Å”anu, lai sasniegtu maksimālu HTTP pieprasÄ«jumu apstrādes veiktspēju. Piedāvātās metodes ļāva palielināt JSON procesora veiktspēju, pamatojoties uz libreactor bibliotēku Amazon EC2 vidē (4 vCPU) no 224 tÅ«kstoÅ”iem API pieprasÄ«jumu sekundē ar Amazon Linux 2 standarta iestatÄ«jumiem ar kodolu 4.14 lÄ«dz 1.2 miljoniem pieprasÄ«jumu vienā otrajā vietā pēc optimizācijas (pieaugums par 436%), kā arÄ« samazināja pieprasÄ«jumu apstrādes kavējumus par 79%. Piedāvātās metodes nav specifiskas libreactor un darbojas, izmantojot citus http serverus, tostarp nginx, Actix, Netty un Node.js (testos tika izmantots libreactor, jo uz tā balstÄ«tais risinājums uzrādÄ«ja labāku veiktspēju).

Linux optimizācija, lai apstrādātu 1.2 miljonus JSON pieprasījumu sekundē

Pamata optimizācijas:

  • Librektora koda optimizÄ“Å”ana. Par pamatu tika izmantota R18 opcija no Techempower komplekta, kas tika uzlabota, noņemot kodu, lai ierobežotu izmantoto CPU kodolu skaitu (optimizācija ļāva paātrināt darbu par 25-27%), montējot GCC ar opcijām ā€œ-O3ā€ (pieaugums par 5-10%) un "-march-native" (5-10%), aizstājot lasÄ«Å”anas/rakstÄ«Å”anas zvanus ar recv/send (5-10%) un samazinot pieskaitāmās izmaksas, izmantojot pthreads (2-3%). . Kopējais veiktspējas pieaugums pēc koda optimizācijas bija 55%, un caurlaidspēja palielinājās no 224k req/s lÄ«dz 347k req/s.
  • Atspējot aizsardzÄ«bu pret spekulatÄ«vas izpildes ievainojamÄ«bu. Parametru ā€œnospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=offā€ izmantoÅ”ana kodola ielādes laikā ļāva palielināt veiktspēju par 28%, un caurlaidspēja palielinājās no 347k req/s lÄ«dz 446k req/s. AtseviŔķi palielinājums no parametra ā€œnospectre_v1ā€ (aizsardzÄ«ba no Spectre v1 + SWAPGS) bija 1-2%, ā€œnospectre_v2ā€ (aizsardzÄ«ba no Spectre v2) - 15-20%, "pti=off" (Spectre v3/Meltdown) - 6%, "mds=off tsx_async_abort=off" (MDS/Zombieload un TSX asinhronā pārtraukÅ”ana) - 6%. IestatÄ«jumi aizsardzÄ«bai pret L1TF/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass un SRBDS uzbrukumiem tika atstāti nemainÄ«gi, kas neietekmēja veiktspēju, jo tie nekrustojas ar pārbaudÄ«to konfigurāciju (piemēram, specifiski KVM, ligzdots virtualizācija un citi CPU modeļi).
  • AuditÄ“Å”anas un sistēmas izsaukumu bloÄ·Ä“Å”anas mehānismu atspējoÅ”ana, izmantojot komandu "auditctl -a never,task" un norādot opciju "--security-opt seccomp=unconfined", startējot docker konteineru. Kopējais veiktspējas pieaugums bija par 11%, un caurlaidspēja palielinājās no 446 495 rekv/s lÄ«dz XNUMX XNUMX req/s.
  • Iptables/netfilter atspējoÅ”ana, izkraujot saistÄ«tos kodola moduļus. Ideju atslēgt ugunsmÅ«ri, kas netika izmantots konkrētā servera risinājumā, rosināja profilÄ“Å”anas rezultāti, pēc kuriem spriežot, funkcijas nf_hook_slow izpilde aizņēma 18% laika. Tiek atzÄ«mēts, ka nftables darbojas efektÄ«vāk nekā iptables, taču Amazon Linux turpina izmantot iptables. Pēc iptable atspējoÅ”anas veiktspējas pieaugums bija 22%, un caurlaidspēja palielinājās no 495 603 rekv/s lÄ«dz XNUMX XNUMX req/s.
  • Samazināta apstrādātāju migrācija starp dažādiem CPU kodoliem, lai uzlabotu procesora keÅ”atmiņas izmantoÅ”anas efektivitāti. Optimizācija tika veikta gan libreactor procesu saistÄ«Å”anas lÄ«menÄ« ar CPU kodoliem (CPU Pinning), gan izmantojot kodola tÄ«kla apdarinātāju piesprauÅ”anu (Receive Side Scaling). Piemēram, irqbalance tika atspējota, un rindā /proc/irq/$IRQ/smp_affinity_list tika skaidri iestatÄ«ta rindas afinitāte pret centrālo procesoru. Lai izmantotu vienu un to paÅ”u CPU kodolu, lai apstrādātu libreactor procesu un ienākoÅ”o pakeÅ”u tÄ«kla rindu, tiek izmantots pielāgots BPF apdarinātājs, kas savienots, ligzdas izveides laikā iestatot karogu SO_ATTACH_REUSEPORT_CBPF. Lai saistÄ«tu izejoÅ”o pakeÅ”u rindas ar centrālo procesoru, ir mainÄ«ti iestatÄ«jumi /sys/class/net/eth0/queues/tx- /xps_cpus. Kopējais veiktspējas pieaugums bija 38%, un caurlaidspēja palielinājās no 603 834 rekv/s lÄ«dz XNUMX XNUMX rekv/s.
  • Pārtraukumu apstrādes un aptaujas izmantoÅ”anas optimizācija. Iespējojot adaptÄ«vā-rx režīmu ENA draiverÄ« un manipulējot ar sysctl net.core.busy_read, veiktspēja palielinājās par 28% (caurlaidspēja palielinājās no 834 1.06 req/s lÄ«dz 361 M req/s, un latentums samazinājās no 292 Ī¼s lÄ«dz XNUMX Ī¼s).
  • Sistēmas pakalpojumu atspējoÅ”ana, kas izraisa nevajadzÄ«gu tÄ«kla steka bloÄ·Ä“Å”anu. Atspējojot dhclient un manuāli iestatot IP adresi, veiktspēja palielinājās par 6%, un caurlaidspēja palielinājās no 1.06 M req/s lÄ«dz 1.12 M req/s. Iemesls, kāpēc dhclient ietekmē veiktspēju, ir trafika analÄ«ze, izmantojot neapstrādātu ligzdu.
  • Cīņa ar Spin Lock. Pārslēdzot tÄ«kla steku uz ā€œnoqueueā€ režīmu, izmantojot sysctl ā€œnet.core.default_qdisc=noqueueā€ un ā€œtc qdisc aizstāt dev eth0 root mqā€, veiktspēja palielinājās par 2%, un caurlaidspēja palielinājās no 1.12 miljoniem req/s lÄ«dz 1.15 miljoniem. pras./s.
  • Pēdējās nelielas optimizācijas, piemēram, GRO (Generic Receive Offload) atspējoÅ”ana ar komandu ā€œethtool -K eth0 gro offā€ un kubiskā pārslodzes kontroles algoritma aizstāŔana ar reno, izmantojot sysctl ā€œnet.ipv4.tcp_congestion_control=renoā€. Kopējais produktivitātes pieaugums bija 4%. Caurlaide palielinājās no 1.15 miljoniem rekv/s lÄ«dz 1.2 miljoniem rekv./s.

Papildus optimizācijām, kas darbojās, rakstā ir apskatÄ«tas arÄ« metodes, kas nesniedza gaidÄ«to veiktspējas pieaugumu. Piemēram, Ŕādi pasākumi izrādÄ«jās neefektÄ«vi:

  • Palaižot libreactor atseviŔķi, veiktspēja neatŔķīrās no tā darbināŔanas konteinerā. Writev aizstāŔanai ar send, maxevents palielināŔanai epoll_wait un eksperimentÄ“Å”anai ar GCC versijām un karodziņiem nebija nekādas ietekmes (efekts bija pamanāms tikai karodziņiem ā€œ-O3ā€ un ā€œ-march-nativeā€).
  • Linux kodola jaunināŔana uz versijām 4.19 un 5.4, izmantojot SCHED_FIFO un SCHED_RR plānotājus, manipulējot ar sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=tc un neietekmēja veiktspēju.
  • ENA draiverÄ« izkrauÅ”anas režīmu iespējoÅ”ana (segmentÄ“Å”ana, izkliedÄ“Å”ana, rx/tx kontrolsumma), veidoÅ”ana ar karogu ā€œ-O3ā€ un parametru ena.rx_queue_size un ena.force_large_llq_header izmantoÅ”ana nedeva nekādu efektu.
  • Izmaiņas tÄ«kla stekā neuzlaboja veiktspēju:
    • Atspējot IPv6: ipv6.disable=1
    • Atspējot VLAN: modprobe -rv 8021q
    • Atspējot pakotnes avota pārbaudi
      • net.ipv4.conf.all.rp_filter=0
      • net.ipv4.conf.eth0.rp_filter=0
      • net.ipv4.conf.all.accept_local=1 (negatÄ«vs efekts)
    • 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_PRIORITĀTE
    • TCP_NODELAY

    Avots: opennet.ru

Pievieno komentāru