තත්පරයකට JSON ඉල්ලීම් මිලියන 1.2ක් හැසිරවීමට Linux ප්‍රශස්තකරණය

HTTP ඉල්ලීම් සැකසීම සඳහා උපරිම කාර්යසාධනයක් ලබා ගැනීම සඳහා Linux පරිසරය සුසර කිරීම පිළිබඳ සවිස්තරාත්මක මාර්ගෝපදේශයක් ප්‍රකාශයට පත් කර ඇත. යෝජිත ක්‍රම මගින් Amazon EC2 පරිසරයේ (4 vCPU) libreactor පුස්තකාලය මත පදනම් වූ JSON ප්‍රොසෙසරයේ ක්‍රියාකාරිත්වය තත්පරයකට API ඉල්ලීම් 224 සිට Amazon Linux 2 හි සම්මත සැකසුම් සමඟ කර්නල් 4.14 සමඟ ඉල්ලීම් මිලියන 1.2 දක්වා වැඩි කිරීමට හැකි විය. ප්‍රශස්තිකරණයෙන් පසු දෙවන (436% ක වැඩිවීමක්) සහ ඉල්ලීම් සැකසීමේ ප්‍රමාදයන් 79% කින් අඩු කිරීමට ද හේතු විය. යෝජිත ක්‍රම libreactor සඳහා විශේෂිත නොවන අතර nginx, Actix, Netty සහ Node.js ඇතුළු අනෙකුත් http සේවාදායකයන් භාවිතා කරන විට ක්‍රියා කරයි (libreactor එය මත පදනම් වූ විසඳුම වඩා හොඳ කාර්ය සාධනයක් පෙන්නුම් කළ බැවින් පරීක්ෂණ වලදී භාවිතා කරන ලදී).

තත්පරයකට JSON ඉල්ලීම් මිලියන 1.2ක් හැසිරවීමට Linux ප්‍රශස්තකරණය

