خطای افزایش مصرف CPU در وردپرس

از میان همه ی خطاهایی که در پنل هاست خود می بینید، خطای افزایش مصرف CPU یکی از آن هاست که در نگاه اول ترسناک به نظر می رسد. یک ایمیل هشدار از هاست دریافت می کنید که «مصرف CPU سایت شما از حد مجاز عبور کرده» یا در نمودار پنل، یک جهش ناگهانی در مصرف منابع می بینید. سایت در ظاهر همچنان باز می شود، اما ممکن است هاست در چند ساعت آینده سایت را معلق کند. این وضعیت، از آن دسته مسائلی است که هم فوری است و هم مبهم؛ چون برخلاف خطای ۵۰۰ یا صفحه ی سفید، هیچ پیام خطای واضحی روی سایت نمی بینید. همه چیز از یک لایه ی زیرین می آید که فقط در پنل هاست قابل مشاهده است.

در سال ها کار روی سایت های وردپرسی، خطای مصرف بالای CPU را در ده ها پرونده دیده ام؛ از یک افزونه ی بدکد تا یک کرون گیرکرده، از یک حمله ی ساده تا یک باگ در نسخه ی PHP. آنچه این موارد را به هم وصل می کند یک نکته ی مشترک است: مصرف CPU همیشه یک علامت است، نه یک علت. یعنی خود عدد بالا، توضیح نمی دهد که چرا این اتفاق افتاده؛ باید به دنبال منبع واقعی مصرف بگردید. در این مقاله، همان مسیری را باز می کنم که در پروژه های واقعی برای تشخیص و رفع این خطا طی می کنم. اگر با ساختار پایه ای وردپرس آشنایی ندارید، ابتدا وردپرس چیست و چگونه شروع کنیم را بخوانید؛ چون فهم لایه بندی وردپرس، کلید تشخیص این نوع خطا است.

مصرف بالای CPU دقیقا چیست؟

مصرف بالای CPU در وردپرس، وضعیتی است که در آن، سایت شما بیش از سهم مجاز خود از پردازنده ی سرور استفاده می کند. هر پلن هاست، یک سقف مشخص برای مصرف CPU دارد — معمولا بر حسب درصد یا بر حسب واحد پردازش مشخص می شود. اگر سایت شما از این سقف عبور کند، هاست می تواند اقداماتی انجام دهد: از کند کردن سایت تا تعلیق موقت حساب تا محدودسازی نرخ درخواست ها.

نکته ی کلیدی اینجاست: مصرف CPU در وردپرس، هیچ وقت از یک منبع واحد نمی آید. بلکه مجموعه ای از فرآیندها در کنار هم، سقف را پر می کنند: اجرای PHP در هر درخواست، کوئری های دیتابیس، اجرای کرون ها، اسکن های افزونه های امنیتی، و حتی ترافیک ربات ها. درک این نکته، اولین قدم در تشخیص است؛ چون به شما می گوید که نباید فقط دنبال یک مقصر بگردید، بلکه باید بفهمید کدام ترکیب از فرآیندها، سقف را پر کرده اند.

ویژگی این خطا، در مقایسه با خطاهای دیگر وردپرس، این است که اغلب هیچ علامت ظاهری در سایت ندارد. سایت باز می شود، سرعتش ممکن است کمی پایین باشد، اما نه آن قدر که کاربر عادی متوجه شود. تنها نشانه، ایمیل هشدار هاست یا نمودارهای پنل است. همین ویژگی، تشخیص را سخت می کند؛ چون کاربر ممکن است ساعت ها یا روزها متوجه نشود که سایتش در آستانه ی تعلیق است.

در لایه ی فنی، مصرف CPU در وردپرس، از چند جای مختلف می آید: اجرای کد PHP در هر درخواست، پردازش دیتابیس، اجرای کرون ها، و فرآیندهای جانبی مثل اسکن یا بکاپ. درک این لایه ها، به شما کمک می کند که در تشخیص، از کدام نقطه شروع کنید. ساختار کلی را در هاست چیست و چگونه انتخاب کنیم و در تاثیر هاست بر سرعت سایت باز کرده ام؛ همان دو مقاله، پیش نیاز درک دقیق این خطا هستند.

مصرف CPU، در واقع آینه ی رفتار پنهان سایت شماست. اگر عدد بالا می رود، یعنی چیزی در پس زمینه در حال خوردن منابع است که با چشم دیده نمی شود. کار شما، پیدا کردن همان چیز پنهان است.

