שליטה במשאבי Docker: מגבלות CPU וזיכרון

בקרת משאבי Docker: מגבלות CPU וזיכרון

אנחנו עוזרים לצוותים להגדיר מגבלות קונטיינרים של Docker כך ש-OOM Killer לא יהרוג מסדי נתונים ונחשולי CPU לא יפילו את הייצור. דליפת זיכרון בשירות אחד מפילה את כל המארח: הגרעין מתחיל להרוג תהליכים אקראיים, והבא בתור יכול להיות Postgres, לא הקונטיינר הבעייתי. נחשול CPU משאילתה גרועה מאט את כל השירותים האחרים על הצומת בו-זמנית. הגישה שלנו: ביקורת, ניטור והגדרה סוהר. כפי שצוין בתיעוד של Docker, השיטה המומלצת היא הגדרת מגבלות זיכרון ו-CPU כדי למנוע תחרות על משאבים. למד כיצד להגדיר מגבלות CPU וזיכרון של Docker ביעילות. השתמש בהגדרות מגבלות זיכרון של Docker Compose עבור מחסני שירותים מרובי רכיבים. נטר עם ניטור docker stats ומחסן cAdvisor Prometheus לאופטימיזציית משאבי Docker. שלט בניהול זיכרון קונטיינרים עם הגדרת מגבלות Docker. עבור הגדרת cpus של Docker, השתמש בשדה deploy.resources.limits.cpus. הגדרות CPU shares של Docker מיועדות למגבלות רכות. הבן את התנהגות OOM Killer של Docker. הזמן ביקורת תשתית Docker — נעריך את הפרויקט שלך תוך יומיים.

למה OOM Killer הורג את התהליך הלא נכון

ללא מגבלות --memory, OOM Killer של Linux בוחר קורבנות על בסיס oom_score_adj וצריכת זיכרון. קונטיינרים של Docker כברירת מחדל מקבלים oom_score_adj=0. Postgres, שמשתמש ב-2GB של shared_buffers, מקבל ציון גבוה וייהרג לפני קונטיינר NodeJS עם דליפת זיכרון שגדל ל-3GB. תוצאה: מסד הנתונים מופל, האפליקציה נשארת בחיים.

עם מגבלות מתאימות, Docker הורג רק את הקונטיינר שחצה את המגבלה שלו. אם תגדיר --memory-swap שווה ל---memory, גם ה-swap עבור הקונטיינר מוגבל — הוא לא יכול לבצע swap בשקט ולפגוע בביצועים.

איך להגדיר מגבלות קונטיינרים כראוי

1. מדוד את הצריכה הנוכחית. הרץ docker stats ואסוף נתונים למשך 7 ימים דרך cAdvisor + Prometheus. מדדים מרכזיים: container_memory_working_set_bytes ו-container_cpu_usage_seconds_total. עקוב אחר האחוזון ה-90 — הוא מראה עומס אמיתי ללא נחשולים.
2. זהה שיאים. עבור זיכרון, השתמש בערך המקסימלי בתוספת 50% מרווח ביטחון. עבור CPU, הסתכל על אחוזון p99, לא על הממוצע. טעות נפוצה: התבססות על ממוצע, מה שגורם לנחשולים להפיל את הקונטיינר.
3. הגדר מגבלות והזמנות. מגבלות קשיחות (docker events --filter type=container --filter event=oom) מונעות מהקונטיינר לחרוג מהגבולות. הזמנות (services: api: image: myapp-api:latest deploy: resources: limits: memory: 512m reservations: memory: 256m worker: image: myapp-worker:latest deploy: resources: limits: memory: 1g cpus: "1.5" reservations: memory: 512m cpus: "0.5" ) מבטיחות מינימום במצבי תחרות. לדוגמה, עבור שירות API, הגדר מגבלת זיכרון ל-512m עם 20% מרווח ביטחון.
4. הוסף התראות. הגדר הודעות על אירועי OOM: limits. נטר גם חניקת CPU: אזהרה כשהמכסה עולה על 80%.
5. בדוק תחת עומס. הרץ בדיקות עומס עם 50% עומס CPU וודא שאף קונטיינר לא חורג מהמגבלות והשהייה נשארת במסגרת SLA.

מגבלות זיכרון ב-Compose

---
services:
  api:
    image: myapp-api:latest
    deploy:
      resources:
        limits:
          memory: 512m
        reservations:
          memory: 256m
  worker:
    image: myapp-worker:latest
    deploy:
      resources:
        limits:
          memory: 1g
          cpus: "1.5"
        reservations:
          memory: 512m
          cpus: "0.5"

