כוונון ליבת לינוקס (sysctl) לשרתים בעלי עומס גבוה

כוונון ליבת לינוקס (sysctl) לשרתים בעומס גבוה

אנו משלבים ומכווננים פרמטרים של ליבת לינוקס (sysctl) לשרתים בעומס גבוה. לצוות שלנו יש ניסיון של 6+ שנים ב-DevOps וביצענו 80+ פרויקטי אופטימיזציה. הגדרות ברירת המחדל של הליבה הן פשרה בין תאימות לביצועים. בשרת עם 10k+ חיבורים מקבילים או תעבורת UDP גבוהה, הן הופכות לצוואר בקבוק: האפליקציה מקבלת EMFILE, שקעים נתקעים ב-TIME_WAIT, וחבילות אובדות. נתקלנו בזה פעמים רבות בפרויקטים: כשהמדדים מראים ירידה אבל ה-CPU וה-RAM פנויים — הסיבה היא כמעט תמיד sysctl. עם יותר מ-5 שנות ניסיון בכוונון ליבה, אספנו פרופילים לשרתי web, DB, ו-load balancer. מאמר זה מספק קונפיגורציות מוכנות ופרקטיקה, ללא תיאוריה. הניסיון שלנו: בפרויקט אחד עם 50k RPS, פשוט הגדלת somaxconn והפעלת BBR הפחיתו את זמן האחזור ב-30% — שיפור ברור לעומת הגדרות ברירת המחדל.

למה הגדרות ברירת המחדל של הליבה הן צוואר בקבוק

ליבת לינוקס מחוץ לקופסה מכווננת לרב-גוניות: backlog מתון, TCP שמרני, באפרים קטנים. בעומס גבוה זה הופך ל:

• הצפת תור חיבורים. לכל שקע listen יש backlog. תחת תעבורה מתפרצת, התור עולה על גדותיו — חבילות SYN נזרקות. net.core.somaxconn = 4096 ברירת המחדל נחנק ב-5k RPS. אנו מגדירים אותו ל-65535.
• דלדול TIME_WAIT ופורטים אפמריים. כל חיבור TCP סגור נשאר ב-TIME_WAIT למשך 2*MSL (60 שניות). ב-10k בקשות/שנייה — 600k שקעים ב-TIME_WAIT. מאגר הפורטים 32768–60999 (28k) מתרוקן תוך שנייה. פתרון: הרחבת הטווח, הפעלת tcp_tw_reuse, הפחתת tcp_fin_timeout.
• באפרים קטנים לקליטה/שידור. rmem_default=87380 ו-wmem_default=16384 ברירת המחדל חונקים חיבורים עם זמן אחזור גבוה (CDN, בין-אזורי). עבור שרתי סטרימינג זה קריטי.

# /etc/sysctl.d/99-network.conf
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_tw_buckets = 1440000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

איך BBR ובאפרים סוחטים את המקסימום מהרשת

BBR (Bottleneck Bandwidth and RTT) של גוגל הוא אלגוריתם בקרת גודש שעובד על בסיס מדידות, לא על בסיס אובדן. בקישורי WAN עם זמן אחזור גבוה (100+ אלפיות שנייה), BBR נותן שיפור של עד 40% בתפוקה לעומת CUBIC, ובחלק מהתרחישים BBR עולה על CUBIC פי 1.5–2. מופעל עם שתי שורות:

net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr 

בדוק תמיכה דרך # /etc/sysctl.d/99-network.conf net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 15 net.ipv4.tcp_max_tw_buckets = 1440000 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.core.rmem_default = 262144 net.core.wmem_default = 262144 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 — אמור להציג net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr . זמין מהליבה 4.9. לפרטים נוספים, ראה BBR בוויקיפדיה.

באפרים: עבור חיבורים עם מכפלת רוחב-פס-זמן-אחזור גבוהה (לדוגמה, 100 Mbps × 200 אלפיות שנייה = 2.5 MB), הבאפרים ברירת המחדל אינם מספיקים. הגדלת sysctl net.ipv4.tcp_available_congestion_control ל-16 MB מאפשרת ניצול מלא של הצינור ללא אובדן תפוקה.

איך להימנע מפגיעה במגבלת מתארי קבצים

הסיבה השנייה הנפוצה לירידה בביצועים היא דלדול fd. Nginx עם 65536 worker_connections צורך 131072 fd (כל חיבור — שקע ומתאר קובץ). bbr cubic reno ברירת המחדל מתרוקן במהירות. כוונון:

# /etc/sysctl.d/99-fs.conf fs.file-max = 2097152 fs.nr_open = 1048576 

