MariaDB מתאתחל לבד? OOM Killer בשרת וורדפרס ואיך מזהים ומתקנים

עודכן לאחרונה: 07.11.2026 · מאת עשהאל דרייר

בקצרה: כש-MariaDB מתאתחל לבד בשרת וורדפרס, הסיבה הנפוצה היא OOM Killer: מנגנון של לינוקס שהורג תהליך כשנגמרים ה-RAM וה-swap. בשרת שלנו בקלאודוויז (Cloudways), עם 16GB ו-36 אתרים, ‏PHP-FPM תפס כ-2.7GB ו-MariaDB כ-4.5GB עד שהזיכרון נגמר. מה שהתמיכה עשתה בספטמבר 2026: הגדילה את ה-swap (מ-2GB ל-4GB) והמליצה להגביל בוטים ו-admin-ajax. בשרת אחר שלנו היא גם צמצמה תהליכי PHP-FPM בסרק מכ-112 ל-3, מה שפינה כ-7.5GB.

⏱ זמן אבחון: 20–40 דקות · רמת קושי: מתקדם · נבדק לאחרונה מול הטיקטים שלנו: 07.11.2026

העמוד מבוסס על פניות תמיכה אמיתיות שפתחנו בקלאודוויז: טיקטים #977464, #978826 ו-#981625 מספטמבר 2026, ו-#619034 מינואר 2025. הנתונים, התאריכים וזמני התגובה לקוחים מהמיילים של מערכת הפניות.

מה זה OOM Killer ולמה הוא בוחר דווקא ב-MariaDB?

OOM Killer (Out Of Memory Killer) הוא חלק מליבת לינוקס. כשאין יותר זיכרון פנוי ואין מקום ב-swap, הוא בוחר תהליך ומחסל אותו כדי שהשרת כולו לא יקרוס.

לפי התיעוד של ליבת לינוקס, כל תהליך מקבל ציון "badness" בין 0 ל-1000, בערך לפי החלק מהזיכרון שהוא תופס. מסד הנתונים הוא בדרך כלל התהליך הבודד הגדול ביותר בשרת וורדפרס, ולכן הוא הראשון שנהרג. אחרי זה מערכת הניהול מפעילה אותו מחדש, ואתם רואים "MariaDB restart".

זה גם ההבדל מול שגיאת חיבור רגילה. אם האתר מציג Error Establishing a Database Connection לכמה שניות ואז חוזר לבד, חשדו ב-OOM. בירור כללי של השגיאה נמצא במדריך Error Establishing a Database Connection.

מה קרה אצלנו? הסיפור מהטיקטים

1. 29.1.2025, טיקט #619034: הודעה יזומה מקלאודוויז שה-MySQL נפל שוב ושוב בגלל OOM בשרת קטן. ההמלצה הייתה לייעל או להגדיל RAM. זה היה האות הראשון, ולא טיפלנו בו לעומק.
2. 23.9.2026, טיקט #977464: שתי הפעלות מחדש של MariaDB בתוך 25 דקות, בשרת עם כ-36 אתרים וכ-108 תהליכי PHP-FPM. התמיכה ענתה תוך כ-21 דקות וזיהתה OOM Killer. אתר אחד תפס כ-69% מזיכרון האפליקציות, בגלל הצפה של שגיאות 404, ‏500 ו-503 על קבצי CSS חסרים של Elementor. ההמלצה: לייצר מחדש את קבצי ה-CSS ולעקוב.
3. 25.9.2026, טיקט #978826: בשרת אחר ה-swap היה מלא ב-100% והיו הריגות OOM. התמיכה מצאה כ-112 תהליכי PHP-FPM בסרק, וצמצמה אותם ל-3. זה פינה כ-7.5GB של RAM. תגובה ראשונה: כ-3.3 שעות.
4. 30.9.2026, טיקט #981625: MariaDB התאתחל בדקה קבועה בשרת של 16GB ו-8 ליבות. העומס היה כ-12 וה-swap של 2GB מלא. התמיכה ענתה תוך כ-50 דקות: PHP-FPM עם כ-2.7GB ו-MariaDB עם כ-4.5GB מיצו את ה-RAM וה-swap. הטריגרים היו תנועת בוטים, preload של WP Rocket ובקשות admin-ajax כבדות. התמיכה הגדילה את ה-swap מ-2GB ל-4GB, והמליצה על הגבלת קצב ב-Cloudflare ל-admin-ajax ועל האטת ה-preload.