چرا این خطا فریبنده است؟

خطای مصرف بالای CPU، سه ویژگی دارد که آن را از بقیه ی خطاهای وردپرس متمایز می کند:

• سایت در ظاهر سالم است: برخلاف خطای ۵۰۰ یا صفحه ی سفید، سایت شما باز می شود و کاربر عادی هیچ مشکلی نمی بیند. تنها نشانه، هشدار هاست است.
• ریشه در چند لایه پخش شده: ممکن است مسئله در افزونه، کرون، دیتابیس، ربات ها، یا تنظیمات سرور باشد. هر لایه، مسیر تشخیص متفاوتی دارد.
• پیام هشدار، مقصر را معرفی نمی کند: هاست فقط می گوید «مصرف بالا است»، نه این که چه چیزی مقصر است. باید خودتان لایه به لایه بررسی کنید.

همین سه ویژگی باعث می شود در پرونده های واقعی، بیشترین زمان تشخیص در این خطا صرف شود. تجربه ام می گوید ترتیب درست تشخیص، تفاوت بین «حل در یک ساعت» و «چند روز سردرگمی» است.

آناتومی مصرف منابع در هاست

برای اینکه بتوانید خطا را در ریشه تشخیص دهید، ابتدا باید بدانید منابع هاست چطور توزیع می شوند. در تجربه ی خودم، ترسیم این فرآیند در پنج گره همیشه کمک کرده:

1. گره ی اول — سهم پلن: هر پلن هاست، یک سهم مشخص از CPU، RAM، و Entry Processes دارد. این سهم، سقف مصرف شما را تعیین می کند.
2. گره ی دوم — مصرف پایه ی وردپرس: حتی یک سایت وردپرسی خام، در هر درخواست، از CPU استفاده می کند. این مصرف پایه، برای هر سایت متفاوت است و به تعداد درخواست ها و حجم کد وابسته است.
3. گره ی سوم — مصرف افزونه ها: هر افزونه ی فعال، در هر درخواست، بخشی از CPU را مصرف می کند. این مصرف، در سایت های با افزونه های زیاد، می تواند چند برابر مصرف پایه باشد.
4. گره ی چهارم — کرون ها و فرآیندهای پس زمینه: بعضی افزونه ها، در زمان های مشخصی (نیمه شب، هر ساعت، هر دقیقه) کرون اجرا می کنند که می تواند فشار زیادی به CPU وارد کند.
5. گره ی پنجم — ترافیک و ربات ها: هر بازدید (انسانی یا رباتیک)، یک درخواست است که از CPU استفاده می کند. ترافیک بالا، ربات های ناشناس، و حمله های Brute Force، می توانند سقف را پر کنند.

هر مصرف بالای CPU، از ترکیب این پنج گره می آید. اگر سایت شما با ترافیک پایین، مصرف بالا دارد، مسئله در گره های دوم تا چهارم است. اگر سایت با ترافیک بالا، مسئله در گره ی پنجم. اگر بعد از یک عملیات خاص (مثل بکاپ یا اسکن)، مصرف جهش می کند، مسئله در گره ی چهارم. تشخیص دقیق گره، اولین کار شماست.

خانواده های اصلی مصرف که در پروژه ها دیده ام

مصرف بالای CPU در وردپرس، در ظاهر دلایل متنوعی دارد اما در عمل، در چند خانواده ی مشخص جا می گیرد. جدول زیر، این خانواده ها را با نشانه هایشان دسته بندی می کند:

در ادامه، هر یک از این خانواده ها را با جزئیات باز می کنم.

افزونه های پرمصرف

شایع ترین دلیل مصرف بالای CPU، در تجربه ی من، همان افزونه های پرمصرف است. هر افزونه ی فعال، در هر درخواست، بخشی از CPU را مصرف می کند. اگر تعداد افزونه ها زیاد باشد یا چند افزونه ی سنگین داشته باشید، مصرف پایه ی سایت می تواند از سقف هاست عبور کند — حتی بدون هیچ ترافیک قابل توجه.

سه دسته ی افزونه که در پروژه ها بیشترین نقش را در مصرف بالا داشته اند:

• افزونه های صفحه ساز سنگین: صفحه سازها، در هر بار لود صفحه، کدهای خودشان را اجرا می کنند. اگر سایت شما چند صفحه ساز همزمان داشته باشد (که خودش یک اشتباه رایج است)، مصرف CPU به شدت بالا می رود.
• افزونه های امنیتی با اسکن real-time: این افزونه ها در هر درخواست، فایل ها یا دیتابیس را بررسی می کنند. اگر روی هاست اشتراکی با منابع محدود اجرا شوند، می توانند به تنهایی نیمی از CPU را مصرف کنند.
• افزونه های آمار و تحلیل درون سایتی: این افزونه ها در هر بازدید، داده جمع می کنند و کوئری می زنند. روی سایت های پربازدید، مصرف شان به شدت بالا می رود.

تشخیص: روش غیرفعال سازی نیمه ای، سریع ترین راه است. همه ی افزونه ها را غیرفعال کنید، سپس نیمی از آن ها را فعال کنید و مصرف CPU را در پنل هاست ببینید. اگر مصرف برگشت، مسئله در نیمه ی فعال است. روش دقیق این کار در چگونه افزونه مشکل ساز وردپرس را پیدا کنیم آمده است.

رفع: پس از پیدا کردن مقصر، سه گزینه دارید: به روزرسانی، جایگزینی با افزونه ای سبک تر، یا حذف کامل. برای انتخاب جایگزین، فهرست افزونه های ضروری وردپرس نقطه ی شروع آگاهانه است. تجربه ام می گوید تعداد افزونه های فعال، باید هر شش ماه یک بار بازبینی شود؛ افزونه هایی که در این شش ماه «دست نخورده» باقی مانده اند، کاندیدای حذف هستند.

هر افزونه ی اضافی، یک مصرف اضافه در هر درخواست است. برخلاف باور رایج، تعداد افزونه ها مهم نیست؛ کیفیت کد و نقش هر افزونه در پروسه ی رندر مهم است.

کرون های گیرکرده

دومین دلیل شایع، کرون های گیرکرده است. وردپرس یک سیستم کرون داخلی دارد که به افزونه ها امکان می دهد کارها را در بازه های زمانی مشخص اجرا کنند. اگر یکی از این کرون ها به هر دلیل گیر کند یا خیلی سنگین باشد، می تواند جهش های ناگهانی در مصرف CPU ایجاد کند.

سه سناریوی رایج:

• کرون های اجرا نشده: اگر سایت شما ترافیک پایینی داشته باشد، کرون وردپرس ممکن است در زمان مقرر اجرا نشود و کارها تلنبار شوند. وقتی درخواست بعدی می آید، همه ی کارهای تلنبار شده با هم اجرا می شوند و یک جهش سنگین ایجاد می کنند.
• کرون های سنگین: بعضی افزونه ها، کرون های سنگین تعریف می کنند (مثل پاک سازی لاگ، اسکن دیتابیس، به روزرسانی قیمت). اگر این کرون ها در ساعات پربازدید اجرا شوند، فشارشان با ترافیک عادی جمع می شود.
• کرون های تعارض دار: اگر دو افزونه، کرون یکسانی را تعریف کنند یا یکی از آن ها کرون دیگری را مسدود کند، ممکن است رفتار غیرقابل پیش بینی رخ دهد.

تشخیص: از افزونه ای مثل WP Crontrol استفاده کنید تا فهرست تمام کرون های فعال را ببینید. اگر کرون هایی با بازه ی اجرای کوتاه (هر دقیقه) یا کرون هایی با اجرای تکرارشونده ی ناموفق می بینید، مقصر پیدا شده است. همچنین، از پنل هاست، بخش Cron Jobs را بررسی کنید تا ببینید که آیا کرون سرور هم روی وردپرس اثر می گذارد.

رفع: سه مسیر:

1. کرون های سنگین را به ساعات کم ترافیک منتقل کنید (معمولا نیمه شب).
2. اگر کرون وردپرس برای سایت شما مناسب نیست، آن را غیرفعال کنید و از کرون واقعی سرور (از طریق cPanel) استفاده کنید.
3. اگر یک کرون مشخص مشکل ساز است، افزونه ی مربوطه را بررسی یا جایگزین کنید.

کوئری های سنگین و حلقه های پنهان

سومین دلیل، کوئری های سنگین است. حتی اگر تعداد افزونه ها کم باشد، یک کوئری بد در یک افزونه می تواند فشار زیادی به CPU وارد کند. این نوع مصرف، معمولا در صفحات خاص (مثل آرشیو، صفحه ی محصول، یا صفحه ی جستجو) بیشتر دیده می شود.

