האטות ה-proxy לאורך זמן: בדיקת conntrack ומגבלות משאבים

ה-proxy מגיב לאחר אתחול. כעבור כמה שעות חיבורים חדשים נתקעים. אתחול נוסף קונה עוד פרק זמן שקט. התבנית הזו מרמזת על מצב מצטבר, אך אינה מזהה איזה מצב אחראי לכך.

במסלול Linux שמשתמש במעקב חיבורים, אחד המועמדים הוא טבלת conntrack. בדקו את הערכים הקיימים האלה במכונה ובמרחב השמות של הרשת שמטפל בתעבורה:

/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_max

הראשון מדווח על רשומות זרימה שהוקצו; השני מגביל אותן. אלה אינם ספירות של משתמשי Squid או בקשות HTTP. מצב הזרימה של הקרנל יכול לשרוד מעבר לעבודה הפעילה של היישום.

חפשו קשר, לא רק מספר גדול

השוו את התפוסה לאורך זמן עם תחילת הכשלים בחיבורים חדשים ועם הודעות קרנל רלוונטיות. מספר גבוה בלי ראיות כשל מתאימות שונה מטבלה שמגיעה שוב ושוב לגבולה בדיוק כשבקשות מתחילות לפקוע בזמן.

הטבלה עשויה לשרת יותר מה-proxy. שירותים מקומיים אחרים, תעבורה מועברת או מסלול רשת עמוס אחר יכולים לתרום. העובדה שאתחול של ה-proxy משנה את הסימפטום אינה מוכיחה שמטמון האובייקטים של Squid היה הגורם.

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

העלאת מגבלה כרוכה בעלות זיכרון. לפני השינוי קבעו את עומס העבודה, מרחב השמות והקיבולת הזמינה. קיצור זמני המתנה ללא הבחנה עלול לשבור הפעלות סרק שימושיות; ניקוי כל מצב החיבורים עלול לשבש תעבורה לא קשורה.

התוצאה השימושית היא הסבר להצטברות ושינוי בקיבולת או במחזור החיים שמתאים לו. בטוח להעלאה אינו תכונה שכל שרת proxy חולק.