הלקח: קריסה בדקה קבועה מצביעה בדרך כלל על משימה מתוזמנת. אצלנו התמיכה לא קבעה סיבה בודדת, אלא מנתה כמה טריגרים: בוטים, preload של WP Rocket ו-admin-ajax כבד.

איך מזהים ש-OOM Killer הרג את MariaDB?

מחפשים שלושה דברים: שורת OOM בלוג של הליבה, swap מלא בגרפים, ושעה שחוזרת על עצמה. ארבעה צעדים, לפי הסדר:

1. בפאנל הניהול בחרו את השרת ופתחו Monitoring. בדקו את גרף הזיכרון וה-swap בשעת הקריסה. פירוט במדריך ניטור שרת בקלאודוויז.
2. התחברו ב-SSH והריצו htop. מיינו לפי זיכרון (MEM%) וספרו כמה תהליכי php-fpm רצים בלי לעבוד.
3. אם יש לכם הרשאה, חפשו בלוג הליבה: dmesg -T | grep -i -E "out of memory|killed process". שורה כמו Out of memory: Killed process ... (mariadbd) היא ההוכחה.
4. למשתמש הראשי בקלאודוויז אין root, ולכן ייתכן שהפקודה לא תעבוד. במקרה כזה בקשו מהתמיכה את שורות ה-OOM ואת הפירוט של צריכת הזיכרון לפי תהליך, כמו שעשינו.

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

איך מתקנים קריסות OOM בשרת וורדפרס בקלאודוויז?

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

פעולה	מי עושה	מה קרה אצלנו
צמצום תהליכי PHP-FPM בסרק	התמיכה	מ-112 ל-3, פונו כ-7.5GB
הגבלת בוטים ו-admin-ajax	אתם (Cloudflare, Bot Protection)	הומלץ בטיקט #981625
האטת preload של קאש	אתם (בתוסף)	הומלץ בטיקט #981625
תיקון אתר שמייצר שגיאות	אתם	יצירה מחדש של CSS של Elementor
הגדלת swap	התמיכה	מ-2GB ל-4GB
הקטנת InnoDB buffer pool	אתם בפאנל	הוצע 4096MB, נשאר 6144MB
הגדלת RAM	אתם	הפתרון האחרון, לא הראשון

1. פתחו פנייה לתמיכה וכתבו את שעות הקריסה. בקשו את שורות ה-OOM ואת צריכת הזיכרון לפי תהליך ולפי אפליקציה.
2. הפעילו Bot Protection בקלאודוויז, ובדקו כמה תנועה מגיעה מבוטים. המדריך עומס של סורקי AI על השרת מסביר איך להגביל אותם.
3. ב-Cloudflare צרו כלל הגבלת קצב (Rate Limiting) לנתיב /wp-admin/admin-ajax.php. לפי התיעוד של Cloudflare, בתוכנית החינמית יש כלל אחד, עם ספירה לפי IP ותקופה של 10 שניות. קבעו סף נדיב, כי גם גולשים אמיתיים משתמשים ב-admin-ajax.
4. האטו או כבו preload של קאש באתרים גדולים, ופזרו את זמני ההרצה בין אתרים.
5. מצאו את האתר שמייצר שגיאות 404 ו-500 בכמויות ותקנו אותו. ב-Elementor זה Regenerate Files & Data תחת Tools.
6. אחרי שבוע בלי קריסות, החליטו אם צריך עוד RAM. אם כן, ראו הגדלת שרת בקלאודוויז.

למה השרת מלא בתהליכי PHP-FPM בסרק?

PHP-FPM מריץ "workers": תהליכים שמחכים לבקשות PHP. כל אפליקציה בשרת מקבלת מאגר משלה, וכל worker שומר זיכרון גם כשהוא לא עושה כלום. בשרת עם 36 אתרים זה מצטבר מהר.

אצלנו היו כ-112 workers בסרק. החשבון: 7.5GB חלקי כ-109 workers שנסגרו נותן כ-70MB לכל worker (הערכה שלנו). בשרת של 16GB זה כמעט חצי מהזיכרון, על תהליכים שלא שירתו אף גולש.

לפי התיעוד של PHP-FPM יש שלושה מצבים לניהול workers:

מצב (pm)	איך הוא עובד	מתי מתאים
static	מספר קבוע של workers, לפי pm.max_children	אתר אחד עמוס עם הרבה RAM
dynamic	מספר משתנה, עם מינימום של workers פנויים שתמיד רצים	אתר אחד או כמה אתרים עם תנועה קבועה
ondemand	worker נפתח רק כשיש בקשה ונסגר אחרי זמן סרק (ברירת מחדל 10 שניות)	שרת עם הרבה אתרים קטנים

בפאנל לא ראינו אפשרות לשנות את מצב ה-pm. אצלנו התמיכה עשתה את השינוי ברמת הפלטפורמה. בפאנל אפשר לשנות הגדרות PHP לאפליקציה (כמו memory_limit), לפי המדריך הגדרות PHP בקלאודוויז, אבל לא את מצב ה-pm.

לגבי מסד הנתונים: התמיכה הציעה להוריד את InnoDB buffer pool מ-6144MB ל-4096MB, והשינוי לא נקלט בטיקט. התיעוד של MariaDB ממליץ שה-buffer pool יחזיק את רוב הנתונים הפעילים, ומזהיר שגודל גדול מדי גורם ל-swapping. בשרת רב-אתרים שווה למצוא את האיזון בין MariaDB ל-PHP-FPM, ולא לתת לאחד מהם את כל הזיכרון. איך הזיכרון מתחלק בשרת וורדפרס מוסבר במדריך כמה RAM צריך אתר וורדפרס.

אילו טעויות נפוצות מחמירות קריסות OOM?

להגדיל RAM מיד: אם הבוטים וה-preload ממשיכים, הם ימלאו גם את הזיכרון החדש. מורידים עומס קודם.

להתעלם מהתראה יזומה: ההודעה מינואר 2025 הייתה סימן מוקדם. כשקלאודוויז שולחת התראה על OOM, פתחו טיקט ובקשו פירוט.

לחשוב שזה דיסק: גם דיסק מלא מפיל את MySQL, ואצלנו זה קרה בנפרד. בדקו את שניהם, לפי המדריך דיסק מלא ו-inodes.

לא לענות לטיקט: טיקט #981625 נסגר אוטומטית אחרי תזכורות. אם הבעיה חוזרת, ענו לאותו טיקט כדי שההיסטוריה תישמר.

מה הצ'קליסט למניעת קריסות MariaDB?

• בדקו פעם בחודש את גרפי ה-RAM וה-swap. swap מלא באופן קבוע הוא אזהרה.
• ספרו workers של PHP-FPM בסרק עם htop. אם יש עשרות, בקשו מהתמיכה לבדוק את הגדרות ה-pm.
• פזרו משימות מתוזמנות ו-preload בין אתרים, ואל תריצו אותן באותה דקה.
• הפעילו Bot Protection והגבלת קצב ל-admin-ajax.
• עקבו אחרי אתרים שמייצרים הרבה 404 ו-500. אתר אחד יכול להפיל שרת שלם.
• השאירו מרווח: אל תגדילו OPcache ו-buffer pool עד שלא נשאר RAM ל-PHP-FPM. ההגדרות האלה נמצאות במדריך הגדרות שרת בקלאודוויז.

שאלות נפוצות

מדריכים קשורים

• האתר נפל? איך בודקים מה קרה
• שגיאות 502, ‏503 ו-504 בקלאודוויז
• אתר איטי ושימוש גבוה במעבד
• הביקורת שלנו על קלאודוויז
• כל המדריכים בתחום: פתרון תקלות · ניטור

מקורות

• proc_pid_oom_score_adj(5) – Linux manual page
• PHP-FPM Configuration – PHP Manual
• InnoDB Buffer Pool – MariaDB Knowledge Base
• Rate limiting rules – Cloudflare Docs
• How to Monitor the RAM Usage of a Server – Cloudways KB
• How to Monitor System Processes Using htop Command – Cloudways KB
• טיקטים #619034 (29.1.2025), ‏#977464, ‏#978826, ‏#981625 (23–30.9.2026) בחשבון קלאודוויז שלנו

מקור רשמי: How to Monitor the RAM Usage of a Server (Cloudways Knowledge Base). העמוד נכתב ונבדק על ידי עשהאל דרייר · עודכן: 07.11.2026

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