نشانه ی این نوع مصرف: سایت در صفحات عادی سریع است اما در یک صفحه ی مشخص، مصرف CPU جهش می کند. علت معمول، یک کوئری بدون pagination، یک حلقه ی تودرتو، یا یک کوئری بدون ایندکس است.

تشخیص: افزونه Query Monitor در اینجا بسیار کمک می کند. این افزونه، تعداد و زمان اجرای کوئری ها را در هر صفحه نشان می دهد. اگر در صفحه ای بیش از ۱۰۰ کوئری یا کوئری ای با زمان اجرای بیش از ۱ ثانیه می بینید، مقصر پیدا شده است.

رفع: اگر خودتان کدنویس هستید، کوئری را بهینه کنید. اگر افزونه ای مقصر است، به نسخه ی جدیدتر به روزرسانی کنید یا جایگزینش کنید. اصول کلی بهینه سازی کوئری ها را در سئو تکنیکال چیست به عنوان بخشی از زیرساخت فنی سایت باز کرده ام.

ربات های ناشناس و حمله ی Brute Force

چهارمین دلیل، ترافیک ربات ها است. حتی اگر سایت شما ترافیک انسانی پایینی داشته باشد، ممکن است صدها ربات ناشناس در روز به سایت شما حمله کنند: اسکنرهای آسیب پذیری، حمله های Brute Force روی صفحه ی ورود، و ربات های محتوایی که صفحات را می خزند.

نشانه ی این نوع مصرف: مصرف CPU در ساعات خاص (معمولا نیمه شب) جهش می کند، درحالی که ترافیک انسانی سایت در آن ساعات پایین است. یا در نمودار پنل هاست، الگوی مصرف، نوسان های منظم دارد.

تشخیص: از پنل هاست، بخش Access Logs یا Raw Access Logs را باز کنید. به دنبال IPهایی با تعداد درخواست بالا بگردید. اگر یک IP مشخص، صدها یا هزاران درخواست در یک ساعت دارد، مقصر پیدا شده است.

رفع: سه مسیر:

1. مسدودسازی IP در سطح .htaccess: اگر IP مشخصی را می شناسید، در .htaccess مسدودش کنید.
2. استفاده از فایروال ابری: سرویس هایی مثل Cloudflare، ترافیک ربات ها را قبل از رسیدن به سرور شما فیلتر می کنند.
3. محدودسازی نرخ درخواست: در پنل هاست، بخش محدودسازی نرخ درخواست را فعال کنید تا از حمله های Brute Force جلوگیری شود.

موضوع امنیت مرتبط با این حوزه را در بهترین افزونه های امنیتی وردپرس به تفصیل باز کرده ام. اگر با حمله ی Brute Force روبه رو هستید، آن مقاله نقطه ی شروع دقیقی است.

Heartbeat API و پیشخوان

وردپرس یک API داخلی به نام Heartbeat دارد که برای ارتباط بین مرورگر و سرور استفاده می شود. این API در هر بازه ی مشخصی (معمولا هر ۱۵ تا ۶۰ ثانیه)، یک درخواست به سرور می فرستد. اگر در پیشخوان باز باشد، حتی بدون هیچ فعالیتی، Heartbeat درخواست می فرستد.

نشانه ی این نوع مصرف: مصرف CPU بالا حتی وقتی هیچ کاری در سایت انجام نمی شود. اگر چند کاربر همزمان در پیشخوان باشند (مثلا در سایت های چندکاربره)، مصرف می تواند چند برابر شود.

تشخیص: در صفحه ی پیشخوان، با DevTools Network را باز کنید و ریلود کنید. اگر درخواست های دوره ای به admin-ajax.php با پارامتر heartbeat را می بینید، مقصر پیدا شده است.

رفع: Heartbeat API را محدود کنید. این کار را می توانید از طریق افزونه یا با یک اسنیپت کوچک در چایلد تم انجام دهید. جزئیات کد سفارشی در چگونه کد سفارشی به وردپرس اضافه کنیم آمده است. یک نکته: Heartbeat API در بعضی موارد مهم است (مثلا برای ذخیره ی خودکار نوشته). قبل از غیرفعال سازی کامل، محدودسازی آن را انتخاب کنید.

نسخه ی PHP و تنظیمات ناهماهنگ

نسخه ی PHP، در مصرف CPU اثر مستقیم دارد. نسخه های جدید PHP (۸.۰ و بالاتر)، چندین برابر سریع تر از نسخه های قدیمی (۷.۰ و پایین تر) هستند. اگر سایت شما روی یک نسخه ی قدیمی PHP اجرا می شود، مصرف CPU به طور طبیعی بالاتر است.

