اگر وردپرس پیام Allowed memory size of ... bytes exhausted می‌دهد، یک پردازش PHP نتوانسته حافظه بیشتری تخصیص دهد. اعداد داخل پیام، فایل و خط آخرین allocation سرنخ‌اند؛ اما فایل آخر الزاماً عامل اصلی مصرف نیست. هدف فوری بازگرداندن امن سرویس و هدف اصلی یافتن request، افزونه یا داده پرمصرف است.
اقدام سریع: متن کامل خطا و زمان را ذخیره کنید، backup داشته باشید و مشخص کنید مشکل با چه عملی رخ می‌دهد. اگر سایت از دسترس خارج است، تغییر اخیر را rollback یا افزونه مظنون را کنترل‌شده غیرفعال کنید. افزایش محدود حافظه فقط وقتی RAM کافی است، یک اقدام موقت است؛ نه تشخیص نهایی.
پیام خطا چه می‌گوید؟
PHP Fatal error: Allowed memory size of 268435456 bytes exhausted
(tried to allocate 20480 bytes) in /path/to/file.php on line 123در این نمونه سقف پردازش ۲۵۶ مگابایت بوده و allocation بعدی شکست خورده است. عبارت tried to allocate نشان نمی‌دهد کل مصرف فقط همان مقدار کوچک بوده؛ پردازش پیش‌تر به سقف نزدیک شده است. مسیر را پیش از انتشار عمومی حذف کنید.
اگر کل سایت از کار افتاده است
- خطای فعلی و آخرین تغییر را ثبت کنید.
- از فایل‌ها و دیتابیس نسخه قابل بازیابی داشته باشید.
- اگر خطا بلافاصله پس از فعال‌سازی افزونه رخ داد، همان افزونه را از پنل یا WP-CLI غیرفعال کنید.
- اگر پنل باز نمی‌شود، تغییر نام پوشه افزونه در سطح فایل راه اضطراری است؛ نام اصلی را ثبت و فقط هدف مشخص را تغییر دهید.
- cacheهای opcode و application را طبق روش محیط پاک‌سازی و سایت را smoke test کنید.
wp plugin deactivate plugin-slugplugin-slug باید از فهرست واقعی افزونه‌ها انتخاب شود. همه افزونه‌ها را بی‌هدف غیرفعال نکنید؛ در فروشگاه ممکن است checkout، پرداخت یا jobهای مهم متوقف شوند.
اگر فقط یک عملیات خطا می‌دهد
وقتی صفحه اصلی سالم است ولی import، ساخت PDF، ویرایش با page builder یا پردازش تصویر خطا می‌دهد، ورودی همان عملیات را بررسی کنید. اندازه فایل، تعداد رکورد batch، ابعاد تصویر، پاسخ API و تعداد نتیجه query می‌تواند تعیین‌کننده باشد. عملیات را با نمونه کوچک در staging تکرار کنید.
اگر خطا فقط در cron رخ می‌دهد، نام hook و صف را پیدا کنید. اجرای مکرر job شکست‌خورده ممکن است رکورد تکراری یا فشار بیشتر بسازد. قبل از retry بدانید job قابلیت اجرای دوباره امن دارد یا خیر.
مقدار فعال را از context درست بخوانید
وب‌سایت معمولاً با PHP-FPM یا handler وب اجرا می‌شود، اما SSH ممکن است PHP CLI دیگری داشته باشد. php -i فقط تنظیم CLI همان فرمان را نشان می‌دهد. Site Health و تنظیمات pool برای context وب شاهد مناسب‌تری هستند. از ایجاد صفحه عمومی phpinfo خودداری کنید.
ثابت‌های وردپرس نیز سقف سیستم را همیشه override نمی‌کنند. برای توضیح تفاوت RAM، PHP و ثابت‌ها، راهنمای تمام شدن حافظه PHP وردپرس را بخوانید.
افزایش موقت حافظه در وردپرس
در محیطی که میزبان اجازه می‌دهد، مقدار زیر می‌تواند پیش از خط توقف ویرایش در wp-config.php تعریف شود:
define( 'WP_MEMORY_LIMIT', '256M' );عدد نمونه نسخه عمومی برای همه سایت‌ها نیست. اگر PHP یا hosting سقف دیگری دارد، این ثابت ممکن است بی‌اثر باشد. پیش از تغییر، مقدار جاری و RAM سرور را بسنجید و بعد از تشخیص مقدار موقت را بازبینی کنید. چند تعریف تکراری در فایل نسازید.
تنظیم در PHP-FPM یا هاست
بسته به معماری، مقدار ممکن است در php.ini، تنظیم pool، پنل hosting یا پیکربندی container اعمال شود. فایل و سرویس دقیق هر پروژه متفاوت است؛ یک دستور عمومی برای reload همه محیط‌ها وجود ندارد. ابتدا منبع مؤثر تنظیم را شناسایی و syntax را بررسی کنید، سپس سرویس مرتبط را کنترل‌شده reload کنید.
اگر چند سایت در یک pool هستند، افزایش سقف یک سایت می‌تواند ظرفیت کل را تغییر دهد. تعداد worker، متوسط و peak مصرف، RAM دیتابیس و حاشیه سیستم باید در محاسبه وارد شوند.
چگونه مقصر واقعی را پیدا کنیم؟
- request یا job قابل بازتولید بسازید.
- stack trace و اولین فایل پروژه در مسیر را بررسی کنید.
- نسخه و تغییرات اخیر افزونه و قالب را ثبت کنید.
- روی staging افزونه مظنون یا ورودی بزرگ را isolate کنید.
- query و حجم داده را بررسی و pagination/batching را ارزیابی کنید.
- peak memory را قبل و بعد از تغییر مقایسه کنید.
اگر خطا بعد از update شروع شده، rollback نسخه سازگار در staging از ویرایش مستقیم کد vendor قابل‌اعتمادتر است. برای مشاهده درست خطا بدون نمایش آن به کاربر از ثبت امن debug.log استفاده کنید.
سناریوهای متداول
تصویر بسیار بزرگ
حافظه لازم برای decode تصویر می‌تواند بسیار بیشتر از اندازه فایل فشرده باشد. کاهش ابعاد پیش از upload یا واگذاری پردازش به سرویس مناسب بهتر از بالا بردن نامحدود سقف است.
Import محصول یا محتوا
فایل را batch کنید، mapping و تعداد رکورد را روی staging بیازمایید و قبل از retry اثر رکوردهای نیمه‌واردشده را بررسی کنید.
صفحه‌ساز یا shortcode
ساختار تو در تو، query بدون limit یا recursive rendering ممکن است مصرف را بالا ببرد. صفحه مشکل‌دار را با نسخه ساده مقایسه و component پرمصرف را isolate کنید.
Backup داخل همان PHP request
فشرده‌سازی فایل حجیم در یک request وب می‌تواند هم حافظه و هم زمان اجرا را مصرف کند. ابزار streaming یا job خط فرمان کنترل‌شده ممکن است مناسب‌تر باشد.
چه کارهایی نکنیم؟
- قرار دادن
memory_limit=-1روی production - بالا بردن سقف تا جایی که OOM Killer کل سرویس را متوقف کند
- ویرایش فایل اصلی افزونه بدون مسیر upgrade
- اجرای دوباره import و payment job بدون بررسی idempotency
- نمایش fatal error و مسیر سرور به بازدیدکننده
- فرض اینکه آخرین فایل پیام حتماً منبع leak است
تأیید رفع مشکل
فقط باز شدن صفحه اصلی کافی نیست. همان عملیات قبلی را با ورودی کنترل‌شده اجرا کنید، log تازه را ببینید و peak memory، زمان و نتیجه داده را کنترل کنید. در فروشگاه، checkout و jobهای عقب‌افتاده را نیز بیازمایید. اگر سقف تغییر کرده، اثر آن را زیر concurrency عادی مانیتور کنید.
چه زمانی بررسی حرفه‌ای لازم است؟
اگر پس از غیرفعال‌سازی عامل واضح، مصرف همچنان رشد می‌کند یا افزایش حافظه باعث فشار کل سرور می‌شود، profiling باید خارج از آزمون‌وخطای production انجام شود. سرویس رفع مشکل فنی وردپرس برای ردیابی request، افزونه و ظرفیت PHP-FPM متناسب با همین خطا است.
پرسش‌های متداول
آیا ۲۵۶ مگابایت همیشه کافی است؟
خیر؛ workloadها متفاوت‌اند. عدد باید بر پایه اندازه عملیات، افزونه‌ها و ظرفیت کل تعیین شود.
چرا با تغییر wp-config خطا باقی ماند؟
ممکن است PHP یا میزبان سقف را اعمال کند، تعریف در محل اشتباه باشد یا context خطا CLI/FPM دیگری باشد.
آیا حذف cache مشکل را حل می‌کند؟
فقط اگر داده cacheشده بخشی از علت باشد. پاک‌سازی cache درمان عمومی memory exhaustion نیست.
آیا این خطا همان Critical Error است؟
می‌تواند باعث صفحه Critical Error شود، اما آن پیام عمومی علت‌های دیگری هم دارد؛ لاگ Critical Error علت واقعی را مشخص می‌کند.