آموزش گام‌به‌گام افزایش حافظهٔ PHP در وردپرس
خطای حافظه در وردپرس از آن دسته مشکلاتی است که با «الان سایت بالا می‌آید، فردا دوباره می‌آید» خودش را نشان میدهد؛ برای همین تیم‌ها مدتی با آن زندگی می‌کنند و در بدترین لحظه — وسط به‌روزرسانی، حین آپلود محصولات فصلی — سایت را از کار می‌اندازد. راه‌حل هم دو لایه دارد که باید با هم دیده شوند: سقف را بالا بردن، و پیدا کردن اینکه چه چیزی سقف را پر کرده است. فقط لایهٔ اول را انجام دهید، مشکل با تأخیر برمی‌گردد؛ فقط لایهٔ دوم را، سایت شما با محدودیت‌های پیش‌فرض نفس می‌زند.
کمبود حافظهٔ PHP چه شکلی خودش را نشان میدهد؟
شناخته‌شده‌ترین چهرهٔ این مشکل، پیام «Fatal error: Allowed memory size … bytes exhausted» است که معمولاً مسیر فایل مقصر را هم کنارش می‌آورد؛ ولی کمبود حافظه چند چهرهٔ خاموش‌تر هم دارد: صفحهٔ سفید بدون پیام، توقف نصفه به‌روزرسانی افزونه‌ها، تکرار خطای ۵۰۰ در لحظه‌های پیک بازدید، و پنل مدیریت که آپلود تصویر بزرگ را رد میکند. وجه مشترک همهٔ این‌ها زمانی بودن است: در ساعت‌های آرام سایت نفس می‌کشد و در پیک، حافظه تمام میشود.
پیش از هر تغییر تنظیمی، دو چیز را ثبت کنید: متن دقیق خطا و تاریخ‌هایی که تکرار شده. اگر پیام خطا مسیر افزونه یا قالب را نشان میدهد، نیمهٔ راه ریشه‌کاوی را رفته‌اید؛ اگر فقط «exhausted» دیدید، مسیر بخش چهارم — آزمون دوجمله‌ای افزونه‌ها — برای شماست. این سابقهٔ مکتوب بعداً مبنای گفت‌وگو با پشتیبانی هاست هم میشود، چون می‌توانید نشان دهید خطا الگوی زمانی دارد، نه تصادفی.
و یک تشخیص تفکیکی مهم: کمبود حافظه را با کمبود حافظهٔ اجرای PHP قاطی نکنید با کمبود فضا یا محدودیت زمان اجرا؛ آن‌ها درمان‌های متفاوتی دارند و جابه‌جایی‌شان، ساعت‌ها تنظیم بی‌اثر می‌سازد.
افزایش حافظه وردپرس در سه لایهٔ تنظیم
افزایش حافظه وردپرس را از نزدیک‌ترین لایه به وردپرس شروع کنید و اگر اثر نکرد، لایهٔ بعدی را بالا ببرید. لایهٔ اول wp-config.php است: ثابت‌های WP_MEMORY_LIMIT و WP_MAX_MEMORY_LIMIT را تعریف یا اصلاح کنید؛ دومی مخصوص بخش مدیریت است و اجازه میدهد کارهای سنگین ادمین — به‌روزرسانی‌ها، آپلودها — حافظهٔ بیشتری بگیرند. لایهٔ دوم تنظیم PHP است: memory_limit در php.ini یا در پنل هاست (بسته به کنترل‌پنل، بخش MultiPHP INI یا تنظیمات مشابه) و در برخی هاست‌ها از طریق .htaccess با دستور php_value. لایهٔ سوم، سقف واقعی سرور است که پشتیبانی هاست آن را می‌بیند.
| لایه | کجا تنظیم میشود | نمونهٔ مقدار رایج |
|---|---|---|
| وردپرس | wp-config.php — WP_MEMORY_LIMIT / WP_MAX_MEMORY_LIMIT | ۱۲۸M / ۲۵۶M |
| PHP | php.ini یا پنل هاست — memory_limit | ۱۲۸M تا ۲۵۶M |
| سرور (سقف واقعی) | فقط با پشتیبانی هاست | بسته به پلن هاست |
مقادیر نمونهٔ رایج‌اند، نه نسخهٔ واحد برای همه؛ با مشخصات پلن هاست خودتان تطبیق دهید.
ترتیب لایه‌ها را رعایت کنید چون هر لایه روی لایهٔ پایین‌تر شرط است: اگر وردپرس ۲۵۶M بخواهد و PHP فقط ۱۲۸M بدهد، همان ۱۲۸M اجرا میشود؛ اگر PHP ۲۵۶M بدهد و سرور در پلن شما سقف کمتری گذاشته باشد، خطا به همان شکل قدیمی برمی‌گردد. بعد از هر تغییر هم یک بار کش‌ها را پاک کنید تا با نتیجهٔ نسخهٔ قبلی داوری نکنید.
سقف واقعی؛ وقتی تنظیم شما به هاست نمی‌رسد
مرز صادقانهٔ این راهنما همین‌جاست: شما فقط تا سقف پلن هاست خود می‌توانید بروید. شماری از پلن‌های اشتراکی سقف memory_limit مشخصی دارند و دستورهای شما از آن بالاتر نمی‌رود؛ نشانه‌اش این است که تنظیم را نوشته‌اید، phpinfo مقدار جدید را نشان میدهد اما خطا در همان حجم قبلی بازمی‌گردد، یا اصلاً مقدار در پنل ذخیره نمیشود. در این وضعیت، تیکت پشتیبانی با همان سابقهٔ مکتوب بخش اول — متن خطا، الگوی زمانی، مقدار درخواستی — سریعترین راه است.
چه وقت ارتقای پلن واقعاً منطقی است؟ وقتی مصرف بالا «درست» است: فروشگاه با کاتالوگ بزرگ، افزونههای سنگینِ ضروری مثل فروشگاه‌ساز یا چندزبانه، و پیک بازدید واقعی. در این حالت حافظهٔ بیشتر، هزینهٔ رشد است نه پوشاندن مشکل. اما اگر سایت کوچکی دارید و مصرفش عجیب بالا رفته، ارتقای پلن فقط مشکل را پرهزینه‌تر جابه‌جا میکند؛ بخش بعدی برای همین حالت است.
یک نکتهٔ قراردادی: قبل از ارتقا، از پشتیبانی بپرسید سقف پلن جدید چقدر است و آیا قابل تنظیم توسط خودتان هست یا هر تغییر تیکت می‌خواهد. دو هاست با «همان حافظه» می‌توانند دو تجربهٔ متفاوت بدهند.
ریشه‌کاوی؛ کدام افزونه حافظه را می‌خورد؟
افزایش سقف بدون پیدا کردن مصرف‌کنندهٔ اصلی، مثل بزرگ‌کردن سطل زیر شیر آب‌باز است. مسیر ریشه‌کاوی سه‌گامی است: اول، وضعیت سلامت سایت (Site Health) در پیشخوان و هر گزارش مصرفی که افزونهٔ پایش یا خود هاست میدهد را ببینید تا باریکهٔ مشکوک را پیدا کنید. دوم، اگر سرنخ روشن نبود، آزمون دوجوله‌ای افزونه‌ها را اجرا کنید: همه را خاموش کنید، خطا را چک کنید، بعد دسته‌دسته روشن کنید تا دوتایی که با روشن‌شدنش خطا برمی‌گردد پیدا شود. سوم، قالب را هم جدا بیازمایید — با یکی از قالب‌های پیش‌فرض وردپرس — چون گاهی مقصر قالب است نه افزونه.
مصرف‌کننده‌های کلاسیک را از قبل بشناسید تا سریع‌تر برسید: تصویرسازی‌های سنگین در لحظهٔ آپلود، ابزارهای صفحه‌ساز با ویرایش‌های مکرر، افزونههای آماری که داده را در حافظه جمع می‌کنند، و چرخه‌های زمان‌بندی‌شدهٔ پشتیبان‌گیری که وسط پیک بازدید می‌افتند. چند مورد از این الگوها را در تمیزکاری دوره‌ای وردپرس با برنامهٔ پاک‌سازی دوره‌ای باز کرده‌ایم؛ مقصر را که پیدا کردید، یا جایگزین سبک‌تر بگذارید یا تنظیماتش را محدود کنید — و فقط در جایی که افزونه واقعاً ضروری و پرمصرف است، سراغ سقف بزرگ‌تر بروید.
هر بار که ریشه را پیدا می‌کنید، یک خط در همان سابقهٔ مکتوب اضافه کنید؛ بعد از دو-سه رخداد، الگوی مصرف سایت شما قابل‌خواندن میشود و تصمیم‌های بعدی — تنظیم، جایگزینی، ارتقا — با داده گرفته میشود، نه با حدس.
حافظه و خطاهای معروف؛ صفحهٔ سفید، ۵۰۰ و خرابی به‌روزرسانی
کمبود حافظه اغلب پشت خطاهایی پنهان است که خودشان راهنمای جداگانه می‌خواهند. صفحهٔ سفید وردپرس — سایتی که بدون پیام خطا خالی میشود — در رفع خطای صفحهٔ سفید وردپرس از حالت نمایش خطا تا بازیابی کامل باز شده؛ کمبود حافظه یکی از متهمان همیشگی آن پرونده است و اگر بعد از بالا بردن سقف، صفحهٔ سفید ادامه داشت، دنبال متهم بعدی بگردید. خطای ۵۰۰ هم همین‌طور است: رفع خطای ۵۰۰ وردپرس مسیر کاملش را میدهد و حافظه فقط یکی از شش-هشت علت معمول آن است.
تفکیک را جدی بگیرید چون درمان‌ها متفاوت‌اند: اگر بالا بردن حافظه خطا را بست، پروندهٔ شما همین بود؛ اگر نست، در همان راهنمای مخصوص هر خطا ادامه بدهید. برای پیدا کردن متن واقعی خطا زیر صفحهٔ سفید، فعال‌کردن موقت نمایش خطا یا دیدن لاگ سرور معمولاً در چند دقیقه متهم را نشان میدهد — و این کار را در فصل آرام انجام دهید، نه وسط کمپین فروش.
پیشگیری و جمع‌بندی
پیشگیری از بازگشت این مشکل، سه عادت کوچک می‌خواهد: افزونههای بی‌استفاده را حذف کنید نه اینکه فقط غیرفعال بگذارید؛ به‌روزرسانی‌های سنگین و پشتیبان‌گیری‌های زمان‌بندی‌شده را در ساعت‌های کم‌بازدید بگذارید؛ و مصرف حافظه را بعد از هر نصب مهم، یک بار چک کنید. این سه عادت در چرخهٔ نگهداری ماهانهٔ وردپرس جا دارند و اگر پذیرفتید که نگهداری، فهرست‌کار است نه واکنش به خطا، هاب نگهداری، مهاجرت و خطاها بقیهٔ فهرست را کنار هم می‌چیند.
جمع‌بندی: افزایش حافظه وردپرس یعنی سه لایهٔ تنظیم به‌ترتیب — wp-config، PHP، سقف هاست — به‌علاوهٔ ریشه‌کاوی مصرف با آزمون دوجوله‌ای؛ و مرز تصمیم هم روشن است: مصرف درستِ کار سنگین، هزینهٔ ارتقای پلن می‌خواهد؛ مصرف عجیبِ سایت کوچک، جایگزینی افزونه. اگر می‌خواهید این چرخه از نگهداری و به‌روزرسانی تا انتشار محتوا خودکار و مأموریت‌محور اجرا شود، پلتفرم سوئیت همین رویه‌ها را پلتفرمی میکند و شما فقط گزارش را می‌بینید. و اگر دوباره همین خطا برگشت، پیش از هر چیز سابقهٔ مکتوب‌تان را باز کنید؛ اغلب پاسخ، در الگوی همان برگه است نه در تنظیم تازه.
رصد ما، رشد شما.
سؤالات پرتکرار
چه مقدار حافظه برای وردپرس کافی است؟
برای سایتهای متوسط، ۱۲۸M نقطهٔ شروع رایج است و ۲۵۶M اغلب خطاهای افزونههای سنگین را میبندد. عدد درست، همان سقفی است که پلن هاست شما بدهد و مصرف واقعی سایت توجیه کند.
افزایش حافظه مشکل را ریشه‌ای حل میکند؟
اگر مصرف بالا درست باشد — کاتالوگ بزرگ، افزونهٔ ضروری سنگین — بله. اگر مصرف عجیب باشد، فقط تأخیر می‌سازد؛ باید افزونهٔ پرمصرف را با آزمون دوجوله‌ای پیدا و جایگزین کنید.
WP_MEMORY_LIMIT را بگذارم یا memory_limit در php.ini؟
هر دو لایهٔ یک زنجیرهاند: وردپرس در wp-config حافظهٔ موردنیازش را درخواست میکند و PHP همانقدر را که سقفش اجازه دهد میدهد. تنظیم را از لایهٔ وردپرس شروع کنید و اگر اثر نکرد به php.ini و سقف هاست بروید.
از کجا بفهمم هاست سقف گذاشته؟
وقتی مقدار جدید در phpinfo دیده میشود اما خطا در همان حجم قبلی تکرار میشود، یا مقدار در پنل ذخیره نمیشود. در این حالت تیکت پشتیبانی با سابقهٔ مکتوب خطاها سریعترین راه است.