نشانه ی این نوع مصرف: مصرف بالا در همه ی صفحات، حتی با ترافیک پایین و افزونه های کم. اگر با این وضعیت روبه رو هستید، اول نسخه ی PHP را چک کنید.

تشخیص: از پنل هاست، بخش «Select PHP Version» را باز کنید و نسخه ی فعلی را ببینید. اگر نسخه ی شما قدیمی تر از ۸.۰ است، ارتقا را جدی بگیرید.

رفع: ابتدا در محیط استیجینگ، سازگاری افزونه ها و قالب را با نسخه ی جدید بررسی کنید. اگر سازگار بودند، روی سایت زنده هم ارتقا دهید. تجربه ام این است که ارتقای PHP از ۷.۴ به ۸.۱، در اکثر سایت ها مصرف CPU را ۲۰ تا ۳۰ درصد کاهش می دهد. اگر با خطای ناسازگاری روبه رو شدید، مسیرهای رفع در خطای ناسازگاری قالب و افزونه وردپرس آمده است.

XML-RPC و پینگ بک های ناخواسته

XML-RPC یک قابلیت داخلی وردپرس است که به اپلیکیشن های دیگر اجازه می دهد با سایت شما ارتباط بگیرند. این قابلیت، در سایت های مدرن معمولا استفاده نمی شود اما باقی می ماند. مشکل اینجاست که XML-RPC، یک نقطه ی حمله ی شناخته شده است؛ حمله کنندگان از آن برای حملات Brute Force و DDoS استفاده می کنند.

نشانه ی این نوع مصرف: جهش های ناگهانی در مصرف، معمولا در ساعات تصادفی. اگر لاگ سرور را ببینید، صدها درخواست به xmlrpc.php می بینید.

رفع: XML-RPC را غیرفعال کنید. این کار را می توانید از طریق افزونه، یا با یک اسنیپت کوچک در .htaccess، یا در functions.php چایلد تم انجام دهید:

add_filter( 'xmlrpc_enabled', '__return_false' );

اگر از اپلیکیشن موبایل وردپرس استفاده می کنید، این قابلیت لازم است. در غیر این صورت، غیرفعال کردنش توصیه می شود. مسیر دقیق کد سفارشی در چگونه کد سفارشی به وردپرس اضافه کنیم آمده است.

ووکامرس و فشار روی دیتابیس

اگر فروشگاه ووکامرس دارید، این یکی از شایع ترین دلایل مصرف بالای CPU است. ووکامرس به طور طبیعی، کوئری های سنگین تری از یک سایت محتوایی دارد: فیلتر محصولات، محاسبه ی موجودی، محاسبه ی مالیات، و به روزرسانی سبد خرید. اگر تعداد محصولات زیاد باشد، این کوئری ها می توانند فشار زیادی به CPU وارد کنند.

نشانه ی این نوع مصرف: مصرف بالا در صفحات محصول، سبد خرید، و تسویه حساب. اگر سایت شما صفحات دیگری هم دارد، مصرف در آن ها معمولی است.

رفع: چند مسیر:

1. فعال سازی کش آبجکت: Redis یا Memcached می تواند کوئری های تکراری را در حافظه نگه دارد و فشار روی دیتابیس را کم کند.
2. بهینه سازی کوئری ها: با Query Monitor، کوئری های سنگین را پیدا و بهینه کنید.
3. استفاده از کش صفحات: برای صفحاتی که پویا نیستند (مثل دسته بندی محصولات)، از کش صفحه استفاده کنید.
4. محدودسازی تعداد محصولات در هر صفحه: اگر در یک صفحه صد محصول نمایش می دهید، آن را به ۲۰ یا ۳۰ کاهش دهید.

موضوع بهینه سازی ووکامرس را در سئو فروشگاه ووکامرس و در بهترین افزونه های کش وردپرس به تفصیل باز کرده ام.

افزونه های بکاپ و اسکن

افزونه های بکاپ و اسکن امنیتی، در زمان اجرا، مصرف CPU بالایی دارند. اگر این افزونه ها در ساعات پربازدید اجرا شوند، فشارشان با ترافیک عادی جمع می شود و می تواند سقف را پر کند. همچنین، اگر بکاپ به صورت فایل زیپ بزرگ ذخیره شود، فشرده سازی آن فشار زیادی به CPU وارد می کند.

نشانه ی این نوع مصرف: جهش های ناگهانی در ساعات مشخص (معمولا شب)، با یک الگوی منظم.

