OPcache מלא בוורדפרס: איך מגדילים ולמה ההגדרה בפאנל לא תמיד נקלטת

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

בקצרה: OPcache מלא בוורדפרס אומר שהזיכרון שבו PHP שומר קוד מקומפל נגמר, ולכן כל בקשה מקמפלת קבצים מחדש. בשרתים שלנו בקלאודוויז (Cloudways), עם כ-60 אתרים על PHP 8.4, אחוז הפגיעה בקאש ירד ל-4% עד 71%. אחרי שהתמיכה הגדילה את OPcache ל-4096MB, את ה-interned strings ל-256MB ואת מגבלת הקבצים ל-400,000, הוא עלה מכ-56% ל-98% (אוקטובר 2026).

⏱ זמן בדיקה: 15 דקות · תיקון דרך התמיכה: 1–4 ימים אצלנו · רמת קושי: מתקדם · נבדק לאחרונה מול הטיקטים שלנו: 07.11.2026

העמוד הזה מבוסס על ארבע פניות תמיכה אמיתיות שפתחנו בקלאודוויז בספטמבר ובאוקטובר 2026 (טיקטים #978826, #983494, #983655, #988333). מספרי הטיקטים, התאריכים וזמני התגובה לקוחים מהמיילים של מערכת הפניות.

מה זה OPcache ולמה הוא חשוב לוורדפרס?

OPcache הוא רכיב מובנה ב-PHP ששומר בזיכרון משותף את הקוד אחרי קומפילציה. בלי OPcache, כל בקשה קוראת מהדיסק ומקמפלת מחדש מאות קבצי PHP של וורדפרס, התבנית והתוספים.

אחוז הפגיעה (hit rate) הוא החלק מהבקשות לקבצים שנענו מהזיכרון. בשרת בריא הוא קרוב ל-100%. כשהוא יורד, השרת עובד קשה יותר על כל דף שלא מגיע מקאש הדפים, כולל לוח הבקרה של וורדפרס וקופת ווקומרס.

שלוש הגדרות קובעות אם OPcache מספיק. לפי התיעוד הרשמי של PHP, ברירות המחדל הן:

הגדרה	מה היא קובעת	ברירת מחדל ב-PHP	מה עבד אצלנו (כ-60 אתרים)
opcache.memory_consumption	גודל הזיכרון המשותף לקוד מקומפל, ב-MB	128	4096
opcache.interned_strings_buffer	זיכרון למחרוזות שחוזרות בקוד (שמות פונקציות, מפתחות)	8	256
opcache.max_accelerated_files	כמה קבצים (מפתחות) נכנסים לטבלה	10000	400000

פרט שקל לפספס: PHP מעגל את max_accelerated_files למעלה למספר הראשוני הבא מרשימה קבועה. 10,000 הופך בפועל ל-16,229, ו-400,000 הופך ל-524,521. המקסימום הוא 1,000,000.

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

הבעיה הופיעה בשני שרתים שמחזיקים עשרות אתרי וורדפרס של לקוחות. האתרים היו איטיים דווקא בדפים שלא נשמרים בקאש, וזמני תגובה של 2.7 עד 13 שניות חזרו שוב ושוב.

1. 23.9.2026, טיקט #977464: בזמן בדיקה של קריסות מסד נתונים ראינו ש-max_accelerated_files עמד על 10,000. זה מעט מדי לעשרות אתרים, כי כל אתר וורדפרס עם תוספים מוסיף אלפי קבצי PHP (הערכה שלנו). התמיכה ענתה תוך כ-21 דקות, אבל ההגדרה נדחתה לטיקט אחר.
2. 25.9.2026, טיקט #978826: הגדלנו את OPcache בפאנל, וכלום לא השתנה. התמיכה מצאה שקובץ ini נפרד של PHP 8.4 קבע 128MB באופן קשיח. אחוז הפגיעה היה כ-4%. תגובה ראשונה: כ-3.3 שעות, והתיקון בוצע.
3. 2.10.2026, טיקט #983494 (שרת שני): בפאנל נשמר 1536MB, והשרת עדיין רץ עם 1024MB. ה-interned strings היו מלאים ב-64MB ואחוז הפגיעה כ-55%. תגובה ראשונה: כ-1.5 שעות, עם תשובה קצרה שהשינויים בוצעו.
4. 3.10.2026, טיקט #983655: OPcache של 1GB היה מלא ב-100% וחולק בין כ-60 אפליקציות על PHP 8.4. התברר שהשינוי הקודם נעשה על PHP 8.2, בזמן שכל האתרים רצו על 8.4. גם 2GB התמלא תוך דקות. ההגדרה הסופית: 4096MB, ‏256MB ל-interned strings ו-400,000 קבצים, עם טעינה מחדש עדינה (graceful reload). אחוז הפגיעה עלה מכ-56% לכ-98%. תגובה ראשונה תוך כ-1.3 שעות, והפתרון אחרי כ-4 תגובות המשך במשך 4 ימים.
5. 10.10.2026, טיקט #988333: בקשה נוספת ל-2048MB נשלחה במייל מכתובת שאינה כתובת החשבון, והמערכת דחתה אותה אוטומטית. הבעיה עצמה כבר נפתרה בטיקטים הקודמים.

השורה התחתונה מהסיפור: הערך בפאנל לא מבטיח שזה הערך שרץ בפועל. בדקו תמיד מה PHP-FPM עצמו מדווח.

למה ההגדרה בפאנל לא תמיד נקלטת?

בטיקטים שלנו היו שתי סיבות. הראשונה: קובץ הגדרות נפרד לגרסת PHP מסוימת (8.4) שדרס את הערך מהפאנל. השנייה: שינוי שבוצע על גרסת PHP אחרת מזו שהאתרים רצים עליה בפועל.

לפי מאמר הגדרות השרת של קלאודוויז, ברירת המחדל של Opcache Memory בפאנל היא 64MB, וההמלצה לשרת של 4GB ומעלה היא פחות מ-1024MB. ההמלצה הזו מתאימה לשרת עם מעט אתרים. בשרת שלנו, עם כ-60 אתרים, 1GB התמלא ב-100%, ולכן ביקשנו מהתמיכה ערכים גבוהים יותר.

איך בודקים אם OPcache מלא? מתוך PHP-FPM, לא מ-SSH

הבדיקה הנכונה רצה בתוך האתר, דרך PHP-FPM. הפקודה php -i בטרמינל מראה את הגדרות ה-CLI, שהוא תהליך נפרד ועלול לקבל הגדרות אחרות. הפונקציה opcache_get_status מחזירה את המצב של הזיכרון המשותף.

1. התחברו ב-SFTP או ב-SSH בקלאודוויז לתיקיית public_html של אחת האפליקציות.
2. צרו קובץ עם שם אקראי וקשה לניחוש, למשל oc-check-7f3k2.php, עם הקוד: <?php $s = opcache_get_status(false); echo json_encode(['full' => $s['cache_full'], 'mem' => $s['memory_usage'], 'strings' => $s['interned_strings_usage'], 'hit' => $s['opcache_statistics']['opcache_hit_rate'], 'keys' => $s['opcache_statistics']['num_cached_keys'], 'max_keys' => $s['opcache_statistics']['max_cached_keys'], 'oom' => $s['opcache_statistics']['oom_restarts']]);
3. פתחו את הקובץ בדפדפן ורשמו את התוצאות.
4. מחקו את הקובץ מיד. הוא חושף מידע על השרת.

מה רואים	מה זה אומר
full = true	הזיכרון נגמר. הגדילו memory_consumption
strings: free_memory קרוב ל-0	interned strings מלא. הגדילו interned_strings_buffer
keys קרוב ל-max_keys	מגבלת הקבצים נגמרה. הגדילו max_accelerated_files
oom גדול מ-0 ועולה	OPcache מתאפס כי אין מקום. זה מוחק את כל הקאש
hit מתחת ל-90%	בדקו את שלושת הסעיפים הקודמים
mem.used_memory לא תואם לערך בפאנל	ההגדרה לא נקלטה. פנו לתמיכה עם הנתון

איך מגדילים OPcache בקלאודוויז, שלב אחר שלב?

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

1. היכנסו לפאנל הניהול, בחרו את השרת, ותחת Server Management בחרו Settings & Packages.
2. מצאו את השדה Opcache Memory, בחרו ערך גבוה יותר ולחצו Save Changes. פירוט על שאר השדות יש במדריך הגדרות שרת בקלאודוויז.
3. חכו כמה דקות והריצו שוב את בדיקת ה-PHP-FPM מהסעיף הקודם.
4. אם used_memory ו-buffer_size לא השתנו, או שאתם צריכים interned strings או max_accelerated_files, פתחו פנייה לתמיכה מתוך הפאנל.
5. בפנייה ציינו את גרסת ה-PHP שהאתרים רצים עליה בפועל, את הפלט של opcache_get_status ואת הערכים המבוקשים. בקשו טעינה מחדש עדינה (graceful reload) של PHP-FPM.
6. אחרי התשובה, בדקו שוב בעצמכם. אצלנו נדרשו כמה סבבים עד שהערכים הנכונים רצו על הגרסה הנכונה.

תבנית לפנייה באנגלית: "All apps on this server run PHP 8.4. opcache_get_status from inside PHP-FPM shows cache_full=true, memory 1024MB, hit rate 55%. Please set opcache.memory_consumption, opcache.interned_strings_buffer and opcache.max_accelerated_files for the PHP 8.4 FPM pools to the values below and do a graceful reload."

כמה OPcache צריך? אל תעתיקו את המספרים שלנו

4096MB התאים לשרת עם כ-60 אתרים על אותה גרסת PHP. לאתר אחד או לכמה אתרים זה בזבוז, כי הזיכרון הזה נלקח מה-RAM של השרת ולא נשאר ל-MariaDB ול-PHP-FPM.

• אתר אחד או שניים: התחילו מהערכים שהפאנל ממליץ עליהם לפי גודל השרת, ובדקו.
• שרת סוכנות עם עשרות אתרים: הגדילו בהדרגה. אצלנו גם 2GB התמלא תוך דקות.
• הכלל: הגדילו עד ש-cache_full נשאר false ו-oom_restarts לא עולה יום שלם. יותר מזה לא מוסיף כלום.

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

אילו טעויות נפוצות מונעות מ-OPcache לעבוד?

בדיקה מה-CLI: ‏php -i בטרמינל לא מראה את מה שהאתר מקבל. בודקים מתוך קובץ PHP שרץ באתר.

שינוי בגרסת PHP הלא נכונה: אצלנו השינוי בוצע על 8.2 כשהאתרים רצו על 8.4. בדקו את הגרסה של כל אפליקציה לפני הפנייה, לפי המדריך שינוי גרסת PHP.

הגדלת זיכרון בלי מגבלת הקבצים: אם max_accelerated_files נשאר 10,000, הזיכרון יכול להיות חצי ריק והקאש עדיין "מלא" מבחינת מפתחות.

לבלבל בין OPcache לקאש אובייקטים: OPcache שומר קוד. Redis ו-Object Cache Pro שומרים תוצאות של שאילתות. שניהם נחוצים, ואחד לא מחליף את השני.

מייל לתמיכה מכתובת אחרת: טיקט #988333 נדחה כי נשלח מכתובת שאינה כתובת החשבון. פתחו פניות מתוך הפאנל.

מה הצ'קליסט למניעה?

• אחרי כל שינוי בגרסת PHP, הריצו שוב את בדיקת opcache_get_status.
• אחרי הוספה של כמה אתרים לאותו שרת, בדקו num_cached_keys מול max_cached_keys.
• שמרו את כל האתרים בשרת על אותה גרסת PHP כשאפשר. כך יש פחות מאגרי הגדרות לנהל.
• רשמו את הערכים שהתמיכה הגדירה, עם תאריך ומספר טיקט. אם משהו מתאפס אחרי עדכון, יש לכם הוכחה.
• עקבו אחרי זמני דפים בלי קאש ב-ניטור האפליקציה. קפיצה פתאומית היא לפעמים OPcache שהתמלא.

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

שאלות נפוצות

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

• שגיאת Error Establishing a Database Connection
• הגדרות PHP לאפליקציה בקלאודוויז
• למה wp-admin איטי גם כשהאתר מהיר
• אתר איטי ושימוש גבוה במעבד
• כל המדריכים בתחום: ביצועים ומהירות · הגדרות שרת

מקורות

• OPcache Runtime Configuration – PHP Manual
• opcache_get_status – PHP Manual
• How to Manage Your Server Settings – Cloudways KB
• How to Customize PHP Settings for Your Application – Cloudways KB
• טיקטים #977464, #978826, #983494, #983655, #988333 בחשבון קלאודוויז שלנו, 23.9–10.10.2026

מקור רשמי: How to Manage Your Server Settings (Cloudways Knowledge Base). העמוד נכתב ונבדק על ידי עשהאל דרייר · עודכן: 07.11.2026

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