بالا رفتن مصرف CPU یکی از مشکلاتی است که ممکن است در هر سایت وردپرسی دیده شود؛ از یک سایت محتوایی گرفته تا فروشگاه‌های WooCommerce. گاهی این اتفاق فقط برای چند دقیقه رخ می‌دهد و گاهی مصرف پردازنده برای مدت طولانی بالا می‌ماند و روی عملکرد سایت تأثیر می‌گذارد.
اما مصرف بالای CPU همیشه به این معنی نیست که هاست ضعیف است.
یک افزونه، اجرای بیش از حد Cron Jobها، درخواست‌های ربات‌ها، Queryهای سنگین دیتابیس یا حتی یک پردازش پس‌زمینه میتواند باعث افزایش مصرف منابع شود.
به همین دلیل قبل از ارتقای هاست یا افزایش منابع، بهتر است مشخص کنیم CPU دقیقاً کجا مصرف میشود.
افزایش منابع بدون پیدا کردن علت مصرف CPU ممکن است فقط مشکل را برای مدتی پنهان کند. اگر یک پردازش غیرعادی دائماً منابع مصرف کند، با افزایش CPU نیز احتمال بازگشت مشکل وجود دارد.
| موضوع | خلاصه |
|---|---|
| مشکل اصلی | بالا رفتن مصرف CPU وردپرس |
| دلایل رایج | افزونه‌ها، WP-Cron، Queryهای سنگین، ربات‌ها و Cache نامناسب |
| در ووکامرس | پردازش سفارش‌ها و Action Scheduler هم میتوانند منابع مصرف کنند |
| روش تشخیص | بررسی لاگ‌ها، Queryها، Cron Jobs و درخواست‌های پرتکرار |
| راه‌حل | ابتدا عامل مصرف را پیدا کنید؛ سپس بهینه‌سازی یا ارتقای منابع |
| نکته مهم | CPU بالا همیشه به معنی ضعیف بودن هاست نیست |
CPU در هاست وردپرس چه کاری انجام می‌دهد؟
تقریباً هر Request که نیاز به پردازش سمت سرور داشته باشد میتواند بخشی از منابع CPU را درگیر کند.
وقتی کاربری صفحه‌ای از سایت را باز می‌کند، بسته به ساختار سایت ممکن است PHP اجرا شود، WordPress بارگذاری شود، افزونه‌ها اجرا شوند، اطلاعاتی از دیتابیس خوانده شود و در نهایت پاسخ برای کاربر تولید شود.
البته اگر Page Cache به‌درستی کار کند، بسیاری از این مراحل برای صفحات Cache شده تکرار نمی‌شوند.
اما همه درخواست‌ها قابل Cache نیستند.
برای مثال:
- ورود به مدیریت وردپرس
- بعضی درخواست‌های AJAX
- WP-Cron
- REST API
- پردازش‌های پس‌زمینه
- درخواست کاربران واردشده
- بخش‌هایی از WooCommerce مثل Cart و Checkout
ممکن است همچنان به اجرای PHP و پردازش سمت سرور نیاز داشته باشند.
بنابراین بالا بودن مصرف CPU لزوماً به تعداد بازدید صفحه محدود نمیشود.
چه چیزهایی باعث مصرف بالای CPU در وردپرس میشوند؟
علت واحدی برای این مشکل وجود ندارد. در بسیاری از سایت‌ها حتی ترکیبی از چند عامل باعث افزایش مصرف منابع میشود.
در ادامه مهم‌ترین موارد را بررسی می‌کنیم.
۱. افزونههای سنگین یا دارای پردازش زیاد
تعداد افزونههای نصب‌شده به‌تنهایی معیار مناسبی برای تشخیص مصرف منابع نیست.
ممکن است سایتی ۳۰ افزونه داشته باشد و مشکلی ایجاد نشود، اما یک افزونه با اجرای Queryهای سنگین یا پردازش مکرر باعث افزایش قابل توجه CPU شود.
افزونه‌هایی که عملیات زیر را زیاد انجام می‌دهند بیشتر باید بررسی شوند:
- پردازش و تولید گزارش
- اسکن امنیتی
- تهیه Backup
- Import و Export اطلاعات
- پردازش تصاویر
- ایجاد درخواست‌های مکرر AJAX
- اجرای Jobهای پس‌زمینه
- ارتباط مکرر با APIهای خارجی
بنابراین به‌جای تمرکز صرف روی تعداد افزونه‌ها باید رفتار آنها بررسی شود.
۲. اجرای بیش از حد WP-Cron
WordPress برای اجرای کارهای زمان‌بندی‌شده از سیستمی به نام WP-Cron استفاده می‌کند.
افزونه‌ها میتوانند از آن برای کارهایی مثل ارسال ایمیل، پاک‌سازی اطلاعات، انتشار مطالب زمان‌بندی‌شده و بسیاری از پردازش‌های پس‌زمینه استفاده کنند.
مشکل زمانی ایجاد میشود که تعداد زیادی Event ایجاد شده باشد یا یک افزونه Jobهایی را با فاصله زمانی بسیار کوتاه اجرا کند.
در چنین شرایطی ممکن است پردازش‌های Cron مرتب PHP و دیتابیس را درگیر کنند.
در سایت‌های پرترافیک معمولاً بهتر است وضعیت WP-Cron بررسی شود و در صورت نیاز اجرای آن با Cron واقعی سمت سرور مدیریت شود.
۳. Queryهای سنگین دیتابیس
WordPress برای بخش بزرگی از اطلاعات خود به دیتابیس وابسته است.
نوشته‌ها، تنظیمات، کاربران، اطلاعات افزونه‌ها و بسیاری از داده‌های WooCommerce در دیتابیس قرار دارند.
فرض کنید یک افزونه برای نمایش یک بخش از سایت Query سنگینی اجرا کند که بررسی آن ۵۰۰ میلی‌ثانیه زمان ببرد.
اگر این Query در تعداد زیادی Request اجرا شود، فشار ایجادشده دیگر فقط مشکل «دیتابیس» نیست و میتواند منابع پردازشی سرور را نیز درگیر کند.
جدول‌های بزرگ، Queryهای بهینه‌نشده، داده‌های اضافی و بعضی ساختارهای Meta میتوانند این مشکل را شدیدتر کنند.
افزونه‌هایی مانند Query Monitor برای پیدا کردن Queryهای کند در WordPress بسیار مفید هستند.
۴. درخواست‌های زیاد admin-ajax.php
فایل admin-ajax.php برای انجام بسیاری از درخواست‌های AJAX وردپرس استفاده میشود.
وجود درخواست به این فایل طبیعی است.
مشکل زمانی است که یک قالب یا افزونه در فاصله‌های بسیار کوتاه تعداد زیادی درخواست AJAX ارسال کند.
مثلاً اگر یک افزونه هر چند ثانیه یک Request جدید ایجاد کند، با افزایش تعداد کاربران این درخواست‌ها میتوانند به تعداد قابل توجهی برسند.
در DevTools مرورگر و Access Log سرور می‌توان تعداد و رفتار این درخواست‌ها را بررسی کرد.
۵. Heartbeat API وردپرس
Heartbeat API امکان ارتباط دوره‌ای مرورگر با WordPress را فراهم می‌کند و قابلیت‌هایی مثل Autosave و اطلاع از وضعیت ویرایش نوشته‌ها از آن استفاده میکنند.
خود Heartbeat یک مشکل نیست.
اما در شرایطی که تعداد زیادی کاربر وارد پنل مدیریت باشند یا افزونه‌ای از Heartbeat استفاده زیادی کند، تعداد درخواست‌های ایجادشده میتواند افزایش پیدا کند.
به همین دلیل غیرفعال کردن کامل Heartbeat معمولاً اولین راه‌حل خوبی نیست؛ ابتدا باید مشخص شود آیا واقعاً سهم قابل توجهی در مصرف منابع دارد یا خیر.
۶. Bot Traffic؛ بازدیدی که در Analytics نمی‌بینید
یکی از دلایلی که گاهی نادیده گرفته میشود، ترافیک ربات‌هاست.
ممکن است Analytics عدد خاصی نشان ندهد، اما سرور هزاران Request از Botها دریافت کند.
این درخواست‌ها میتوانند شامل موارد مختلفی باشند:
- wp-login.php
- xmlrpc.php
- صفحات جستجو
- URLهای نامعتبر
- REST API
- صفحات محصول
یا تلاش برای پیدا کردن آسیب‌پذیری‌های شناخته‌شده.
اگر این درخواست‌ها قبل از رسیدن به WordPress توسط CDN، WAF یا لایه‌های امنیتی کنترل نشوند، ممکن است PHP برای بخش قابل توجهی از آنها اجرا شود.
ترافیک کم در Google Analytics الزاماً به معنی Request کم روی سرور نیست. برای تشخیص Bot Traffic باید Logهای وب‌سرور را هم بررسی کرد.
این یکی از دلایلی است که بررسی Access Log در مشکلات مصرف CPU اهمیت زیادی دارد.
۷. WooCommerce و پردازش‌های Dynamic
WooCommerce نسبت به یک سایت محتوایی ساده رفتار متفاوتی دارد.
بخش‌هایی مانند:
- Cart
- Checkout
- My Account
پردازش سفارش - Webhook
- پرداخت
- Session
معمولاً نمی‌توانند دقیقاً مانند یک صفحه مقاله Cache شوند.
از طرف دیگر WooCommerce و افزونههای مرتبط میتوانند Jobهای پس‌زمینه نیز داشته باشند.
برای مثال Action Scheduler توسط WooCommerce و بسیاری از افزونههای آن برای مدیریت کارهای زمان‌بندی‌شده استفاده میشود.
اگر صف بزرگی از Actionها ایجاد شده باشد یا یک Action مرتب Fail شود و دوباره اجرا شود، میتواند هم دیتابیس و هم منابع پردازشی را درگیر کند.
۸. نداشتن Cache یا درست کار نکردن آن
فرض کنید یک صفحه WordPress برای تولید HTML نیاز به اجرای PHP و ۷۰ Query دیتابیس داشته باشد.
اگر Page Cache فعال باشد، ممکن است نتیجه این پردازش ذخیره شود و درخواست بعدی بدون اجرای مجدد تمام مراحل پاسخ داده شود.
اما اگر Cache به هر دلیلی MISS شود، PHP دوباره باید صفحه را تولید کند.
به همین دلیل صرفاً نصب بودن یک افزونه Cache به معنی درست کار کردن Cache نیست.
مواردی مانند:
- Cache HIT/MISS
- صفحات Exclude شده
- کاربران Logged-in
- Cookieها
- Query Stringها
- تنظیمات CDN
باید در صورت وجود مشکل بررسی شوند.
۹. حملات Brute Force و درخواست‌های مخرب
گاهی افزایش CPU اصلاً از کاربران واقعی سایت نیست.
تعداد زیادی Request به wp-login.php، xmlrpc.php یا Endpointهای دیگر میتواند باعث اجرای مکرر WordPress شود.
در این شرایط افزونه امنیتی داخل WordPress میتواند مفید باشد، اما یک نکته وجود دارد:
اگر Request ابتدا به PHP و WordPress رسیده باشد، بخشی از منابع سرور قبل از Block شدن درخواست مصرف شده است.
اینجاست که WAF سمت سرور یا لایه Edge اهمیت بیشتری پیدا می‌کند؛ زیرا بخشی از درخواست‌های مخرب میتوانند قبل از رسیدن به WordPress متوقف شوند.
۱۰. واقعاً منابع هاست کافی نیست
تا اینجا بیشتر درباره مشکلات نرم‌افزاری صحبت کردیم، اما گاهی هیچ رفتار غیرعادی وجود ندارد و سایت واقعاً به منابع بیشتری نیاز دارد.
مثلاً سایتی که قبلاً روزانه ۵۰۰ بازدید داشته ممکن است اکنون چند هزار بازدید داشته باشد.
یا سایتی که ابتدا یک وب‌سایت ساده بوده، بعداً تبدیل شده باشد به سایتی با:
WooCommerce، افزونههای بیشتر، کاربران واردشده و پردازش‌های پس‌زمینه.
در چنین شرایطی افزایش مصرف منابع طبیعی است.
اگر پس از بررسی مشخص شود پردازش غیرعادی وجود ندارد و سایت مرتب به محدودیت منابع می‌رسد، احتمالاً زمان بررسی پلن بالاتر یا سرویس میزبانی مناسب‌تر رسیده است.
در این شرایط بهتر است هنگام انتخاب هاست وردپرس فقط فضای دیسک را در نظر نگیرید و CPU، RAM و محدودیت‌های پردازشی سرویس را نیز بررسی کنید.
چطور علت مصرف بالای CPU وردپرس را پیدا کنیم؟
اینجا مهم‌ترین بخش ماجراست.
به‌جای اینکه تصادفی افزونه‌ها را غیرفعال کنیم یا بلافاصله هاست را ارتقا دهیم، بهتر است مرحله‌به‌مرحله جلو برویم.
| چیزی که بررسی می‌کنیم | دنبال چه چیزی هستیم؟ | ابزار یا محل بررسی |
|---|---|---|
| Access Log | Requestهای پرتکرار، Bot و URLهای مشکوک | لاگ وب‌سرور |
| PHP | پردازش‌های طولانی یا پرتعداد | Resource Monitoring |
| Database | Queryهای کند و پرتکرار | Query Monitor / Slow Query Log |
| WP-Cron | Eventهای پرتکرار یا غیرعادی | WP-CLI / Cron Manager |
| AJAX | درخواست زیاد به admin-ajax.php | DevTools / Access Log |
| WooCommerce | Actionهای Pending یا Failed | Scheduled Actions |
| Cache | HIT/MISS و صفحات بدون Cache | Header / Cache Logs |
| افزونه‌ها | پردازش غیرعادی یک Plugin | Query Monitor / تست کنترل‌شده |
از Access Log شروع کنید
Access Log یکی از بهترین نقاط شروع است.
اگر CPU مثلاً ساعت ۱۴:۳۰ بالا رفته، بررسی کنید در همان بازه چه URLهایی بیشترین Request را دریافت کرده‌اند.
ممکن است ناگهان متوجه شوید هزاران Request به یک Endpoint خاص ارسال شده است.
این اطلاعات مسیر بررسی را کاملاً تغییر می‌دهد.
Query Monitor را بررسی کنید
Query Monitor فقط برای بررسی Query نیست.
این افزونه میتواند اطلاعات مفیدی درباره:
- Database Queries
- HTTP API Calls
- Hooks
- PHP Errors
- Scripts
- Styles
ارائه دهد.
اگر یک افزونه در هر Page Load ده‌ها Query اضافه می‌کند، معمولاً در این مرحله سرنخ خوبی پیدا خواهید کرد.
البته بهتر است ابزارهای Debug و Profiling را روی سایت Production با احتیاط استفاده کنید.
Scheduled Actions ووکامرس را بررسی کنید
اگر WooCommerce دارید از مسیر مربوط به Scheduled Actions وضعیت Actionها را بررسی کنید.
وجود تعدادی Action کاملاً طبیعی است.
اما اگر تعداد بسیار زیادی Action با وضعیت:
Pending
یا:
Failed
وجود دارد، باید بررسی شود چه افزونه یا فرآیندی آنها را ایجاد کرده است.
صرفاً پاک کردن جدول‌ها بدون پیدا کردن علت ایجاد Actionها راه‌حل مناسبی نیست.
CPU بالا همیشه یعنی هاست ضعیف است؟
خیر. این یکی از مهم‌ترین اشتباهاتی است که هنگام بررسی Performance اتفاق می‌افتد.
فرض کنید یک افزونه هر دقیقه یک پردازش سنگین اجرا می‌کند.
اگر CPU سرویس را دو برابر کنیم، احتمالاً سایت مدتی وضعیت بهتری خواهد داشت؛ اما همان پردازش همچنان وجود دارد.
از طرف دیگر اگر سایت واقعاً رشد کرده باشد، حتی یک WordPress کاملاً بهینه نیز بالاخره به منابع بیشتری نیاز پیدا می‌کند.
بنابراین باید بین این دو وضعیت تفاوت قائل شویم:
| وضعیت | اقدام منطقی |
|---|---|
| پردازش غیرعادی وجود دارد | پیدا کردن و رفع علت |
| Bot Traffic زیاد است | کنترل ترافیک در WAF/CDN |
| Query سنگین وجود دارد | بررسی Database/Application |
| Cache درست کار نمیکند | اصلاح Cache |
| Cron غیرعادی است | بررسی Scheduled Jobs |
| سایت سالم است ولی منابع دائماً پر میشوند | بررسی ارتقای سرویس |
آیا افزایش RAM مشکل CPU را حل می‌کند؟
الزاماً نه. CPU و RAM دو منبع متفاوت هستند.
افزایش RAM زمانی کمک می‌کند که محدودیت حافظه بخشی از Bottleneck باشد.
اما اگر مشکل اصلی یک Query سنگین، اجرای بیش از حد PHP یا تعداد زیاد Request باشد، اضافه کردن RAM الزاماً مصرف CPU را کاهش نمی‌دهد.
همین موضوع درباره ارتقای CPU هم وجود دارد.
افزایش منابع میتواند ظرفیت پردازش سایت را بیشتر کند، اما جایگزین پیدا کردن پردازش غیرعادی نیست.
چه زمانی باید هاست وردپرس را ارتقا دهیم؟
اگر موارد غیرعادی بررسی شده‌اند، Cache درست کار می‌کند، Bot Traffic کنترل شده و افزونه یا Query مشکل‌داری وجود ندارد، اما سایت همچنان در ساعات پرترافیک به محدودیت منابع می‌رسد، احتمالاً ظرفیت سرویس فعلی کافی نیست.
نشانه‌هایی مثل:
- رسیدن مداوم CPU به Limit
- افزایش Response Time هنگام ترافیک
- ایجاد خطا هنگام افزایش کاربران هم‌زمان
- کند شدن پردازش‌های Dynamic
- رشد پایدار بازدید و پردازش‌های سایت
میتوانند نشان دهند زمان بررسی منابع بیشتر رسیده است.
نکته مهم این است که انتخاب پلن بالاتر باید بر اساس مصرف واقعی سایت انجام شود، نه صرفاً عدد بازدید.
جمع‌بندی
بالا رفتن CPU در WordPress یک «مشکل» مشخص نیست؛ یک نشانه است.
ممکن است علت آن یک Plugin، WP-Cron، Query سنگین، Bot Traffic، WooCommerce، درخواست‌های AJAX، Cache نامناسب یا واقعاً کمبود منابع باشد.
بنابراین ترتیب منطقی این است:
مشاهده مصرف → پیدا کردن زمان افزایش → بررسی Requestها → بررسی PHP و Database → بررسی Cron و پردازش‌های پس‌زمینه → بررسی Cache → تصمیم درباره منابع
اول Bottleneck را پیدا کنید، بعد درباره افزایش منابع تصمیم بگیرید.
این رویکرد معمولاً اطلاعات بسیار بیشتری نسبت به غیرفعال کردن تصادفی افزونه‌ها یا ارتقای فوری هاست در اختیار شما قرار می‌دهد.
سوالات متداول
آیا مصرف ۱۰۰ درصد CPU در وردپرس خطرناک است؟
رسیدن کوتاهمدت CPU به ۱۰۰٪ الزاماً مشکل جدی محسوب نمیشود و ممکن است هنگام یک پردازش سنگین رخ دهد. اگر مصرف CPU برای مدت طولانی بالا بماند یا مرتب به Limit برسد و روی Response Time سایت تأثیر بگذارد، باید علت آن بررسی شود.
کدام افزونههای وردپرس CPU بیشتری مصرف میکنند؟
نمیتوان صرفاً بر اساس دستهبندی افزونه مشخص کرد کدام Plugin پرمصرف است. افزونههای Backup، Security، Statistics، Search، Page Builder و بعضی افزونههای WooCommerce ممکن است پردازش بیشتری داشته باشند، اما پیادهسازی و تنظیمات هر افزونه اهمیت بیشتری دارد. بهترین روش، اندازهگیری رفتار واقعی افزونه است.
آیا WP-Cron باعث افزایش CPU میشود؟
WP-Cron بهخودیخود مشکل محسوب نمیشود، اما تعداد زیاد Eventها یا Jobهایی که بیش از حد اجرا میشوند میتوانند مصرف PHP و دیتابیس را افزایش دهند. در این شرایط باید Scheduled Eventها و افزونه ایجادکننده آنها بررسی شوند.
آیا افزایش CPU هاست باعث سریعتر شدن وردپرس میشود؟
اگر Bottleneck واقعاً کمبود CPU باشد، منابع بیشتر میتواند ظرفیت پردازشی سایت را افزایش دهد. اما اگر مشکل از Query کند، API خارجی، Cache نامناسب یا پردازش غیرعادی باشد، افزایش CPU الزاماً مشکل اصلی را برطرف نمیکند.
از کجا بفهمیم کدام بخش وردپرس CPU مصرف می‌کند؟
بهترین روش ترکیب چند منبع اطلاعاتی است. Access Log برای بررسی Requestها، ابزارهایی مثل Query Monitor برای بررسی رفتار WordPress و دیتابیس، وضعیت WP-Cron و Scheduled Actions برای پردازش‌های پس‌زمینه و ابزارهای Monitoring هاست برای مشاهده زمان و میزان مصرف منابع میتوانند در پیدا کردن عامل اصلی کمک کنند.