reservations — תקרה קשיחה. --compatibility — מינימום מובטח (Docker Swarm משתמש בזה למיקום צמתים). עבור Compose v2+ עצמאי, מגבלות עובדות ישירות ללא דגל --cpus.

אילו מגבלות CPU לבחור: Shares או Quota?

Docker מספק שני מנגנוני הגבלת CPU שמבולבלים לעיתים קרובות.

cpus (או cpus: "0.5") — מכסת CFS. services: api: deploy: resources: limits: cpus: "2.0" # не более 2 ядер в любой момент reservations: cpus: "0.5" # гарантировано 50% ядра bg_worker: deploy: resources: limits: cpus: "0.5" # batch-worker не должен мешать API פירושו שהקונטיינר מקבל לכל היותר 50% מליבת CPU אחת לכל תקופת 100ms. זו מגבלה קשיחה: גם אם המארח פנוי, הקונטיינר לא מקבל יותר. מגבלות קשיחות עם cpus טובות פי 2 מ-cpu_shares לצורך יכולת חיזוי.

cpu_shares — משקל יחסי. ברירת מחדל 1024. אם לקונטיינר אחד יש 512 ולאחר 2048 — במצב תחרות הראשון מקבל 20% CPU והשני 80%. אבל אם המארח פנוי, שניהם מקבלים כמה שצריך. זו מגבלה רכה, מתאימה למשימות אצווה.

---
services:
  api:
    deploy:
      resources:
        limits:
          cpus: "2.0" # не более 2 ядер в любой момент
        reservations:
          cpus: "0.5" # гарантировано 50% ядра
  bg_worker:
    deploy:
      resources:
        limits:
          cpus: "0.5" # batch-worker не должен мешать API

מתי להשבית את OOM Killer?

oom_kill_disable: true — אחת ההגדרות המסוכנות ביותר. היא משביתה את OOM Killer עבור הקונטיינר, כלומר במצב לחץ זיכרון הגרעין יהרוג משהו אחר במקום. משתמשים בזה רק במקרים קיצוניים (למשל, עבור Elasticsearch שמנהל זיכרון פנימית).

התנהגות Swap זיכרון ו-OOM

---
services:
  app:
    mem_limit: 512m
    memswap_limit: 512m # swap = 0 (memswap_limit - mem_limit)
    oom_kill_disable: false # НЕ отключать OOM killer
---

מה כלול

• ביקורת מגבלות נוכחיות ותצורות Docker Compose / Swarm.
• הקמת ניטור (cAdvisor + Prometheus) לאיסוף מדדים.
• ניתוח שיאי זיכרון ו-CPU לכל שירות במשך 7 ימים עם אחוזון 90.
• הגדרת מגבלות והזמנות לפי SLA.
• הגדרת התראות על אירועי OOM.
• תיעוד: Runbook לניהול מגבלות, מדיניות קנה מידה.
• העברת ידע לצוות — הדרכה על פקודות בסיסיות וכיוונון.

התוצאות שלנו

במשך 5 שנות ניסיון DevOps, מעל 50 פרויקטים של אופטימיזציית תשתית Docker. לאחר הגדרת מגבלות, לקוחות מדווחים:

• חיסכון של עד 40% במשאבי מארח, הפחתת עלויות ענן עד $10,000 לחודש. לדוגמה, לקוח אחד חסך $5,000 לחודש לאחר הביקורת.
• הפחתה של 50% ב-MTTR לאירועי OOM, פי 3 פחות אירועים קריטיים — זה פי 3 שיפור בתגובה לאירועים.

תהליך עבודה ומחירים

אנחנו מתחילים ניטור ללא מגבלות — אוספים נתוני צריכה אמיתיים. מנתחים שיאי זיכרון ו-CPU לכל שירות. מגדירים מגבלות והזמנות. מגדירים התראות OOM. מוודאים התנהגות תחת עומס.

רשימת בדיקה לבדיקה עצמית:

• ודא שלכל שירות יש מגבלת זיכרון.
• הגדר services: app: mem_limit: 512m memswap_limit: 512m # swap = 0 (memswap_limit - mem_limit) oom_kill_disable: false # НЕ отключать OOM killer שווה ל---memory-swap כדי להשבית swap.
• הוסף התראות על אירועי OOM.
• ודא ש-cpu_shares לא בשימוש עבור שירותים קריטיים.
• בדוק תחת עומס עם ניצולת CPU של 50-80%.

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