Backlog WooCommerce Action Scheduler: CPU și joburi ratate

Un backlog WooCommerce Action Scheduler apare atunci când acțiunile restante sunt create mai repede decât le poate finaliza serverul. Nu evalua coada numai după numărul total de acțiuni cu status pending, deoarece joburile programate pentru viitor sunt normale. Numără acțiunile care și-au depășit ora programată, identifică hook-ul dominant, verifică funcționarea WP-Cron și citește logurile joburilor eșuate. Procesează restanțele numai în loturi controlate. Rularea simultană a mii de acțiuni poate transforma backlogul într-un vârf CPU, blocaje în baza de date sau indisponibilitatea magazinului.

Scris de echipa tehnică ServerSpan.

Un număr mare de acțiuni pending nu înseamnă automat backlog

Action Scheduler este coada de joburi în fundal folosită de WooCommerce și de numeroase extensii. Poate procesa webhookuri, mesaje email, plăți recurente, sincronizări de inventar, importuri analitice, modificări ale comenzilor și sarcini de mentenanță.

O acțiune programată pentru săptămâna viitoare trebuie să rămână pending. O reînnoire programată pentru mâine nu este întârziată astăzi. Coada devine backlog atunci când acțiunile rămân neexecutate după ora programată, iar cea mai veche restanță se îndepărtează tot mai mult în trecut.

Măsurătoare	Ce arată	Model sănătos	Model problematic
Total acțiuni pending	Include atât joburile viitoare, cât și pe cele restante	Poate fi ridicat pe magazine cu abonamente sau sincronizări programate	Nu dovedește singur existența unui backlog
Acțiuni pending restante	Joburi care trebuiau deja executate	Număr mic care scade la verificarea următoare	Numărul crește între două măsurători
Cea mai veche acțiune restantă	Întârzierea maximă a cozii	Dată recentă care avansează spre prezent	Acțiune veche de ore sau zile
Acțiuni grupate după hook	Componenta care produce workloadul	Mai multe hook-uri cu volume controlabile	Un singur hook domină aproape toată coada

Compară rata de creare cu rata de finalizare. Dacă un plugin creează 300 de acțiuni pe oră, iar contul de hosting finalizează numai 200, backlogul crește cu 100 de acțiuni în fiecare oră. Un batch mai mare poate reduce temporar coada, dar nu repară un workload care depășește permanent capacitatea disponibilă.

Serviciul ServerSpan de găzduire web DirectAdmin include administrarea cronjoburilor. Existența cronului nu înlocuiește identificarea hook-ului și a limitei care împiedică procesarea.

Începe cu ecranul Acțiuni programate din WooCommerce

Deschide WooCommerce → Stare → Acțiuni programate. Aceeași interfață poate fi disponibilă și în Unelte → Acțiuni programate.

Interfața oficială Action Scheduler permite filtrarea acțiunilor după status, sortarea după hook sau data programată, rularea unei acțiuni pending și consultarea jurnalului unei acțiuni eșuate.

Notează următoarele date înainte să rulezi, anulezi sau ștergi ceva:

• Numărul acțiunilor pending care și-au depășit ora programată.
• Data și ora celei mai vechi acțiuni restante.
• Hook-urile care apar cel mai frecvent.
• Grupul sau pluginul asociat acelor hook-uri.
• Ultimul mesaj de eroare pentru acțiunile failed.
• Acțiunile care rămân neobișnuit de mult în status in-progress.

Deschide mai multe acțiuni eșuate și citește întregul log. O excepție repetată, un timeout HTTP, un API indisponibil sau o eroare de bază de date identifică callback-ul care trebuie reparat. Rularea repetată a aceleiași acțiuni fără corectarea dependenței produce numai consum suplimentar și alte loguri de eroare.

Action Scheduler poate marca o acțiune drept failed dacă rulează mai mult de cinci minute. Dacă execuția se termină ulterior, statusul poate deveni complete. Verifică toate intrările din log înainte să presupui că jobul trebuie relansat.

Măsoară restanțele cu WP-CLI sau direct din baza de date

WP-CLI oferă rezultate repetabile, ușor de comparat înainte și după intervenție. Începe cu verificări read-only:

wp action-scheduler version
wp action-scheduler datastore
wp action-scheduler status

Un rezultat sănătos confirmă existența comenzilor Action Scheduler și identifică datastore-ul activ. O comandă lipsă poate însemna că site-ul încarcă o versiune veche, pluginul relevant este inactiv sau bootstrapul WordPress pentru WP-CLI a eșuat.

Pentru un site care folosește tabelele dedicate Action Scheduler, afișează acțiunile grupate după status:

prefix="$(wp db prefix)"

wp db query "
SELECT status, COUNT(*) AS actions
FROM ${prefix}actionscheduler_actions
GROUP BY status
ORDER BY actions DESC;
"

Rezultatul trebuie să separe acțiunile pending, complete, failed și in-progress. Un număr mare de acțiuni complete reprezintă în principal o problemă de retenție și dimensiune a bazei de date. Acțiunile pending restante reprezintă activitatea întârziată.

