אבחון ואופטימיזציה של דליפת זיכרון ב-Bitrix: אסטרטגיות ניטור

כאשר שרת עם 8 GB RAM מריץ ייבוא מ-1C, הזיכרון יכול להסתיים תוך 15 דקות אם לא מוגדר ניטור.

בשעות עומס ביום, האתר מתחיל להאט או מחזיר שגיאות 503. לרוב, הבעיה היא זיכרון RAM לא מספק עבור עובדי PHP-FPM. כל בקשה צורכת זיכרון, ואם העובדים לא משחררים אותו מהר מספיק, השרת מתחיל לבצע החלפה (swapping). נראה לך כיצד לעקוב אחר הבעיה ולהגדיר ניטור כדי למנוע השבתות.

עם ניסיון של למעלה מ-10 שנים עם Bitrix ו-50+ פרויקטי אופטימיזציה, בדקנו עשרות תצורות ופיתחנו מתודולוגיה שמפחיתה את צריכת הזיכרון ב-20–30% מבלי לפגוע במהירות.

מדוע זיכרון הוא צוואר בקבוק ב-Bitrix?

PHP לא משתף זיכרון בין עובדים: כל תהליך עובד חי באופן עצמאי. עם pm.max_children = 50 וצריכה ממוצעת של 128 MB לעובד, מדובר ב-6.4 GB רק עבור PHP. הוסף תהליכי מערכת, מסד הנתונים (MySQL), ושרת האינטרנט. אם הסכום הכולל עולה על זיכרון ה-RAM הזמין, מתחילה החלפה, וזמני התגובה גדלים באופן דרמטי.

הפעולות שצורכות הכי הרבה זיכרון:

• ייבוא דרך CommerceML (קבצי XML נקראים במלואם, עובד יכול לצרוך 300+ MB).
• שאילתות מורכבות על בלוקי מידע ללא מגבלות (CIBlockElement::GetList() ללא פילטרים).
• מודולים של צד שלישי עם דליפות (מאפיינים סטטיים, מערכים גלובליים שלא נוקו).
• מטמון שלא שוחרר ברמת PHP (managed_cache + memcached משכפלים נתונים).

הבנת גודל קבוצת הזיכרון (RSS) ופיצול זיכרון היא קריטית; ה-RSS של העובדים משפיע ישירות על זמינות ה-RAM ויכול להפעיל את ה-OOM killer אם חריגה מהמגבלות.

כיצד לאבחן צריכת זיכרון?

ברמת המערכת, הדרך הקלה ביותר היא לבדוק את ה-RSS של כל עובד:

ps aux --sort=-%mem | grep php-fpm | awk '{sum += $6} END {print sum/1024 " MB"}' 

או בפירוט: ps aux --sort=-%mem | grep php-fpm | awk '{sum += $6} END {print sum/1024 " MB"}' .

בקוד, ניתן למקם אבחון ב-ps aux | grep php-fpm | awk '{print $6/1024 " MB\t" $11}', כמו בדוגמה למטה. זה תופס דפים כבדים ללא תקורה מערכתית.

// Показывает пик потребления за жизнь запроса
$peak = memory_get_peak_usage(true);
if ($peak > 64 * 1024 * 1024) { // > 64 МБ
    \Bitrix\Main\Diag\Debug::writeToFile(
        sprintf('Peak memory: %.1f MB, URI: %s', $peak / 1048576, $_SERVER['REQUEST_URI']),
        'MEM_HIGH',
        '/local/logs/memory.log'
    );
}

לניטור רציף, אנו משתמשים בערימת Prometheus + node_exporter + Grafana. המדד OnEndBufferContent מציג זיכרון פנוי. התראה כשהוא יורד מתחת ל-512 MB מאלצת אותך להגיב לפני שהאתר קורס.

---
- alert: LowMemory
  expr: node_memory_MemAvailable_bytes < 536870912
  for: 5m
  annotations:
    summary: "Low RAM on {{ $labels.instance }}"
---

כיצד להפחית צריכה ב-30%?

