אופטימיזציה של לינוקס לטיפול ב-1.2 מיליון בקשות JSON בשנייה

פורסם מדריך מפורט בנושא כוונון סביבת לינוקס להשגת ביצועים מקסימליים לעיבוד בקשות HTTP. השיטות המוצעות אפשרו להגדיל את הביצועים של מעבד ה-JSON המבוסס על ספריית ה-Libreactor בסביבת Amazon EC2 (4 vCPU) מ-224 אלף בקשות API לשנייה עם הגדרות סטנדרטיות של Amazon Linux 2 עם ליבה 4.14 ל-1.2 מיליון בקשות לכל שנייה. שנייה לאחר אופטימיזציה (עלייה של 436%), והביאה גם להפחתת העיכובים בטיפול בבקשות ב-79%. השיטות המוצעות אינן ספציפיות ל-Libreactor ועובדות בעת שימוש בשרתי http אחרים, כולל nginx, Actix, Netty ו-Node.js (Libreactor שימש בבדיקות כי הפתרון המבוסס עליו הראה ביצועים טובים יותר).

אופטימיזציות בסיסיות:

• אופטימיזציה של קוד ליברקטור. האופציה R18 מתוך ערכת Techempower שימשה כבסיס, אשר שופרה על ידי הסרת קוד כדי להגביל את מספר ליבות המעבד בשימוש (אופטימיזציה אפשרה לזרז את העבודה ב-25-27%), הרכבה ב-GCC עם אפשרויות "-O3" (עלייה של 5-10% ) ו-"-March-native" (5-10%), החלפת שיחות קריאה/כתיבה ב-rev/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" (הגנה מפני Spectre v1 + SWAPGS) הייתה 1-2%, "nospectre_v2" (הגנה מפני Spectre 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, מקוננת וירטואליזציה ודגמי CPU אחרים).
• השבתת מנגנוני ביקורת וחסימת שיחות מערכת באמצעות הפקודה "auditctl -a never,task" וציון האפשרות "--security-opt seccomp=unconfined" בעת הפעלת הקונטיינר של docker. עליית הביצועים הכוללת הייתה 11%, והתפוקה גדלה מ-446 אלף דרישות/שניות ל-495 אלף דרישות/שניות.
• השבתת iptables/netfilter על ידי פריקת מודולי הליבה המשויכים. הרעיון להשבית את חומת האש, שלא היה בשימוש בפתרון שרת ספציפי, נוצר על ידי יצירת פרופילים, לפיהם לקח לפונקציית nf_hook_slow 18% מהזמן לביצוע. יצוין כי nftables עובד בצורה יעילה יותר מאשר iptables, אך אמזון לינוקס ממשיכה להשתמש ב-iptables. לאחר השבתת iptables, העלייה בביצועים הייתה 22%, והתפוקה גדלה מ-495k req/s ל-603k req/s.
• הגירה מופחתת של מטפלים בין ליבות CPU שונות כדי לשפר את היעילות של השימוש במטמון המעבד. אופטימיזציה בוצעה הן ברמת קשירת תהליכי המשחרר לליבות CPU (CPU Pinning) והן באמצעות הצמדת מטפלי רשת ליבה (Receive Side Scaling). לדוגמה, irqbalance הושבתה וזיקת ​​התור למעבד הוגדרה במפורש ב-/proc/irq/$IRQ/smp_affinity_list. כדי להשתמש באותה ליבת CPU כדי לעבד את תהליך ה-Libreactor ואת תור הרשת של מנות נכנסות, נעשה שימוש במטפל BPF מותאם אישית, המחובר על ידי הגדרת הדגל SO_ATTACH_REUSEPORT_CBPF בעת יצירת השקע. כדי לאגד תורים של מנות יוצאות למעבד, ההגדרות /sys/class/net/eth0/queues/tx-/xps_cpus שונו. עליית הביצועים הכוללת הייתה 38%, והתפוקה גדלה מ-603 דרישות/שניות ל-834 דרישות/שניות.
• אופטימיזציה של טיפול בפסיקות ושימוש בסקר. הפעלת מצב ה-Adaptive-rx במנהל ההתקן של ENA ותפעול sysctl net.core.busy_read הגדילה את הביצועים ב-28% (התפוקה גדלה מ-834k req/s ל-1.06M req/s, והשהייה ירדה מ-361μs ל-292μs).
• השבתת שירותי מערכת המובילים לחסימה מיותרת בערימת הרשת. השבתת dhclient והגדרה ידנית של כתובת ה-IP הביאו לעלייה של 6% בביצועים והתפוקה גדלה מ-1.06M req/s ל-1.12M req/s. הסיבה ש-dhclient משפיע על הביצועים היא בניתוח תעבורה באמצעות שקע גולמי.
• Fighting Spin Lock. העברת ערימת הרשת למצב "noqueue" באמצעות sysctl "net.core.default_qdisc=noqueue" ו-"tc qdisc replace dev eth0 root mq" הובילה לעלייה של 2% בביצועים, והתפוקה גדלה מ-1.12M req/s ל-1.15M דרישה/ים.
• אופטימיזציות קלות אחרונות, כגון השבתת GRO (Generic Receive Offload) עם הפקודה "ethtool -K eth0 gro off" והחלפת אלגוריתם בקרת הגודש המעוקב ב-reno באמצעות sysctl "net.ipv4.tcp_congestion_control=reno". העלייה בפריון הכוללת הייתה 4%. התפוקה גדלה מ-1.15M req/s ל-1.2M req/s.

בנוסף לאופטימיזציות שעבדו, המאמר דן גם בשיטות שלא הובילו לעלייה בביצועים הצפויה. לדוגמה, התברר שהדברים הבאים אינם יעילים:

• הפעלת Libreactor בנפרד לא הייתה שונה בביצועים מהפעלתו במיכל. החלפת writev בשלח, הגדלת maxevents ב-epoll_wait והתנסות עם גרסאות ודגלים של GCC לא השפיעה (ההשפעה הייתה מורגשת רק עבור הדגלים "-O3" ו-"-march-native").
• שדרוג ליבת לינוקס לגירסאות 4.19 ו-5.4, באמצעות מתזמני SCHED_FIFO ו-SCHED_RR, מניפולציה של sysctl kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns, transparent_hugepages=never, skew_tick=t=1 וביצועי שעון לא השפיעו.
• במנהל ההתקן של ENA, הפעלת מצבי Offload (פילוח, פיזור-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