رفع:

1. زمان بندی بکاپ را به ساعات کم ترافیک منتقل کنید (معمولا بین ۲ تا ۵ بامداد).
2. از فشرده سازی کم تر استفاده کنید یا بکاپ را به صورت مستقیم به فضای ابری منتقل کنید (بدون فشرده سازی سنگین).
3. اگر بکاپ حجم زیادی دارد، آن را به قطعات کوچک تر تقسیم کنید.
4. افزونه های اسکن امنیتی را به صورت زمان بندی شده اجرا کنید، نه real-time.

روش گام به گام تشخیص

ترتیبی که در پروژه های خودم طی می کنم، از سریع ترین به دقیق ترین است:

1. الگوی مصرف را ببینید. در نمودار پنل هاست، آیا مصرف در همه ی ساعات بالا است یا فقط در ساعات خاص؟ الگو، مقصر را لو می دهد.
2. Entry Processes را چک کنید. این پارامتر، تعداد درخواست های همزمان PHP را نشان می دهد. اگر بالا است، مسئله در ترافیک یا ربات ها است.
3. لاگ سرور را ببینید. از Raw Access Logs، IPهای پرمصرف را پیدا کنید. اگر رباتی مشخص وجود دارد، مسدودش کنید.
4. افزونه ها را به روش نیمه ای غیرفعال کنید. اگر مصرف پایین آمد، مقصر در افزونه ها است.
5. WP Crontrol را نصب کنید. فهرست کرون ها را ببینید. اگر کرون هایی با اجرای مکرر یا سنگین هست، مقصر پیدا شده.
6. Query Monitor را نصب کنید. کوئری های سنگین را در صفحات مختلف ببینید.
7. نسخه ی PHP را چک کنید. اگر قدیمی است، ارتقا را جدی بگیرید.
8. اگر همه جواب داد، سراغ سرور بروید. گاهی مسئله در سطح بالاتر از وردپرس است.

این ترتیب، در پروژه های واقعی، بیش از نود درصد پرونده ها را تا گام پنجم حل می کند. اگر تا گام آخر رسیدید و مسئله همچنان باقی است، معمولا مسئله در سطح سرور یا سیاست هاست است و نیاز به هماهنگی با پشتیبانی دارد.

ابزارهای معتبر برای تحلیل مصرف

پنج ابزاری که در پروژه های خودم زیاد استفاده می کنم و در تشخیص مصرف بالای CPU نقش کلیدی داشته اند:

یک — پنل هاست (cPanel / DirectAdmin): بخش «Resource Usage» یا «CPU Usage» در پنل هاست، دقیق ترین اطلاعات را درباره ی مصرف فعلی می دهد. این اولین جایی است که باید ببینید.

دو — Query Monitor (افزونه): این افزونه، کوئری ها، هوک ها، و بارگذاری فایل ها را در هر صفحه نشان می دهد. برای پیدا کردن کوئری های سنگین، ابزار اصلی است.

سه — WP Crontrol (افزونه): این افزونه، فهرست کامل کرون های وردپرس را نشان می دهد و امکان ویرایش یا حذف آن ها را می دهد. برای پیدا کردن کرون های سنگین، ضروری است.

چهار — Server Logs (Raw Access Logs): از پنل هاست یا از طریق SSH، می توانید لاگ سرور را ببینید. این لاگ، دقیقا نشان می دهد چه کسی و چه زمانی به سایت شما درخواست داده. برای شناسایی ربات های ناشناس، ابزار اصلی است.

پنج — Cloudflare Analytics (اگر از CDN استفاده می کنید): این ابزار، ترافیک ربات ها و حمله ها را به طور دقیق نشان می دهد. اگر سایت شما پشت Cloudflare است، این ابزار یکی از بهترین منابع برای تحلیل ترافیک است.

رفع امن و راستی آزمایی

بعد از اینکه ریشه را پیدا و رفع کردید، سه لایه راستی آزمایی انجام دهید تا مطمئن شوید مسئله در ریشه حل شده و برنمی گردد:

1. پایش ۴۸ ساعته: در دو روز آینده، نمودار مصرف CPU را در پنل هاست ببینید. اگر مصرف به حالت عادی برگشته، مسئله حل شده است.
2. تست با ترافیک بالا: اگر مسئله در ترافیک بالا بود، در ساعات اوج دوباره چک کنید که آیا مصرف در محدوده ی مجاز باقی می ماند.
3. تست با عملیات سنگین: اگر مسئله در یک عملیات خاص بود (مثل بکاپ)، همان عملیات را دوباره اجرا کنید و مصرف را ببینید.