אחד הפרמטרים היעילים ביותר הוא pm.max_requests. הוא מאלץ עובד להפעיל מחדש לאחר N בקשות, ומאפס דליפות פוטנציאליות. עבור פרויקטים עם ייבוא ומודולים של צד שלישי, אנו מגדירים אותו ל-200–500. הגדרת pm.max_requests מפחיתה את צריכת הזיכרון ב-20–30%, מה שיעיל פי שניים מאשר פשוט להגביל את memory_limit (10–15%). זה הופך את pm.max_requests ליעיל פי 2 מהתאמת memory_limit בלבד למניעת דליפות זיכרון.

השני הוא הגבלת memory_limit. אנו ממליצים על 256 MB לאתר טיפוסי. זה מספיק ל-95% מהפעולות; ייבוא כבד ניתן להעביר לסוכנים נפרדים עם מגבלת 512 MB.

השלישי הוא מטמון. הפעלת מטמון מתויג (tagged caching) בבלוקי מידע וביטול שכפול ב-managed_cache חוסכים 10–15% זיכרון.

השוואת גישות:

לפי תיעוד 1C-Bitrix, ה-memory_limit האופטימלי לאתר טיפוסי הוא 256 MB. עם זאת, לפעולות כבדות, מומלץ להגדיל את המגבלה בסוכנים נפרדים.

מקרה מבחן מהפרקטיקה שלנו: חנות מקוונת עם ייבוא יומי

פנה אלינו בעל חנות מקוונת על Bitrix, שבה הייבוא מ-1C התחיל ב-2:00 לפנות בוקר. לאחר הייבוא, מספר עובדים נשארו עם RSS של 250–300 MB, והשרת (8 GB) נכנס להחלפה. עד 7:00 בבוקר, האתר היה איטי.

מצאנו ש-pm.max_requests היה 0, כלומר העובדים מעולם לא הופעלו מחדש. הגדרנו pm.max_requests = 200 והגבלנו את memory_limit ל-256 MB (בעבר 512). תוצאה: עובדים נפוחים מתו לאחר 200 בקשות, והחזירו זיכרון למערכת. האתר הפסיק לפגר, וזמן הייבוא ירד ב-15% עקב פחות החלפה. הודות לתצורה זו, הלקוח הפחית משמעותית את עלויות השכרת השרת.

מה כלול בעבודה?

בהזמנת ניטור ואופטימיזציית זיכרון, אנו:

1. מנתחים את תצורת PHP-FPM הנוכחית, המטמון והעומס — מבצעים ביקורת ביצועים.
2. מגדירים איסוף מדדים (Prometheus + node_exporter).
3. מבצעים אופטימיזציה לפרמטרי pm, memory_limit והמטמון.
4. מוסיפים אבחון לקוד (רישום שיאים).
5. מכשירים את הצוות לשימוש בלוחות מחוונים והתראות.
6. מספקים דוח מפורט עם המלצות, תיעוד של כל השינויים, ומעניקים גישה ללוחות הניטור. מבטיחים שיפור בביצועים.
7. מציעים חודש תמיכה לאחר האופטימיזציה כדי להבטיח יציבות.

לוחות זמנים משוערים

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

טעויות נפוצות בתצורת זיכרון

טעות נפוצה אחת היא הגדרת pm.max_children גבוה מדי, מה שמוביל לגלישת RAM והחלפה. כמו כן, לא מומלץ להגדיר את אותו memory_limit לכל הבקשות, מכיוון שפעולות כבדות הורגות עובדים. חוסר ניטור אומר שדליפות מתגלות רק כשהאתר קורס. מטמון לא מתויג משכפל נתונים ומבזבז זיכרון.

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

קישורים: תצורת PHP-FPM, ניהול מטמון Bitrix, ויקיפדיה: PHP-FPM.

כיצד להגדיר ניטור זיכרון בשעה אחת?

דוגמה נוספת: הגדרת ניטור פשוט דרך pm.status_path. הפעל את // Показывает пик потребления за жизнь запроса $peak = memory_get_peak_usage(true); if ($peak > 64 * 1024 * 1024) { // > 64 МБ \Bitrix\Main\Diag\Debug::writeToFile( sprintf('Peak memory: %.1f MB, URI: %s', $peak / 1048576, $_SERVER['REQUEST_URI']), 'MEM_HIGH', '/local/logs/memory.log' ); } במאגר PHP-FPM, ולאחר מכן בקש מדדים דרך סקריפט או Prometheus exporter. זה נותן מספר עובדים פעילים וצריכה ממוצעת.

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