Identifică hook-urile care produc restanțele:

wp db query "
SELECT
    hook,
    COUNT(*) AS overdue,
    MIN(scheduled_date_gmt) AS oldest_due_gmt
FROM ${prefix}actionscheduler_actions
WHERE status = 'pending'
  AND scheduled_date_gmt <= UTC_TIMESTAMP()
GROUP BY hook
ORDER BY overdue DESC
LIMIT 20;
"

Un rezultat sănătos conține puține acțiuni restante și date recente. Un rezultat problematic conține sute sau mii de acțiuni pentru același hook, cu cea mai veche dată aflată cu multe ore sau zile în trecut.

Repetă interogarea după zece minute fără să modifici site-ul. Dacă numărul scade, runnerul funcționează și încearcă să recupereze întârzierea. Dacă numărul rămâne fix, pornirea cozii poate fi blocată. Dacă numărul crește, acțiunile sunt create mai repede decât sunt finalizate.

O eroare care spune că tabela nu există poate indica un prefix diferit, un datastore vechi sau o migrare incompletă. Confirmă rezultatul comenzii wp action-scheduler datastore. Nu crea manual tabelele înainte de stabilirea cauzei.

Un WP-Cron defect lasă acțiunile WooCommerce în așteptare

Runnerul implicit Action Scheduler depinde de WP-Cron și de cereri loopback asincrone. Un magazin cu trafic redus poate porni WP-Cron neregulat. Autentificarea HTTP, un firewall, o problemă DNS sau un plugin de securitate poate bloca loopback-ul chiar dacă paginile magazinului se încarcă normal.

Testează mecanismul de pornire:

wp cron test

wp cron event list \
  --fields=hook,next_run_gmt,next_run_relative,recurrence \
  --format=table

Un test sănătos raportează că pornirea WP-Cron funcționează. Un răspuns HTTP diferit de 200 indică o problemă la cererea loopback. Mesajul că DISABLE_WP_CRON este activ nu reprezintă automat o eroare atunci când un cron real rulează deja din panoul de hosting.

Verifică setările relevante din wp-config.php fără să modifici fișierul:

grep -nE \
  'DISABLE_WP_CRON|ALTERNATE_WP_CRON|WP_CRON_LOCK_TIMEOUT' \
  wp-config.php

Lipsa outputului înseamnă că se folosesc valorile WordPress implicite. Dacă DISABLE_WP_CRON este true, confirmă existența și execuția jobului extern. Dezactivarea cronului intern înainte de configurarea înlocuitorului oprește acțiunile WooCommerce, articolele programate și alte joburi WordPress.

Backlogul și vârful CPU pot proveni din același workload

Rândurile inactive din coadă nu consumă singure mult CPU. Încărcarea apare când callback-urile sunt executate, interoghează baza de date, trimit mesaje, procesează comenzi, contactează servicii externe sau creează alte acțiuni.

Runnerul web implicit revendică un lot de 25 de acțiuni. Continuă procesarea până când se apropie de 90% din memoria disponibilă sau de limita de aproximativ 30 de secunde, apoi poate iniția o altă cerere asincronă dacă mai există activitate restantă.

Model observat	Interpretare probabilă	Următoarea verificare
CPU crește periodic, iar restanțele scad	Runnerul procesează un backlog existent	Identifică hook-ul dominant și măsoară rata de finalizare
CPU crește, dar numărul restant continuă să urce	Producătorul creează activitate mai repede decât poate fi executată	Verifică pluginul sau integrarea care generează hook-ul
Nu există activitate CPU, iar restanțele rămân fixe	Cronul sau pornirea cozii poate fi defectă	Rulează wp cron test și verifică loopback-ul
Aceeași acțiune eșuează în mod repetat	Callback-ul are o dependență nerezolvată	Citește logul acțiunii și logurile WooCommerce
Magazinul devine lent în timpul recuperării	Procesarea concurează cu checkoutul pentru PHP și baza de date	Oprește recuperarea și continuă în loturi mai mici

Nu mări numărul de cozi concurente ca primă intervenție pe shared hosting. Documentația de performanță Action Scheduler avertizează că mai multe cozi asincrone pot crește puternic încărcarea și pot indisponibiliza site-ul.

Logurile acțiunilor eșuate identifică exact callback-ul defect

Afișează ultimele acțiuni failed fără să le modifici:

wp db query "
SELECT
    action_id,
    hook,
    attempts,
    scheduled_date_gmt,
    last_attempt_gmt
FROM ${prefix}actionscheduler_actions
WHERE status = 'failed'
ORDER BY last_attempt_gmt DESC
LIMIT 20;
"

Alege apoi un ID numeric și consultă istoricul său:

action_id=123

wp db query "
SELECT log_date_gmt, message
FROM ${prefix}actionscheduler_logs
WHERE action_id = ${action_id}
ORDER BY log_date_gmt;
"

Înlocuiește 123 cu un ID returnat de interogarea anterioară. Logul trebuie să arate când acțiunea a fost creată, pornită și oprită. Mesajele pot identifica un callback lipsă, un fatal error PHP, un timeout de rețea sau o excepție produsă de plugin.

