wp-cron یک daemon دائمی نیست؛ وردپرس معمولاً هنگام دریافت درخواست بررسی می‌کند آیا رویداد زمان‌بندی‌شده‌ای موعد اجرا دارد. اگر job سنگین، عقب‌افتاده یا هم‌پوشان باشد، می‌تواند PHP و CPU را در زمان بازدید درگیر کند. اما هر CPU بالایی از cron نیست و خاموش کردن آن بدون جایگزین، کارهای مهم را متوقف می‌کند.
پاسخ سریع: ابتدا نام hook، زمان‌بندی، مدت اجرا و فراوانی را پیدا کنید و timestamp مصرف CPU را با cron و PHP log تطبیق دهید. سپس علت job شکست‌خورده یا طولانی را اصلاح، از overlap جلوگیری و در صورت نیاز trigger را به system cron کنترل‌شده منتقل کنید.
wp-cron چه کارهایی انجام می‌دهد؟
انتشار زمان‌بندی‌شده، پاک‌سازی، update check و بسیاری از کارهای افزونه‌ها از رویدادهای cron استفاده می‌کنند. در ووکامرس، بخشی از jobها ممکن است از Action Scheduler عبور کنند که جدول و runner مخصوص خود را دارد. حذف یک‌جای رویدادها می‌تواند ایمیل، sync، backup یا پردازش سفارش را از کار بیندازد.
نشانه‌های درگیری Cron
- CPU spike در فاصله زمانی تقریباً ثابت
- کندی اولین بازدید پس از دوره کم‌ترافیک
- فراخوانی زیاد
wp-cron.phpدر access log - رویدادهای missed schedule یا دیرکرده در Site Health
- processهای PHP CLI یا FPM با duration طولانی
- صف بزرگ jobهای failed/pending
این نشانه‌ها فرضیه‌اند. برای تشخیص عمومی CPU، راهنمای مصرف CPU وردپرس را نیز اجرا کنید.
فهرست رویدادها با WP-CLI
wp cron event list
wp cron schedule listاین فرمان‌ها read-only هستند و باید در root درست سایت و با کاربر مناسب اجرا شوند. ستون next_run، recurrence و hook را ثبت کنید. اطلاعات آرگومان‌ها ممکن است حساس باشد؛ قبل از اشتراک پاک‌سازی کنید.
چرا Job عقب می‌افتد؟
ترافیک کم، غیرفعال بودن trigger، DNS/loopback، PHP timeout، fatal error، lock، job قبلی طولانی یا کمبود worker می‌تواند باعث تأخیر شود. اجرای دستی رویداد بدون رفع علت ممکن است دوباره شکست بخورد یا اثر تکراری بسازد. ابتدا PHP و debug.log همان زمان را بخوانید.
چرا اجرای هم‌پوشان رخ می‌دهد؟
اگر مدت job از interval بیشتر باشد، trigger بعدی ممکن است در حالی برسد که قبلی هنوز فعال است. lock ناکافی، timeout اشتباه یا چند node نیز احتمال overlap را بالا می‌برد. هر hook باید رفتار idempotent و lock مناسب داشته باشد؛ این موضوع به پیاده‌سازی افزونه وابسته است.
Job سنگین را چگونه پیدا کنیم؟
- زمان CPU spike را ثبت کنید.
- process و access log را در همان بازه ببینید.
- فهرست eventها و runnerهای فعال را استخراج کنید.
- نام hook را به افزونه یا کد مالک نسبت دهید.
- duration، ورودی و تعداد آیتم batch را در staging اندازه بگیرید.
- خطا، retry و overlap را بررسی کنید.
صرف دیدن hook پرتکرار به معنی سنگین بودن آن نیست. duration و هزینه هر اجرا را همراه فراوانی بسنجید.
انتقال Trigger به System Cron
برای سایت پرترافیک می‌توان trigger داخلی را غیرفعال و فراخوانی زمان‌بندی‌شده قابل‌کنترل تعریف کرد، اما فقط پس از تأیید اینکه scheduler خارجی واقعاً اجرا، مانیتور و alert می‌شود. ثابت رایج وردپرس چنین است:
define( 'DISABLE_WP_CRON', true );افزودن این ثابت بدون job جایگزین باعث توقف رویدادها می‌شود. command و interval system cron باید با مسیر، user، PHP و معماری واقعی شما تنظیم شود؛ یک نمونه عمومی را کورکورانه روی production کپی نکنید.
Batch و زمان‌بندی
import، ارسال ایمیل و sync را به batchهای کوچک با checkpoint تقسیم کنید. job باید ادامه‌پذیر و در صورت retry امن باشد. کار سنگین را به ساعت کم‌بار منتقل کنید، ولی jobهای حساس به زمان مثل موجودی یا پرداخت را بدون تحلیل عقب نیندازید.
Loopback و شبکه
روش HTTP loopback ممکن است با DNS، WAF، basic auth یا TLS شکست بخورد. خاموش کردن WAF یا verification TLS برای عبور cron راه‌حل امن نیست. مقصد، status و response را بررسی و rule هدفمند تعریف کنید. در چند node، trigger و lock مشترک نیاز به طراحی دارد.
Action Scheduler را با wp-cron یکی ندانید
wp-cron می‌تواند runner را تحریک کند، اما backlog و status jobها در لایه Action Scheduler مدیریت می‌شود. پاک کردن جدول یا همه pendingها خطر از دست رفتن کار دارد. hookهای شکست‌خورده، claim، log و علت retry را جدا بررسی کنید.
Runbook حادثه CPU ناشی از Cron
- process، زمان و hook محتمل را پیش از restart ثبت کنید.
- اثر تجاری job را مشخص کنید؛ آیا پرداخت، ایمیل یا موجودی است؟
- در صورت ضرورت فقط trigger یا job مشخص و غیرحیاتی را مهار کنید.
- صف را حذف نکنید و وضعیت رکوردهای درحال اجرا را نگه دارید.
- عامل را در staging با همان ورودی بازتولید و batch/lock را اصلاح کنید.
- jobهای عقب‌مانده را تدریجی و با مانیتورینگ اجرا کنید.
اگر مهار موقت انجام شد، زمان انقضا و مسئول بازگرداندن آن را ثبت کنید. خاموش ماندن cron پس از پایان حادثه می‌تواند چند روز بعد به انباشت job و قطعی شدیدتر منجر شود.
مانیتورینگ پیشگیرانه
تعداد pending/failed، قدیمی‌ترین job، duration، retry و هم‌پوشانی را مانیتور کنید. alert روی یک failure منفرد ممکن است نویز باشد؛ سن، روند backlog و اثر مسیر تجاری معیارهای بهتری هستند. پس از deployment یا فروش ویژه، این شاخص‌ها را نزدیک‌تر دنبال کنید.
اشتباه‌های رایج
- تعریف DISABLE_WP_CRON بدون scheduler جایگزین
- اجرای دستی همه eventها در production
- حذف صف برای پایین آوردن عدد
- کاهش interval بدون سنجش duration
- اجرای cron با root یا مسیر PHP اشتباه
- نادیده گرفتن چند node و overlap
تأیید اصلاح
کاهش CPU باید همراه اجرای موفق و به‌موقع job باشد. lag، failure، duration و retry را مانیتور کنید و ایمیل، انتشار زمان‌بندی‌شده، backup و عملیات تجاری وابسته را smoke test کنید. فقط پایین آمدن نمودار با متوقف شدن کارها موفقیت نیست.
چه زمانی کمک تخصصی لازم است؟
اگر hook مالک مشخصی ندارد، queue تراکنشی بزرگ است یا چند runner هم‌پوشان CPU را اشباع می‌کنند، حذف تصادفی خطرناک است. سرویس افزایش سرعت وردپرس می‌تواند event، PHP process و منابع سرور را در یک timeline تحلیل کند.
پرسش‌های متداول
آیا wp-cron را خاموش کنیم؟
فقط با scheduler جایگزین آزموده‌شده و مانیتورینگ؛ در غیر این صورت کارهای زمان‌بندی‌شده متوقف می‌شوند.
آیا ترافیک کم باعث تأخیر cron می‌شود؟
در مدل trigger مبتنی بر بازدید ممکن است؛ scheduler واقعی می‌تواند زمان‌بندی را قابل‌پیش‌بینی‌تر کند.
چرا یک رویداد چند بار اجرا می‌شود؟
overlap، retry، lock ناکافی یا ثبت تکراری event را بررسی کنید؛ حذف همه رویدادها تشخیص نیست.