یک نکته ی ظریف: بعد از رفع، اگر هاست شما قبلا هشدار داده، تیکت بزنید و از پشتیبانی بخواهید که وضعیت حساب شما را بازبینی کند. بعضی هاست ها، بعد از هشدار، برای چند روز حساب را در وضعیت «تحت نظارت» نگه می دارند و اگر مصرف شما بهبود یافته، آن را برمی دارند.

اشتباهات رایج در مواجهه با این خطا

یک اشتباه ظریف که در دیدگاه ها زیاد می بینم: کاربران با دیدن هشدار هاست، فورا اقدام به مهاجرت به یک هاست گران تر می کنند. اما در بیش از نیمی از موارد، مسئله با یک بهینه سازی ساده حل می شود و مهاجرت، فقط هزینه را بالا می برد. آرام باشید، لایه به لایه بررسی کنید، و در صورت لزوم از بکاپ استفاده کنید. راهنمای اصولی بکاپ در چگونه از سایت وردپرسی بکاپ بگیریم آمده است.

پیشگیری بلندمدت

پنج عادتی که در پروژه های خودم، نرخ این خطا را به کمترین حد رسانده است:

• بازبینی فصلی افزونه ها: هر سه ماه، فهرست افزونه ها را بازبینی کنید. هر افزونه ای که در این سه ماه «دست نخورده» باقی مانده، کاندیدای حذف است.
• پایش ماهانه ی منابع هاست: با پنل هاست یا با یک سرویس پایش بیرونی، ماهانه مصرف CPU را ببینید. ترندهای صعودی، زودتر از بحران خبر می دهند.
• ارتقای دوره ای PHP: هر شش ماه یک بار، نسخه ی PHP سایت را بررسی و در صورت نیاز ارتقا دهید.
• استفاده از CDN: CDN، ترافیک استاتیک و بخشی از ترافیک مخرب را از سرور شما دور می کند. راهنمای راه اندازی در افزایش سرعت وردپرس آمده است.
• زمان بندی هوشمند کرون ها: کرون های سنگین را به ساعات کم ترافیک منتقل کنید.

و یک عادت عملی که در پروژه های خودم پیاده کرده ام: مستندسازی رفتار مصرف. یک فایل ساده داشته باشید که در آن، نمودار مصرف ماهانه ی سایت ثبت شده باشد. اگر روزی مصرف جهش کرد، این سند، تفاوت بین تشخیص سریع و گم شدن در حدس ها است. همین یک عادت کوچک، در بلندمدت، سرمایه گذاری ارزشمندی است. اگر می خواهید دید جامع تری از رفع خطاهای رایج وردپرس داشته باشید، راهنمای جامع رفع خطاهای رایج وردپرس نقطه ی شروع مناسبی است.

نگاه مهندسی به مصرف منابع

از منظر کسی که وردپرس را به عنوان یک پلتفرم تولیدی می بیند، مصرف بالای CPU یک نشانه ی سیستمی است، نه یک باگ لحظه ای. سه تفکیک در این نگاه، به تشخیص و پیشگیری بلندمدت کمک می کند:

یک — مصرف CPU، یک بودجه ی محدود است. در سیستم های بالغ، مفهوم «بودجه ی منابع» (Resource Budget) به عنوان یک اصل معماری پذیرفته شده است. یعنی برای هر لایه از سیستم، یک سهم مشخص از منابع تعریف می شود و هر لایه موظف است در آن سهم بماند. در وردپرس، چون این مفهوم به طور پیش فرض تعریف نشده، احتمالا مصرف منابع به شکل تجمعی بالا می رود. راه حل معماری این است که در انتخاب افزونه ها، «بودجه ی مصرف» را به عنوان یک معیار انتخاب در نظر بگیریم، نه فقط قابلیت ها. تجربه ی من این است که در بلندمدت، سایت هایی که با این معیار ساخته شده اند، پایداری بسیار بیشتری دارند.

دو — مصرف CPU، نشانه ی نقض مرزهای مسئولیت است. همان طور که در بحث تعارض قالب و افزونه گفتم، هر لایه باید فقط کار خودش را انجام دهد. اگر یک افزونه، به جای تمرکز روی کار اصلی خود، فایل ها را اسکن می کند، دیتابیس را هر دقیقه بررسی می کند، یا تمام داده ها را در حافظه نگه می دارد، در واقع از مرز مسئولیتش خارج شده و منابع اضافه ای مصرف می کند. راه حل معماری این است که در بازبینی دوره ای، به این سوال توجه کنیم: آیا این افزونه، فقط کار خودش را انجام می دهد؟ اگر نه، بهتر است یا تنظیم شود یا جایگزین شود.