මූලික ප්‍රශස්තිකරණය:

  • ලිබ්‍රෙක්ටර් කේතය ප්‍රශස්ත කිරීම. ටෙචම්පවර් කට්ටලයේ R18 විකල්පය පදනමක් ලෙස භාවිතා කරන ලද අතර, භාවිතා කරන ලද CPU කෝර් ගණන සීමා කිරීම සඳහා කේතය ඉවත් කිරීම මගින් වැඩිදියුණු කරන ලදී (ප්‍රශස්තකරණය මඟින් කාර්යය 25-27% කින් වේගවත් කිරීමට ඉඩ ලබා දී ඇත), GCC හි “-O3” විකල්ප සමඟ එකලස් කිරීම. (5-10% ක වැඩිවීමක් ) සහ "-march-native" (5-10%), recv/send (5-10%) සමඟ කියවීමේ/ලිවීමේ ඇමතුම් ප්‍රතිස්ථාපනය කිරීම සහ pthreads භාවිතා කරන විට උඩිස් අඩු කිරීම (2-3%) . කේත ප්‍රශස්තකරණයෙන් පසු සමස්ත කාර්ය සාධනය වැඩිවීම 55%ක් වූ අතර ප්‍රතිදානය 224k req/s සිට 347k req/s දක්වා වැඩි විය.
  • සමපේක්ෂන ක්‍රියාත්මක කිරීමේ දුර්වලතා වලට එරෙහිව ආරක්ෂාව අක්‍රීය කරන්න. කර්නලය පූරණය කිරීමේදී “nospectre_v1 nospectre_v2 pti=off mds=off tsx_async_abort=off” යන පරාමිති භාවිතා කිරීමෙන් කාර්ය සාධනය 28% කින් වැඩි කිරීමට හැකි වූ අතර ප්‍රතිදානය 347k req/s සිට 446k req/s දක්වා වැඩි විය. වෙනමම, “nospectre_v1” (Specter v1 + SWAPGS වෙතින් ආරක්ෂාව) පරාමිතියෙන් වැඩි වීම 1-2%, “nospectre_v2” (Specter v2 වෙතින් ආරක්ෂාව) - 15-20%, "pti=off" (Spectre v3/Meltdown) - 6 %, "mds=off tsx_async_abort=off" (MDS/Zombieload සහ TSX Asynchronous Abort) - 6%. L1TF/Foreshadow (l1tf=flush), iTLB multihit, Speculative Store Bypass සහ SRBDS ප්‍රහාර වලට එරෙහිව ආරක්ෂාව සඳහා වන සැකසුම් නොවෙනස්ව තබා ඇත, ඒවා පරීක්‍ෂා කරන ලද වින්‍යාසය සමඟ ඡේදනය නොවූ බැවින් කාර්ය සාධනයට බල නොපායි (උදාහරණයක් ලෙස, KVM සඳහා විශේෂිත, nested අථත්යකරණය සහ අනෙකුත් CPU ආකෘති).
  • "auditctl -a never,task" විධානය භාවිතයෙන් විගණනය සහ පද්ධති ඇමතුම් අවහිර කිරීමේ යාන්ත්‍රණයන් අක්‍රීය කිරීම සහ ඩොකර් කන්ටේනරය ආරම්භ කිරීමේදී "--security-opt seccomp=unconfined" විකල්පය සඳහන් කිරීම. සමස්ත කාර්ය සාධන වැඩිවීම 11% ක් වූ අතර, ප්‍රතිදානය 446k req/s සිට 495k req/s දක්වා වැඩි විය.
  • ආශ්‍රිත කර්නල් මොඩියුල බාගැනීමෙන් iptables/netfilter අක්‍රිය කිරීම. නිශ්චිත සේවාදායක විසඳුමක භාවිතා නොකළ ෆයර්වෝල් අක්‍රිය කිරීමේ අදහස ප්‍රොෆයිල් කිරීමේ ප්‍රතිඵල මගින් පොළඹවන ලදී, nf_hook_slow ශ්‍රිතය ක්‍රියාත්මක වීමට කාලයෙන් 18%ක් ගත වූ බව විනිශ්චය කරයි. nftables iptables වලට වඩා කාර්යක්ෂමව ක්‍රියා කරන බව සටහන් වේ, නමුත් Amazon Linux දිගටම iptables භාවිතා කරයි. iptables අක්‍රිය කිරීමෙන් පසුව, කාර්ය සාධනය වැඩිවීම 22% ක් වූ අතර, ප්‍රතිදානය 495k req/s සිට 603k req/s දක්වා වැඩි විය.
  • ප්‍රොසෙසර හැඹිලි භාවිතයේ කාර්යක්ෂමතාව වැඩි දියුණු කිරීම සඳහා විවිධ CPU මධ්‍යයන් අතර හසුරුවන්නන්ගේ සංක්‍රමණය අඩු කිරීම. ප්‍රශස්තකරණය ලිබ්‍රේක්‍ටර් ක්‍රියාවලි CPU මධ්‍ය (CPU Pinning) වෙත බන්ධනය කිරීමේ මට්ටමින් සහ කර්නල් ජාල හසුරුවන්න (Receive Side Scaling) හරහා සිදු කරන ලදී. උදාහරණයක් ලෙස, irqbalance අක්‍රිය කර ඇති අතර CPU වෙත පෝලිම් සම්බන්ධය පැහැදිලිවම /proc/irq/$IRQ/smp_affinity_list තුළ සකසා ඇත. ලිබ්‍රේක්ටර් ක්‍රියාවලිය සහ එන පැකට් වල ජාල පෝලිම සැකසීමට එකම CPU හරය භාවිතා කිරීමට, සොකට් එක සාදන විට SO_ATTACH_REUSEPORT_CBPF ධජය සැකසීමෙන් සම්බන්ධ වන අභිරුචි BPF හසුරුව භාවිතා කරයි. CPU වෙත පිටතට යන පැකට් පෝලිම් බැඳීමට, /sys/class/net/eth0/queues/tx- සැකසුම් වෙනස් කර ඇත. /xps_cpus. සමස්ත කාර්ය සාධන වැඩිවීම 38% ක් වූ අතර, ප්‍රතිදානය 603k req/s සිට 834k req/s දක්වා වැඩි විය.
  • බාධා කිරීම් හැසිරවීම සහ ඡන්දය භාවිතා කිරීම ප්‍රශස්ත කිරීම. ENA ධාවකයේ අනුවර්තී-rx මාදිලිය සක්‍රීය කිරීම සහ sysctl net.core.busy_read හැසිරවීම මඟින් කාර්ය සාධනය 28% කින් වැඩි විය (throughput 834k req/s සිට 1.06M req/s දක්වා වැඩි විය, සහ ප්‍රමාදය 361μs සිට 292μs දක්වා අඩු විය).
  • ජාල තොගයේ අනවශ්‍ය අවහිර කිරීම් වලට තුඩු දෙන පද්ධති සේවා අක්‍රිය කිරීම. dhclient අක්‍රිය කිරීම සහ IP ලිපිනය අතින් සැකසීමේ ප්‍රතිඵලයක් ලෙස 6% කාර්ය සාධනය වැඩි වීමක් සහ ප්‍රතිදානය 1.06M req/s සිට 1.12M req/s දක්වා වැඩි විය. dhclient කාර්ය සාධනයට බලපාන හේතුව අමු සොකට් එකක් භාවිතා කරන ගමනාගමන විශ්ලේෂණයයි.
  • ස්පින් ලොක් සටන් කිරීම. sysctl “net.core.default_qdisc=noqueue” සහ “tc qdisc replace dev eth0 root mq” හරහා ජාල තොගය “noqueue” ප්‍රකාරයට මාරු කිරීම 2% කාර්ය සාධනය වැඩි කිරීමට හේතු වූ අතර ප්‍රතිදානය 1.12M req/s සිට 1.15M දක්වා වැඩි විය. req/s.
  • “ethtool -K eth0 gro off” විධානය සමඟ GRO (Generic Receive Offload) අක්‍රිය කිරීම සහ sysctl “net.ipv4.tcp_congestion_control=reno” භාවිතයෙන් cubic congestion control algorithm reno සමඟ ප්‍රතිස්ථාපනය කිරීම වැනි අවසාන සුළු ප්‍රශස්තිකරණයන්. සමස්ත ඵලදායිතාව වැඩිවීම 4% කි. ප්‍රතිදානය 1.15M req/s සිට 1.2M req/s දක්වා වැඩි විය.

