هزاران Scheduled Action در حالت Pending می‌تواند ایمیل، webhook، sync موجودی، subscription یا کارهای نگهداری را عقب بیندازد. اما قبل از incident اعلام کردن، زمان اجرای آن‌ها را ببینید: actionهای برنامه‌ریزی‌شده برای آینده طبیعی‌اند. مشکل زمانی است که تعداد actionهای آماده اجرا بالا می‌رود، سن قدیمی‌ترین مورد زیاد می‌شود و نرخ تکمیل از نرخ ورود عقب می‌ماند.
اقدام فوری: جداول را truncate و همه actionها را یک‌جا Run نکنید. ابتدا از دیتابیس backup بگیرید، pendingهای overdue را بر اساس hook/group شمارش کنید و قدیمی‌ترین زمان را ثبت کنید. سپس cron/runner، failedها، PHP log و منابع را در همان بازه بررسی کنید. نوع hook تعیین می‌کند تأخیر چه اثر تجاری دارد.
آیا واقعاً Backlog دارید؟
- تعداد pending با زمان گذشته، نه همه futureها
- سن قدیمی‌ترین action آماده اجرا
- نرخ action جدید در برابر complete در دقیقه
- hook یا group غالب
- failed و in-progress قدیمی
- زمان شروع مشکل نسبت به update یا قطعی
برای شناخت اجزای صف، ابتدا راهنمای Action Scheduler ووکامرس را ببینید. عدد کل بدون status و scheduled date می‌تواند گمراه‌کننده باشد.
اثر تجاری را اولویت‌بندی کنید
| نوع Hook | اثر احتمالی تأخیر | اولویت بررسی |
|---|---|---|
| پرداخت/Subscription | وضعیت مالی یا تمدید عقب‌افتاده | بحرانی؛ reconcile لازم |
| موجودی/ERP | stock یا قیمت قدیمی | بالا |
| Webhook/ایمیل | integration یا اطلاع‌رسانی دیر | وابسته به مصرف‌کننده |
| Cleanup/گزارش | رشد داده یا گزارش دیر | معمولاً پایین‌تر |
اجرای batch باید با اولویت business هماهنگ باشد. ممکن است پاک‌سازی بتواند صبر کند اما تأیید تمدید نه. args و log می‌توانند داده حساس داشته باشند؛ خروجی عمومی را redact کنید.
WP-Cron یا Cron واقعی اجرا نمی‌شود
اگر WP-Cron در تنظیمات غیرفعال شده، باید جایگزین سیستم‌عامل با زمان‌بندی و URL/فرمان صحیح وجود داشته باشد. اگر به ترافیک سایت متکی است، سایت کم‌ترافیک یا loopback ناموفق runner را دیر آغاز می‌کند. زمان آخرین run و log cron را بررسی کنید. چند scheduler موازی نیز می‌تواند overlap و فشار بسازد.
Loopback و درخواست داخلی
DNS داخلی، HTTPS، Basic Auth، WAF یا redirect زبان ممکن است درخواست loopback را رد کند. Site Health و access log سرنخ می‌دهند. TLS verification را خاموش یا hostname را دور نزنید؛ DNS، certificate chain و دسترسی endpoint را درست کنید. 200 بودن صفحه اصلی از داخل سرور لزوماً اجرای runner را ثابت نمی‌کند.
Fatal Error در یک Hook
یک callback معیوب ممکن است batch را کند یا failedهای فراوان بسازد. WooCommerce log، PHP error log و Action log را با timestamp تطبیق دهید. stack trace باید افزونه مالک را نشان دهد. نمایش خطا برای بازدیدکننده یا ثبت secret در log مناسب نیست. پس از اصلاح، نمونه محدود را retry کنید.
Action طولانی یا API خارجی کند
sync ERP، webhook یا API می‌تواند تا timeout worker را نگه دارد. connect/read time، status و retry را اندازه بگیرید. افزایش timeout اجازه می‌دهد actionهای کمتری در واحد زمان تمام شوند. عملیات باید timeout محدود، backoff و idempotency داشته باشد؛ retry کور ممکن است درخواست مالی یا موجودی را دوبار اجرا کند.
نرخ تولید از مصرف بیشتر است
حتی بدون خطا، اگر در هر دقیقه action بیشتری از ظرفیت runner ساخته شود صف رشد می‌کند. نرخ schedule و complete را برای hook غالب رسم کنید. علت می‌تواند import بزرگ، فروش ویژه، sync پرحجم یا producer معیوب باشد. ظرفیت را فقط با concurrency بالا نبرید؛ PHP، RAM، دیتابیس و provider خارجی سقف دارند.
Producer معیوب و Actionهای مشابه
اگر hook و args مشابه با فاصله بسیار کوتاه تکرار می‌شوند، محل schedule کردن را بررسی کنید. ممکن است هر page load یا retry یک action جدید بسازد. ابتدا producer را متوقف یا rate-limit کنید؛ پاک کردن backlog درحالی‌که تولید ادامه دارد نتیجه موقت می‌دهد. recurring واقعی را با duplicate ناخواسته اشتباه نگیرید.
PHP-FPM و محدودیت منابع
runner با درخواست کاربران worker و منابع مشترک دارد. صف PHP، CPU، available memory، I/O و MySQL connections را در زمان backlog ببینید. افزایش worker بدون RAM کافی می‌تواند OOM یا swap ایجاد کند. اگر jobها در ساعت فروش رقابت می‌کنند، زمان‌بندی و سهم ظرفیت را بازطراحی کنید.
Lock، Claim و In-progress قدیمی
توقف process وسط اجرا می‌تواند claim یا actionهای درحال‌اجرا باقی بگذارد تا مکانیزم بازیابی نسخه آن‌ها را آزاد کند. دستکاری مستقیم status و lock با SQL خطر اجرای دوباره هم‌زمان دارد. سن، log و وضعیت process را بررسی و از API/ابزار پشتیبانی‌شده همان نسخه استفاده کنید.
دیتابیس و Query کند صف
جدول بزرگ، index نامناسب، I/O یا transaction طولانی می‌تواند claim و update را کند کند. slow log و execution plan را روی clone بررسی کنید. optimize یا index حدسی روی production ممکن است lock و فضای موقت زیادی بخواهد. ابتدا backup و ظرفیت maintenance window را مشخص کنید.
نسخه و Migration ناقص
پس از update افزونه ممکن است schema یا callback تغییر کرده باشد. module/plugin version، migration log و سازگاری PHP/WooCommerce را بررسی کنید. rollback فایل بدون rollback سازگار دیتابیس می‌تواند وضعیت را بدتر کند. clone تازه production بهترین محل آزمایش نسخه قبلی یا patch است.
برنامه مهار مرحله‌ای
- backup و snapshot تعداد/سن صف بگیرید.
- hookهای حیاتی و producer غالب را مشخص کنید.
- اگر تولید runaway است، منبع را کنترل‌شده مهار کنید.
- cron، runner، loopback و fatal error را اصلاح کنید.
- API کند و timeout/retry را در callback رفع کنید.
- ظرفیت مصرف را با batch کوچک و مانیتور بالا ببرید.
- نرخ تخلیه، منابع و side effect را پیوسته کنترل کنید.
- پس از تخلیه، عملیات تجاری عقب‌افتاده را reconcile کنید.
در زمان Incident تغییرات را کنترل کنید
هنگام رشد سریع backlog، deployment و تغییر تنظیمات غیرمرتبط را موقتاً متوقف کنید تا timeline قابل تفسیر بماند. زمان شروع، آخرین release، hook غالب، نرخ ورود/خروج و نمونه exception را در incident log ثبت کنید. اگر سفارش مشتری متاثر است، تیم پشتیبانی باید بداند کدام موارد نیازمند بررسی‌اند.
پس از مهار producer یا رفع runner، backlog را با batch کوچک تخلیه و منابع را مشاهده کنید. اگر نرخ تکمیل افت کرد، batch را متوقف و bottleneck را بررسی کنید؛ هدف صفر کردن سریع عدد نیست، بلکه بازیابی بدون side effect و بدون از کار انداختن Checkout است.
چرا Run All خطرناک است؟
اجرای هم‌زمان هزاران action می‌تواند PHP و دیتابیس را اشباع، API خارجی را rate-limit و عملیات قدیمی را بدون ترتیب لازم اجرا کند. بعضی actionها پس از تغییر business دیگر معتبر نیستند. نمونه محدود از هر hook را روی staging یا با runbook اجرا و side effect، مدت و idempotency را تأیید کنید.
چرا Delete All راه‌حل نیست؟
Pendingها ممکن است تنها رکورد کارهای پرداخت، ایمیل، subscription یا موجودی باشند. حذف آن‌ها عدد را صفر می‌کند ولی وضعیت business را ناقص می‌گذارد. cancel یا حذف فقط وقتی قابل قبول است که مالک hook، اثر، جایگزین و فهرست reconcile روشن باشد. تاریخچه incident را نیز حفظ کنید.
پس از بازیابی چه چیزهایی را تطبیق دهیم؟
- پرداخت و وضعیت سفارش با پنل درگاه
- تمدیدها و دسترسی مشتریان
- موجودی و قیمت با ERP
- webhookهای دریافت‌شده توسط مقصد
- ایمیل‌های ارسال‌شده و احتمال تکرار
- گزارش و cleanupهایی که از موعد گذشته‌اند
زمان تخلیه صف را واقع‌بینانه برآورد کنید
اگر ۳۰ هزار action آماده دارید و ظرفیت خالص پس از کسر actionهای تازه ۳۰۰ مورد در دقیقه است، تخلیه نظری حدود صد دقیقه طول می‌کشد؛ مدت hook و rate limit می‌تواند این نرخ را تغییر دهد. نرخ خالص را مرتب محاسبه کنید و عبور از ظرفیت را با افزایش latency و خطا تشخیص دهید.
افزایش هم‌زمانی تا جایی مفید است که دیتابیس، PHP و سرویس مقصد اشباع نشوند. افت نرخ خالص همراه با افزایش latency نشانه worker بیشتر نیست؛ ابتدا گلوگاه را رفع کنید.
هشدارهای پیشگیرانه
روی سن قدیمی‌ترین pending overdue، نرخ failed، فاصله schedule تا complete و تعداد in-progress قدیمی هشدار بگذارید. metricها را بر اساس hook یا group تفکیک کنید. همچنین cron heartbeat، PHP queue، DB latency و external API را کنار آن نمایش دهید تا علت با اثر اشتباه نشود.
اشتباه‌های رایج
- شمردن future actionها به‌عنوان backlog
- truncate جدول یا تغییر status با SQL
- Run All در production
- افزایش concurrency بدون ظرفیت‌سنجی
- retry عملیات مالی بدون idempotency
- پاک کردن failedها پیش از ثبت exception
- رفع معلول بدون متوقف کردن producer
چه زمانی کمک تخصصی لازم است؟
اگر backlog شامل پرداخت، subscription یا sync موجودی است، حذف یا اجرای کور می‌تواند خسارت مالی و داده تکراری بسازد. پشتیبانی فروشگاه ووکامرس می‌تواند نرخ ورود/خروج، hook، cron، log و منابع را تحلیل و تخلیه مرحله‌ای همراه با reconcile طراحی کند.
پرسش‌های متداول
چند Pending زیاد محسوب می‌شود؟
عدد ثابت ندارد؛ سن overdue، نرخ ورود/خروج و اهمیت hook تعیین‌کننده است.
آیا افزایش PHP worker صف را تخلیه می‌کند؟
فقط اگر worker bottleneck باشد و RAM/دیتابیس ظرفیت داشته باشند؛ API کند یا fatal error باقی می‌ماند.
می‌توان actionهای قدیمی را Cancel کرد؟
پس از شناخت مالک، اثر business و مسیر جایگزین. قدیمی بودن به‌تنهایی مجوز لغو نیست.
چرا بعد از تخلیه دوباره صف رشد می‌کند؟
producer، cron یا ظرفیت پایدار اصلاح نشده است. نرخ schedule و complete را دوباره مقایسه کنید.