سه — مصرف CPU، نیازمند مشاهده پذیری است. در سیستم های بالغ، هر جنبه از رفتار سیستم باید «قابل مشاهده» باشد. یعنی باید بتوانیم در هر لحظه بگوییم چه چیزی، چقدر، و چه زمانی مصرف می کند. در وردپرس، این سطح از مشاهده پذیری به طور پیش فرض وجود ندارد. راه حل معماری این است که با ترکیب چند ابزار (Query Monitor، پنل هاست، CDN Analytics، و لاگ سرور) این سطح از مشاهده پذیری را خودمان ایجاد کنیم. تجربه ام این است که سایت هایی که در آن ها این سطح از مشاهده پذیری ایجاد شده، در برابر مشکلات منابع بسیار مقاوم تر هستند — چون پیش از بحران، می توانند روندهای صعودی را ببینند و اقدام کنند.

از منظر انتزاعی تر، مسئله ی مصرف بالای CPU یک معیار بلوغ است. سایت هایی که مکررا با این مشکل روبه رو می شوند، معمولا از یک الگوی معماری مشترک رنج می برند: افزونه های زیاد و بی کیفیت، نبود پایش منظم، و نبود مستندات. سایت هایی که این خطا را کم تر تجربه می کنند، سه ویژگی مشترک دارند: انتخاب دقیق افزونه ها، پایش منظم منابع، و مستندات دقیق. تفاوت این دو دسته، نه در ابزارها، که در نظم عملیاتی است. اگر می خواهید از این خطاهای آینده پیشگیری کنید، اولین قدم ساده ای که توصیه می کنم: یک ستون کوچک در سند پروژه اضافه کنید که ماهانه سه عدد در آن ثبت شود — مصرف CPU، تعداد افزونه های فعال، و امتیاز سرعت سایت. همین یک جدول کوچک، در طول سال های آینده، یک تاریخچه ی ارزشمند از رفتار سایت شما خواهد بود — چیزی که در تشخیص هر نوع مشکل منابع، تفاوت بین چند دقیقه و چند روز است.

مصرف CPU، عددی نیست که فقط در پنل هاست ببینید؛ یک آینه ی رفتاری است که نشان می دهد سایت شما چقدر سالم و چقدر پرحاشیه است.

سخن پایانی

خطای افزایش مصرف CPU در وردپرس، از آن دسته خطاهایی است که در ظاهر هیچ نشانه ای در سایت ندارد اما می تواند در پنل هاست، حساب شما را به لبه ی تعلیق ببرد. ده سناریویی که در این مقاله باز کردم — از افزونه های پرمصرف تا کرون ها، از کوئری های سنگین تا ربات های ناشناس، از Heartbeat API تا XML-RPC و ووکامرس — می توانند بیش از نود درصد پرونده ها را تا گام پنجم حل کنند.

تجربه ام این است که در این خطا، «پیشگیری» بسیار ارزان تر از «رفع» است. یک پایش ماهانه ی منابع، یک بازبینی فصلی افزونه ها، و ارتقای دوره ای PHP، می توانند شما را از هفته ها عیب یابی نجات دهند. برعکس، سایت هایی که هر ماه با یک مشکل جدید در مصرف منابع مواجه می شوند، معمولا از همان ابتدا انضباط عملیاتی نداشته اند.

اگر این خطا را روی سایت خودتان دیده اید و یکی از خانواده های این مقاله مقصر بوده، خوشحال می شوم در دیدگاه ها بخوانم. به ویژه اگر سناریوی نادری کشف کرده اید — مثلا یک افزونه ی خاص با یک رفتار غیرمعمول، یا یک الگوی مصرف که کمتر دیده می شود — همان جزئیات برای خواننده ی بعدی که در همان موقعیت گرفتار است، از هر راهنمای عمومی ارزشمندتر است. اگر هم پس از خواندن این مقاله به این نتیجه رسیدید که زیرساخت فعلی سایت شما سقف این نوع مسائل است، دو مقاله ی راهنمای انتخاب هاست و تاثیر هاست بر سرعت سایت مسیر بعدی شما هستند. 🖥️