חשוב: tcp_rmem הוא המגבלה המקסימלית לכל תהליך. עבור nginx בדוק גם את fs.file-max = 524288 ביחידת systemd (בדרך כלל # /etc/sysctl.d/99-fs.conf fs.file-max = 2097152 fs.nr_open = 1048576 ). בדוק את המגבלה הנוכחית: fs.nr_open. שימוש: LimitNOFILE (המספר הראשון — בשימוש, השלישי — מקסימום). בדוק מגבלות תהליך נוכחיות: LimitNOFILE=65536. כמו כן, בדוק שימוש ברמת המערכת: cat /proc/$(pidof nginx)/limits | grep "Open files". אם מתקרבים ל-cat /proc/sys/fs/file-nr, הגדל.

זיכרון: swappiness, יחס dirty, overcommit

# /etc/sysctl.d/99-memory.conf (опционально, входит в полный профиль)
vm.swappiness = 10
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
vm.overcommit_memory = 1
vm.overcommit_ratio = 50

• cat /proc/<PID>/limits | grep 'Max open files' — הליבה מבצעת החלפה רק כשבהחלט הכרחי. עבור Redis/Memcached הגדר 0 או 1 (אבל 0 לא מבטל החלפה לחלוטין).
• cat /proc/sys/fs/file-nr + file-max: ב-5% דפים מלוכלכים, הליבה מתחילה כתיבה ברקע; ב-20% היא חוסמת write(). עבור NVMe, ניתן להוריד את # /etc/sysctl.d/99-memory.conf (опционально, входит в полный профиль) vm.swappiness = 10 vm.dirty_ratio = 20 vm.dirty_background_ratio = 5 vm.overcommit_memory = 1 vm.overcommit_ratio = 50 ל-3.
• vm.swappiness = 10 + vm.dirty_ratio = 20 — אפשר overcommit ב-50% מה-RAM. נחוץ עבור Redis (fork במהלך bgsave) ו-Java עם ערימות גדולות.

מה כולל שירות כוונון הליבה שלנו

• ביקורת פרמטרים נוכחיים: איסוף vm.dirty_background_ratio = 5, dirty_background_ratio, vm.overcommit_memory = 1, פרופיל עומס (RPS, סוגי חיבורים).
• פרופיל עומס: שימוש ב-wrk, iperf3, pgbench לכוונון מדויק.
• הכנת פרופיל: קונפיגורציה מפורטת עם נימוק לכל פרמטר לפי עומס העבודה שלך.
• יישום וניטור: פריסה בשלבים עם מעקב אחר מדדים (זמן אחזור, תפוקה, שיעור שגיאות).
• תיעוד: תיאור כל השינויים, למה ואיך לחזור לאחור.
• אחריות: 3 חודשי תמיכה לאחר השחרור — אם הפרופיל לא מספק את הרווחים הצפויים, אנו מתקנים ללא עלות.

עלות הכוונון מחושבת באופן אישי, אבל ההחזר הוא בדרך כלל פחות מ-3 חודשים בזכות שיפור הביצועים. החיסכון בחומרה יכול להגיע ל-30% — עבור פרויקט בינוני, זה חיסכון של $2,000 לחודש. בקשו ייעוץ — נבחן את הפרויקט שלכם.

תהליך העבודה

1. אנליטיקה — ביקורת sysctl נוכחי, זיהוי צווארי בקבוק (TIME_WAIT, fd, באפרים).
2. עיצוב — בחירת פרופיל לפי סוג העומס (web, DB, סטרימינג).
3. יישום — החלה דרך vm.overcommit_ratio = 50, בדיקה בסביבת staging.
4. בדיקת עומס — wrk, iperf3, השוואת מדדים.
5. פריסה לייצור עם ניטור (Prometheus + Grafana).

לצוות שלנו יש ניסיון של 6+ שנים ב-DevOps ו-80+ פרויקטי אופטימיזציה. אנו מבטיחים תוצאות. צרו קשר כדי לקבל ניתוח מפורט של המערכת שלכם.

החל את כל הקונפיגורציות עם sysctl -a, בדוק פרמטר ספציפי עם ss -s. לפני שינויים, צלם תמונת מצב: cat /proc/sys/fs/file-nr.

פרופיל ייצור מלא:

# /etc/sysctl.d/99-highload.conf
# Сеть — TCP
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_slow_start_after_idle = 0
# Буферы
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# BBR
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
# Файловые дескрипторы
fs.file-max = 2097152
# Память
vm.swappiness = 10
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5

פרטים נוספים ב-BBR בוויקיפדיה.