وقتی import، ساخت thumbnail، ذخیره صفحه با صفحه‌ساز یا یک job پس‌زمینه متوقف می‌شود، ممکن است همان پردازش PHP به سقف حافظه خود رسیده باشد. این با «پر شدن کل RAM سرور» یکسان نیست: memory_limit برای هر پردازش یا درخواست اعمال می‌شود، در حالی که چند worker هم‌زمان می‌توانند مجموع RAM سیستم را مصرف کنند.
پاسخ سریع: مقدار مجاز و مقدار درخواست‌شده را از پیام fatal error بخوانید، URL یا job ایجادکننده را مشخص کنید و نسخه PHP مربوط به وب را از CLI جدا بدانید. افزایش محدود و حساب‌شده می‌تواند سرویس را موقتاً برگرداند، اما رشد غیرعادی داده، loop یا افزونه معیوب باید رفع شود.
نشانه‌های رایج کمبود حافظه PHP
- پیام
Allowed memory size ... exhaustedدر PHP log - خطای 500 فقط هنگام import، backup یا ویرایش صفحه بزرگ
- موفق بودن صفحه عمومی و شکست wp-admin یا cron
- قطع شدن پردازش تصویر یا تولید فایل خروجی
- Restart شدن worker در کنار log مربوط به حافظه
صفحه سفید یا 500 به تنهایی کمبود حافظه را ثابت نمی‌کند. نخستین fatal error همان request را از لاگ وردپرس و PHP پیدا کنید.
چهار عدد متفاوت را با هم اشتباه نگیرید
| محدودیت/منبع | دامنه اثر | نکته |
|---|---|---|
memory_limit | پردازش PHP | ممکن است بین web و CLI متفاوت باشد |
WP_MEMORY_LIMIT | درخواست‌های معمول وردپرس | نمی‌تواند سقف اجباری میزبان را جادویی رد کند |
WP_MAX_MEMORY_LIMIT | بعضی کارهای مدیریت | مجوز مصرف واقعی همچنان به PHP وابسته است |
| RAM/limit کانتینر | کل سرویس یا سیستم | مجموع workerها و سرویس‌های دیگر را شامل می‌شود |
اگر PHP-FPM با سقف ۲۵۶ مگابایت و چندین worker کار کند، ظرفیت بالقوه فقط یک عدد ۲۵۶ مگابایتی نیست. هر worker الزاماً تا سقف مصرف نمی‌کند، ولی تنظیم تعداد worker بدون توجه به RAM می‌تواند OOM سیستم ایجاد کند.
علت‌های محتمل به ترتیب عملی
- افزونه یا قالبی که داده بسیار بزرگ یا loop ایجاد می‌کند.
- import/export، backup یا پردازش تصویر با batch نامناسب.
- صفحه‌ساز، query یا پاسخ API با حجم غیرعادی.
- تغییر نسخه PHP یا افزونه و افزایش مصرف پس از update.
- تنظیم پایین نسبت به workload واقعی.
- تفاوت تنظیمات CLI، FPM و چند pool یا کانتینر.
- تعداد زیاد worker و فشار حافظه در سطح سیستم.
تشخیص مرحله‌به‌مرحله
- زمان، endpoint، کاربر و عملیات شکست‌خورده را ثبت کنید.
- از پیام خطا مقدار allowed، requested و فایل/خط را بخوانید.
- بررسی کنید خطا در frontend، مدیریت، cron یا WP-CLI رخ داده است.
- نسخه PHP و فایل پیکربندی همان SAPI را مشخص کنید.
- افزونه‌های حاضر در stack trace و آخرین تغییرات را بررسی کنید.
- همان سناریو را با داده کنترل‌شده در staging بازتولید کنید.
- پس از هر اصلاح، peak memory و نتیجه عملیات را دوباره اندازه بگیرید.
فایل ذکرشده در آخرین خط لزوماً مقصر اصلی نیست؛ ممکن است فقط جایی باشد که آخرین allocation انجام شده است. stack trace، حجم ورودی و مسیر فراخوانی را کامل ببینید.
بررسی تنظیم فعال PHP
خروجی php -i یا php --ini مربوط به CLI است و ممکن است با PHP-FPM سایت فرق داشته باشد. برای محیط وب از Site Health، صفحه تشخیصی محافظت‌شده یا تنظیمات pool استفاده کنید. صفحه عمومی phpinfo() ایجاد نکنید؛ جزئیات محیط را افشا می‌کند.
wp eval 'echo ini_get("memory_limit"), PHP_EOL;'
wp eval 'echo size_format( memory_get_peak_usage( true ) ), PHP_EOL;'این فرمان‌ها را در root درست وردپرس و با کاربر مناسب اجرا کنید. اجرای CLI مسیر وب، reverse proxy و request واقعی را بازسازی نمی‌کند؛ نتیجه فقط یک شاهد تکمیلی است.
راه‌حل کم‌ریسک تا پیشرفته
۱. عملیات را کوچک‌تر کنید
در import، تصویر یا پردازش صف، batch را کاهش دهید و فایل بسیار بزرگ را بخش‌بندی کنید. پیش از حذف داده یا اجرای دوباره job مطمئن شوید عملیات idempotent است.
۲. تغییر اخیر را isolate کنید
اگر مشکل بعد از update آغاز شده، نسخه‌ها و log را ثبت و افزونه مظنون را در staging آزمایش کنید. برای سایت ازکارافتاده از روش امن تغییر نام پوشه یا WP-CLI استفاده کنید، اما وضعیت و مسیر rollback را نگه دارید؛ راهنمای خرابی پس از آپدیت افزونه جزئیات بیشتری دارد.
۳. سقف را موقت و حساب‌شده تغییر دهید
فقط وقتی workload مشروع است و RAM ظرفیت دارد، مقدار را در لایه مؤثر همان محیط تنظیم کنید. روی هاست مدیریت‌شده ممکن است پنل یا پشتیبانی میزبان مرجع باشد. تغییر چند فایل مختلف هم‌زمان تشخیص منبع تنظیم را دشوار می‌کند.
۴. کد یا query پرمصرف را اصلاح کنید
بارگذاری همه رکوردها در حافظه، پاسخ API بدون pagination، تصویر بسیار بزرگ و cache کردن object حجیم باید در طراحی اصلاح شود. profiler و instrumentation را روی staging به کار ببرید و فقط میانگین مصرف را نبینید؛ peak مهم است.
چه مقدار حافظه مناسب است؟
یک عدد جهانی برای همه سایت‌ها وجود ندارد. قالب، افزونه‌ها، اندازه تصویر، import و concurrency متفاوت‌اند. مقدار باید به اندازه اجرای workload معتبر باشد و در کنار تعداد worker، RAM دیتابیس، cache و حاشیه امن سیستم محاسبه شود. سقف بسیار بالا می‌تواند bug را پنهان کند و هنگام ترافیک، چند worker کل سرور را تحت فشار بگذارند.
اشتباه‌های رایج
- تنظیم
-1یا سقف بسیار بزرگ روی production - فرض اینکه مقدار CLI همان PHP-FPM است
- افزایش worker و memory_limit به‌طور هم‌زمان
- نادیده گرفتن فایل، خط و request ذکرشده در fatal error
- اجرای دوباره import یا سفارش بدون بررسی اثر تکرار
- نصب افزونه بهینه‌ساز برای درمان هر نوع memory leak
پیشگیری
روی staging آزمون update و import داشته باشید، jobهای بزرگ را batch کنید و مصرف workerها، restart و OOM را مانیتور کنید. برای کارهای زمان‌بر، timeout و memory را همراه هم نبینید: بالا بردن یکی الزاماً دیگری را حل نمی‌کند. پس از رخداد، ورودی و نسخه‌های دقیق را در گزارش فنی ثبت کنید.
چه زمانی کمک تخصصی لازم است؟
اگر مصرف بعد از افزایش منطقی دوباره رشد می‌کند، فقط در checkout یا cron رخ می‌دهد، یا سرویس با OOM متوقف می‌شود، ادامه آزمون روی production مناسب نیست. سرویس رفع مشکل فنی وردپرس می‌تواند request پرمصرف را از PHP تا افزونه و ظرفیت سرور ردیابی کند.
پرسش‌های متداول
آیا افزایش WP_MEMORY_LIMIT همیشه اثر می‌کند؟
خیر؛ میزبان یا PHP ممکن است سقف پایین‌تری اعمال کند و تنظیم در context اشتباه خوانده شود.
آیا کمبود حافظه PHP یعنی RAM سرور پر است؟
نه الزاماً. یک request می‌تواند به سقف خود برسد در حالی که RAM آزاد است؛ حالت معکوس نیز ممکن است.
چرا فقط پیشخوان خطا می‌دهد؟
کارهای مدیریت، گزارش، صفحه‌ساز یا import ممکن است داده بیشتری از صفحات cacheشده عمومی پردازش کنند.