වැඩ කළ ප්‍රශස්තිකරණයන්ට අමතරව, අපේක්ෂිත කාර්ය සාධනය වැඩි කිරීමට හේතු නොවූ ක්‍රම ද ලිපියේ සාකච්ඡා කරයි. උදාහරණයක් ලෙස, පහත සඳහන් දේ අකාර්යක්ෂම විය:

  • ලිබ්‍රෙක්ටරය වෙන වෙනම ධාවනය කිරීම එය බහාලුමක ක්‍රියාත්මක වීමට වඩා කාර්ය සාධනයෙන් වෙනස් නොවේ. writev වෙනුවට send සමග ප්‍රතිස්ථාපනය කිරීම, epoll_wait හි maxevents වැඩි කිරීම සහ GCC අනුවාද සහ ධජ සමඟ අත්හදා බැලීම කිසිදු බලපෑමක් සිදු නොකළේය (එය "-O3" සහ "-march-native" ධජ සඳහා පමණක් කැපී පෙනේ).
  • Linux කර්නලය 4.19 සහ 5.4 අනුවාදවලට උත්ශ්‍රේණි කිරීම, SCHED_FIFO සහ SCHED_RR උපලේඛන භාවිතා කරමින්, sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, kernel.sched_wakeup_granularity_ns හැසිරවීම, transparent_clock=hugets did not affect.
  • ENA ධාවකය තුළ, Offload මාතයන් සක්‍රීය කිරීම (segmentation, scatter-gather, rx/tx checksum), “-O3” ධජය සමඟ ගොඩනැගීම සහ ena.rx_queue_size සහ ena.force_large_llq_header පරාමිති භාවිතා කිරීම කිසිදු බලපෑමක් ඇති කළේ නැත.
  • ජාල තොගයේ වෙනස්කම් කාර්ය සාධනය වැඩි දියුණු නොකළේය:
    • IPv6 අක්‍රිය කරන්න: ipv6.disable=1
    • VLAN අක්‍රීය කරන්න: modprobe -rv 8021q
    • පැකේජ මූලාශ්‍ර පරීක්ෂා කිරීම අක්‍රීය කරන්න
      • net.ipv4.conf.all.rp_filter=0
      • net.ipv4.conf.eth0.rp_filter=0
      • net.ipv4.conf.all.accept_local=1 (සෘණාත්මක බලපෑම)
    • 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

    මූලාශ්රය: opennet.ru

අදහස් එක් කරන්න