האם שער ה-VPN שלכם מוגבל על ידי ה-CPU? קראו קודם את העומס לפי ליבה
ממוצעים מסתירים את התהליכון שחשוב. קראו עומס לפי ליבה מול העברה מבוקרת, שללו את הנתיב, ואז שנו הגדרה מתועדת אחת בכל הרצה.
החליטו איזו משלוש המגבלות השגתם לפני שאתם קונים מופע גדול יותר. ליבה אחת עמוסה לחלוטין והשאר בטלות מצביעה על עבודת הצפנה לכל זרימה. כל הליבות רוויות במהלך העברה מצביעות על קיבולת כוללת. CPU נמוך עם מספר גדל של שליחות חוזרות מצביע על הנתיב. לכל אחת צעד ראשון אחר, ורק אחת מהן נפתרת במופע גדול יותר.
שלוש מגבלות, טבלה אחת, שלושה תיקונים
| Limit | Reading during a transfer | First move |
|---|---|---|
| Single thread | one core near 100%, siblings idle | spread flows across workers |
| Aggregate CPU | every core busy, load average climbs | capacity, or less work per byte |
| Path or provider | low CPU, retransmits or steal time high | MTU, loss, host contention |
קראו את השורות כאבחנות ולא כשלבים. תהליכון אחד ב-100% והשאר בטלות הוא התוצאה הנפוצה ביותר בשער שנושא מנהרה גדולה אחת, מפני שההצפנה של אותה זרימה רצה על ליבה אחת. כל הליבות עסוקות במהלך ההעברה פירושו שהמכונה כבר עושה את מלוא העבודה שהיא יכולה. CPU נמוך עם שליחות חוזרות עולות פירושו שהמעבד ממתין לרשת שממשיכה לאבד נתונים.
תקנו אותן בסדר הראיות הזה. פיזור זרימות בין עובדים עוזר למקרה הראשון ולא עושה דבר לשני. מופע גדול יותר עוזר לשני ומבזבז כסף על הראשון. תיקון MTU או אובדן הוא היחיד שנוגע בשלישי. לקנות קיבולת לפני שיודעים באיזו שורה אתם היא הגרסה היקרה של ניחוש.
הפרידו תהליכון מוצמד ממארח עמוס
התחילו בניצולת לפי ליבה, כדי שליבה מוצמדת אחת לא תוכל להתחבא בתוך ממוצע. הרצה אחת במהלך ההעברה מראה אם העומס שטוח או עם פסגות. שתי הצורות מלמדות, ופרופיל עם פסגות לעתים קרובות אומר שחלון הדגימה תפס פעילות של המתזמן ולא הצפנה.
mpstat -P ALL 1 5ייחסו את הליבה העמוסה לתהליך, ואז לתהליכון. הרצת ההמשך שלמטה שומרת על תהליכוני אב ובן יחד, מה שחשוב כשהדמון מסתעף לכל חיבור:
pidstat -u -t -p $(pgrep -f 'openvpn|wireguard|ipsec') 1 10הצפנת הליבה אף פעם לא מופיעה במונה תהליך במרחב משתמש. דגמו תהליכונים בנפרד והשוו את התצוגה הזו להנהלת החשבונות של התהליך:
top -H -b -n 1 | head -20קראו את מוני השקעים אחרונים, מפני שהם מחליטים אם עוד CPU יעזור בכלל. שליחות חוזרות שעולות בזמן ש-CPU שטוח אינן בעיית מעבד. השאירו את ההעברה פועלת בזמן הדגימה, אחרת המספרים יתארו מכונה בטלה:
ss -ti | grep -E 'retrans|cwnd|rtt'העברה מבוקרת, רצה פעמיים
מונים בטלים לא מוכיחים דבר, ומבחן מול נקודת קצה אקראית מוכיח מעט מאוד. בחרו לקוח אחד, יעד אחד והעברה מייצגת אחת שמותר לכם להריץ, ואז תעדו תפוקה והשהיה אינטראקטיבית באותו חלון. שער יכול להירוות בזמן שהעתקה גדולה עדיין מסתיימת, ועקומת ההשהיה היא מה שמשתמשים באמת מרגישים. כתבו את ההעברה, מספר הלקוחות וגרסת הדמון לצד המספרים.
חזרו על ההרצה עם כמה זרימות מקבילות. עלייה לאורך זרימות מרמזת על חלונות לכל זרימה; הישארות שטוחה עם ליבה מוצמדת מרמזת על עיבוד.
ואז חזרו פעם נוספת כשעומסי העבודה האופציונליים עצורים. גיבוי, שולח יומנים או מסד נתונים על אותו מארח יכולים לייצר ממוצע עמוס שאין לו שום קשר למנהרות. אם ה-CPU עדיין מוצמד והמארח שקט אחרת, הראיות מצביעות על תהליך ה-VPN. אם הוא יורד, מדדתם את השכן, והשער מעולם לא היה הבעיה.
שללו את הנתיב לפני שקונים חומרה
שליחות חוזרות עולות, חלון גודש מתכווץ וזמן הלוך-חזור גדל כולם מצביעים הרחק מהמעבד. השוו את MTU המנהרה ל-MTU הנתיב, בדקו את הקישור הבסיסי לאובדן, ואשרו שה-uplink של הלקוח עצמו אינו הגבול. שער גדול יותר לא מתקן קישור שמפיל מנות, ומשתמשים מתארים את שתי התקלות באותן מילים. מונה השליחות החוזרות מפריד ביניהן בדקות.
בשרת וירטואלי, הוסיפו את המדדים של הספק לאלה של האורח. זמן גנוב הוא הדרך שבה מכירת יתר נעשית גלויה בתוך האורח, ושום כיוונון בתוך האורח לא מסיר אותו. מוני האורח לא רואים את המארח, כך שגרף אורח נקי אינו הוכחה למארח בריא.
שינוי אחד, מדידה אחת
בחרו את ההשערה שהראיות תומכות בה, ואז שנו בדיוק הגדרה נתמכת אחת: מספר עובדים, אפשרות פריקה מתועדת, או גודל המופע. OpenVPN מפרסמת מדריך לפתרון בעיות ביצועים על אותו פיצול בין עיבוד לתעבורה: פתרון בעיות ביצועים של OpenVPN.
אשרו שאפשרות הפריקה באמת פעילה במקום לסמוך על הדגל, ואז הריצו שוב את אותה העברה והשוו דומה לדומה. זו הדרך היחידה להבחין בין שיפור אמיתי לאחה צהריים שקטה. שמרו נקודת ביקורת שאפשר לשחזר, מפני שבשינוי השני אנשים מאבדים את המעקב אחרי מה עזר. משתנה אחד לכל הרצה הוא איטי ליום ומהיר לחודש.
אל תחלישו את האימות או את מערך הצפנים כדי שהגרף ייראה טוב יותר. אם ה-CPU עדיין לא עוקב אחרי הסימפטום, חזרו לבדיקות נתיב ויישום במקום לשדרג על בסיס ניחוש.