מציאת מגבלת מתארי הקבצים האמיתית של Squid
קראו את מגבלות התהליך של ה-proxy הפעיל לפני שינוי הגדרות PAM או העתקת ערך nofile קבוע ממתכון קיבולת.
בדקו את הדמון הפעיל לפני שאתם סומכים על ulimit -n של מעטפת ההתחברות. להתקנה שמשתמשת ב-squid.service, התחילו עם:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceקראו את /proc/PID/limits באמצעות מזהה התהליך האמיתי. בפריסה מרובת תהליכים, בדקו גם את ה-worker הרלוונטי. ערך השמור בתצורה אינו הוכחה שהתהליך הזה ירש אותו.
| בקרה | היקף |
|---|---|
מעטפת ulimit ו-PAM limits.conf | צאצאי המעטפת או הפעלות שמשתמשות בפועל בהגדרת PAM |
systemd LimitNOFILE= | תהליכים שהופעלו תחת מדיניות המשאבים של אותו שירות |
Squid max_filedescriptors, היכן שנתמך | מגבלת היישום בתוך אילוצי מערכת ההפעלה |
שירות מערכת אינו מאמץ שינויי PAM רק מפני שמנהל שינה את הקובץ. השתמשו ב-drop-in ייעודי לשירות כאשר שינוי מגבלת ה-systemd שלו מתאים. Squid מתעד ש-max_filedescriptors דורש הפעלה מחדש כדי להשתנות; אם יישאר לא מוגדר, הוא יורש את המגבלה הרכה של מערכת ההפעלה.
כיילו את המגבלה לפי מתארים ולא לפי משתמשים. לקוחות יכולים להחזיק כמה sockets, וגם חיבורים יוצאים, יומנים וצינורות עזר צורכים מתארים. העלאת המגבלה מאפשרת צריכה רבה יותר בלי להקצות מיד כמות RAM קבועה לכל מתאר אפשרי. לא הערכת זיכרון ישנה לכל socket ולא 65,535 הם דרישת קיבולת אוניברסלית או תקרת Linux.
לאחר שינוי השירות, השוו את מגבלות התהליך החדש לערכים המיועדים. אם כשלים מתרחשים הרבה מתחתיהם, חקרו את המשאב שבאמת נגמר.