Consultă și logurile WooCommerce din WooCommerce → Stare → Loguri. Caută în jurul aceluiași timestamp GMT și filtrează după pluginul indicat de hook. Verifică și logul PHP disponibil în panoul de hosting.

Hook-ul dominant este mai util decât eticheta generică „backlog WooCommerce”. O acțiune de plată, una de email, un import analytics și o sincronizare de inventar au dependențe și riscuri diferite.

Procesează coada în loturi mici după repararea cauzei

Acțiunile pending pot modifica comenzi, trimite notificări, apela webhookuri sau iniția operațiuni de plată, în funcție de extensiile instalate. Creează un backup actual al bazei de date și identifică hook-urile dominante înainte de procesarea manuală.

Pentru cozi mari, Action Scheduler recomandă WP-CLI, deoarece comenzile din shell sunt mai puțin expuse timeouturilor unei cereri web. Începe cu un singur lot mic:

wp action-scheduler run \
  --batch-size=20 \
  --batches=1

O execuție sănătoasă raportează acțiunile finalizate și returnează controlul către shell. Verifică din nou numărul restanțelor, utilizarea CPU și acțiunile eșuate înainte de următorul lot.

Oprește procesarea dacă apar erori noi, contul atinge limitele sau magazinul devine indisponibil. Repară mai întâi callback-ul sau dependența.

Nu folosi opțiunea --force în etapa inițială. Aceasta ignoră protecția privind concurența. Nu separa hook-urile de plăți, expirări și schimbări de status în runneri independenți decât dacă documentația extensiei confirmă că ordinea nu este importantă.

Nu șterge în masă acțiunile pending numai pentru a reduce contorul. Eliminarea cozii poate însemna reînnoiri ratate, webhookuri netrimise, importuri incomplete sau joburi de mentenanță omise. Anulează acțiuni numai după identificarea pluginului care le-a creat și confirmarea că activitatea nu mai este necesară.

Un cron real previne întârzierile dependente de trafic

Un cron de sistem este util atunci când magazinul are trafic neregulat sau joburile trebuie să ruleze la intervale previzibile. Configurează și testează comanda externă înainte de dezactivarea cronului pornit la accesarea paginilor.

O comandă tipică pentru DirectAdmin este:

*/5 * * * * /usr/bin/php -q \
  /home/USER/domains/example.com/public_html/wp-cron.php \
  >/dev/null 2>&1

Înlocuiește utilizatorul, domeniul, calea și executabilul PHP cu valorile contului. Rulează manual comanda o dată înainte de programare. O execuție corectă nu afișează de obicei nimic și returnează codul zero. Erorile PHP sau calea incorectă trebuie remediate înainte de dezactivarea WP-Cron.

După verificarea schedulerului extern, oprește pornirea cronului la accesarea paginilor:

define( 'DISABLE_WP_CRON', true );

Adaugă setarea în wp-config.php înaintea liniei care oprește editarea. Păstrează un backup al fișierului. Eliminarea cronului extern în timp ce această constantă rămâne activă va opri joburile automate WordPress.

Shared hosting rămâne potrivit când backlogul este temporar

Un backlog temporar după un import mare, o actualizare de plugin sau o sincronizare unică nu impune automat migrarea la VPS. Shared hosting rămâne potrivit atunci când coada se golește după repararea cauzei, checkoutul rămâne rapid, iar joburile recurente se finalizează în intervalul necesar.

Limita mediului shared a fost atinsă atunci când restanțele cresc în timpul operării normale, callback-urile necesită procese CLI de lungă durată, runnerul ocupă repetat toți workerii PHP sau contul nu poate executa cronul suficient de des.

Comparația ServerSpan dintre shared hosting și VPS explică diferența dintre administrarea inclusă și controlul asupra resurselor. Ghidul despre WooCommerce și vârfurile de trafic tratează separat workerii PHP, cererile dinamice și încărcarea bazei de date.

Pentru probleme mai generale de concurență și indisponibilitate, consultă și articolul despre site-urile WordPress care cedează la valuri de trafic.

Monitorizează vechimea cozii după remediere

O coadă reparată trebuie să prezinte mai puține restanțe, o dată mai recentă pentru cea mai veche acțiune și niciun eșec repetat pentru hook-ul corectat. Repetă măsurătorile după o oră și după 24 de ore.

Cel mai util prag de alertare nu este numărul total de acțiuni pending. Generează o alertă atunci când cea mai veche acțiune restantă depășește întârzierea acceptată de magazin sau când numărul restanțelor crește la mai multe verificări consecutive.

Regula finală este directă. Confirmă că joburile sunt într-adevăr restante, identifică hook-ul care le produce, verifică pornirea cronului și repară erorile repetate înainte de procesarea cozii. Rulează loturi mici și urmărește CPU-ul, checkoutul și acțiunile failed. O coadă care începe imediat să crească din nou are încă o problemă nerezolvată de producție sau capacitate.