WooCommerce Action Scheduler: Bekleyen İşlemler Neden Birikir?

Araçlar → Zamanlanmış eylemler ekranında binlerce bekleyen ya da başarısız işlem ve "past-due actions found" uyarısı görüyorsanız, Action Scheduler kuyruğu ya hiç çalıştırılmıyor ya da işlendiğinden hızlı doluyordur. En sık rastlanan iki neden, sunucu cron'u kurulmadan wp-cron'un kapatılması ve sitenin kendine istek atamamasıdır (loopback). Bekleyenleri toptan silmeyin, içlerinde web kancası teslimleri, stok senkronları ya da abonelik yenilemeleri olabilir. Önce hangi çalıştırıcının çalışmadığını bulun, sunucu cron'una WP-CLI çalıştırıcısını ekleyin, başarısız işlemlerin günlüğünü okuyup nedenini düzeltin.

Action Scheduler ne iş görür?

WooCommerce, arka planda yapılması gereken işleri anında değil sıraya koyarak çalıştırır. Bu sırayı tutan kütüphane Action Scheduler'dır. WooCommerce'in içinde gelir, pek çok eklenti de onu kullanır: pazaryeri ve ERP entegrasyonları, e-posta pazarlama, abonelik yenilemeleri, analitik verisinin işlenmesi. WooCommerce 10.1'den itibaren WooCommerce'in kendi zamanlanmış bakım işleri de, süresi dolan sepet oturumlarının temizliği dahil, buraya taşındı.

Her iş bir kancaya (hook) bağlı bir "eylem" olarak veritabanına yazılır. Kullanılan dört tablo actionscheduler_actions, actionscheduler_claims, actionscheduler_groups ve actionscheduler_logs, başlarında sitenizin tablo öneki olur. Bir eylemin durumu bekleyen (pending), devam ediyor (in-progress), tamamlandı (complete), başarısız (failed) ya da iptal edildi (canceled) olabilir. Ekranı iki yerden açarsınız: Araçlar → Zamanlanmış eylemler ve WooCommerce → Durum → Zamanlanmış eylemler sekmesi.

Kuyruk nasıl işlenir?

Burada bilinmesi gereken asıl şey, Action Scheduler'ın kendi başına uyanmamasıdır. Onu üç çalıştırıcıdan biri tetikler.

Birincisi WP-Cron çalıştırıcısı. action_scheduler_run_queue kancası dakikada bir zamanlanır, ama WP-Cron da gerçek bir zamanlayıcı değildir. Ya bir ziyaretçi isteğiyle ya da sunucu cron'unun wp-cron.php dosyasını çağırmasıyla çalışır. İkincisi eşzamansız istek (async request) çalıştırıcısı. Yönetim panelinde bir sayfa açıldığında, vadesi gelmiş bekleyen eylem varsa site kendine bir loopback isteği atar ve kuyruğu o istekte işler. Bunu en fazla 60 saniyede bir yapar. Üçüncüsü WP-CLI çalıştırıcısı, yani sunucuda komut satırından çalıştırılan wp action-scheduler run.

Web isteğiyle çalışan iki çalıştırıcının sınırları belgede açıkça yazıyor. Her istekte 25 eylemlik bir parti alınır, işlem en fazla 30 saniye sürer, aynı anda yalnız bir parti çalışır ve kullanılabilir belleğin %90'ı dolunca durulur. Bu değerler action_scheduler_queue_runner_batch_size, action_scheduler_queue_runner_time_limit ve action_scheduler_queue_runner_concurrent_batches filtreleriyle değiştirilebilir. Varsayılanların gerekçesi Action Scheduler'ın performans belgesinde anlatılıyor.

Varsayımsal senaryo: sunucu cron'u wp-cron.php dosyasını beş dakikada bir çağırıyor. Bir pazaryeri eklentisinin her eylemi dış API yüzünden 2 saniye sürüyor. Her beş dakikada 30 saniyelik tek bir parti yaklaşık 15 eylem bitirir, saatte 180 eder. Eklenti saatte 500 eylem üretiyorsa kuyruk her saat 300'den fazla büyür. Yönetim panelinde biri çalışırken eşzamansız çalıştırıcı biraz yetişir, gece kimse yokken birikme hızlanır. Hiçbir şey "bozuk" değildir. Kapasite yetmiyordur.

Birikmenin olası nedenleri

Tablodaki ilk satır en tipik olanıdır. Biri wp-cron'u kapatma tavsiyesini uygulamış ama yerine sunucu cron'unu kurmamıştır. Kuyruk o andan sonra yalnız yönetim panelini açtığınızda çalışan eşzamansız istekle ilerler. Gündüz yavaşça erir, gece durur.

Teşhis adımları

Zamanlanmış eylemler ekranını okumak

Ekranın üstündeki durum filtrelerinden önce Süresi geçmiş, sonra Başarısız görünümünü açın. Kanca sütunu hangi işin biriktiğini, zamanlama tarihi ne zamandan beri beklediğini söyler. Asıl ipucu günlük sütunundadır. Bir eylem başladığında "action started via WP Cron", "via Async Request" ya da "via WP CLI" gibi bir satır düşer. Son günlerde tamamlanan eylemlerin neredeyse hepsi "via Async Request" diyorsa WP-Cron yolu çalışmıyordur.

Başarısız eylemlerde ileti nedeni doğrudan gösterir. "action failed: ..." satırı eklentinin fırlattığı hatayı aktarır. "unexpected shutdown: PHP Fatal error ..." satırı hatanın dosyasını ve satırını verir. "action was in-progress for at least 300 seconds without completing" ise işin beş dakika içinde bitmediğini, büyük olasılıkla PHP tarafından kesildiğini anlatır. Action Scheduler'ın uyarısı da bir eşiğe dayanır: vadesini bir günden fazla geçmiş en az bir eylem varsa yönetim panelinde "past-due actions found" bildirimi çıkar. Resmî SSS birkaç süresi geçmiş eylemin normal olduğunu, bir günden eski çok sayıda eylemin ise bir sorun işareti olduğunu söylüyor.

Site Sağlığı ve loopback

Araçlar → Site Sağlığı ekranında "Your site could not complete a loopback request" uyarısı görüyorsanız site kendi adresine istek atamıyor demektir. WordPress bu isteği zamanlanmış olayları çalıştırmak için de kullanır. Hazırlık kopyalarında sık görülen parola korumalı dizin, sunucunun kendi IP'sinden gelen isteği engelleyen bir güvenlik kuralı ya da alan adının sunucu içinden yanlış adrese çözülmesi buna yol açabilir. Aynı ekrandaki "An active PHP session was detected" uyarısı da loopback isteklerini bozar. Bu durumda sorun bir eklentinin açık bıraktığı PHP oturumudur.

WP-CLI ile sayım

Hostinginizde ya da sunucunuzda WP-CLI varsa tabloyu tek komutla görürsünüz. Komutları WordPress'in kurulu olduğu dizinde çalıştırın:

wp action-scheduler status

wp action-scheduler action list --status=failed \
  --per_page=20 --fields=id,hook,scheduled_date

wp action-scheduler action logs 1234

wp cron test

İlk komut çalıştırıcının etkin olup olmadığını, kullanılan sürümü ve her durum için sayı, en eski ve en yeni tarihi listeler. İkincisi son başarısız eylemleri gösterir. --per_page vermezseniz liste varsayılan olarak yalnız beş kayıt getirir. Üçüncüsü 1234 numaralı eylemin günlüğünü yazdırır. Son komut WP-Cron'un HTTP üzerinden tetiklenip tetiklenemediğini sınar ve DISABLE_WP_CRON tanımlıysa bunu hata olarak bildirir. Bu hata tek başına sorun değildir, yeter ki yerine sunucu cron'u kurulmuş olsun.

Hangi kancanın kuyruğu doldurduğunu phpMyAdmin'de bir sorguyla görebilirsiniz (öneki kendi kurulumunuza göre düzeltin):

SELECT hook, status, COUNT(*) AS adet
FROM wp_actionscheduler_actions
GROUP BY hook, status
ORDER BY adet DESC
LIMIT 20;

Çözüm: kuyruğa sunucu cron'u ve WP-CLI

Önce temel ayar. DISABLE_WP_CRON açıksa sunucu cron'unun wp-cron.php dosyasını düzenli çağırdığından emin olun. Bu geçişin adımlarını ve önerilen aralıkları wp-cron'dan sunucu cron'una geçiş rehberinde anlattık, burada tekrar etmeyelim.

Kuyruğu sürekli dolu bir mağazada bu tek başına yetmeyebilir, çünkü her çağrıda yine 30 saniyelik tek bir parti işlenir. Daha sağlam yol, Action Scheduler için ayrı bir WP-CLI görevi tanımlamaktır. Action Scheduler belgesine göre komut satırından çalışan iş, web isteklerindeki zaman aşımı kısıtlarına genellikle takılmaz. WP-CLI çalıştırıcısında varsayılan parti boyutu da 100'dür. cPanel'deki Cron Jobs ekranına ya da kendi sunucunuzun crontab'ına şu satır eklenebilir:

*/2 * * * * /usr/local/bin/wp --path=/home/kullanici/public_html \
  action-scheduler run --batches=20 --quiet > /dev/null 2>&1

wp programının yolu ve WordPress dizini sunucuya göre değişir, kendi değerlerinizi yazın. Yolu bilmiyorsanız sağlayıcınıza sorun. --batches=20 her çağrıda en fazla 20 parti işler, sıfır verirseniz kuyruk boşalana kadar çalışır. --force seçeneğini cron'a koymayın. Action Scheduler aynı anda çalışan parti sayısını sınırlar. O an başka bir parti çalışıyorsa yeni çağrı "There are too many concurrent batches." iletisiyle hemen çıkar, bu beklenen davranıştır. --force bu korumayı kaldırır ve üst üste binen çalıştırmalar sunucuyu yorabilir. Komut satırındaki PHP'nin sürümü ve bellek sınırı web tarafındakinden farklı olabilir, ilk gün çıktıyı bir dosyaya yönlendirip kontrol etmek iyi fikirdir.

Kendi sunucunuzda kaynak varsa aynı anda çalışan parti sayısını action_scheduler_queue_runner_concurrent_batches filtresiyle ikiye ya da üçe çıkarabilirsiniz. Bunu paylaşımlı hostingte yapmayın. Eşzamanlı işlem sınırını kuyruk tüketir ve ziyaretçiye yer kalmaz.

Saklama süresini ayarlamak

Tamamlanan ve iptal edilen eylemler varsayılan olarak 31 gün saklanır. Action Scheduler 4.0.0 ile (WooCommerce 11.0 bu sürümle geliyor) başarısız eylemler de üç aydan eskiyse siliniyor ve temizlik her işte değil, günde bir kez site saatiyle 03.00'te ayrı bir iş olarak çalışıyor. Ayrıntılar WooCommerce geliştirici blogundaki Action Scheduler 4.0.0 duyurusunda. Tablo yine de çok büyüyorsa süreyi kısaltabilirsiniz. Aşağıdaki parça bir mu-plugin dosyasına ya da alt temanın functions.php dosyasına eklenebilir:

add_filter( 'action_scheduler_retention_period', function () {
    return 7 * DAY_IN_SECONDS;
} );

Biriken eski kayıtları beklemeden temizlemek için WP-CLI'nin clean komutu var. Varsayılan olarak yalnız tamamlanmış ve iptal edilmiş, 31 günden eski eylemlere dokunur:

wp action-scheduler clean --batch-size=500 --pause=1

--pause=1 partiler arasında bir saniye bekler, büyük tablolarda veritabanının nefes almasını sağlar.

Başarısız işlemler: önce neden, sonra yeniden çalıştırma

Başarısız bir eylemi düşünmeden yeniden çalıştırmak, aynı hatayı yeni bir zaman damgasıyla kaydetmekten öteye geçmez. Sıra şöyle olmalı: günlükteki iletiyi okuyun, eklentinin kendi günlüğüne (WooCommerce → Durum → Günlükler) ve PHP hata günlüğüne bakın, nedeni düzeltin, sonra tek bir eylemi deneyin.

wp action-scheduler action run 1234

Tek eylem başarıyla tamamlanırsa aynı kancanın diğer başarısızlarını da yeniden çalıştırabilirsiniz. Burada bir tuzak var. Bazı işler iki kez çalışınca zarar verir: müşteriye ikinci kez giden bir e-posta, pazaryerine iki kez düşen stok, iki kez çekilmeye çalışılan abonelik ücreti. Yeniden çalıştırmadan önce işin karşı tarafta zaten tamamlanıp tamamlanmadığını kontrol edin.

Kaldırdığınız bir eklentinin geride bıraktığı bekleyen eylemler artık hiçbir işe yaramaz ve her çalıştırmada başarısız olur. Bunları kancaya göre iptal edebilirsiniz:

wp action-scheduler action cancel eski_eklenti_senkron --all

Kanca adını yazmadan önce sayım sorgusuyla doğrulayın. Benzer adlı kancalar yanlış işi iptal ettirebilir.

Bekleyenleri körü körüne silmeyin

Sık yapılan hata, "kuyrukta 80.000 eylem var" panikle tablonun boşaltılmasıdır. Bekleyen bir eylem henüz yapılmamış bir iştir. İçinde bir müşterinin sipariş bildirimi, ERP'ye gitmemiş bir sipariş, zamanı gelmiş bir abonelik yenilemesi ya da WooCommerce'in kendi temizlik işi olabilir. Silindiğinde iş yapılmamış olarak kalır ve çoğu zaman kimse fark etmez. İptal etmek de aynı sonucu doğurur.

Temizlik ya da toplu iptal yapacaksanız önce veritabanı yedeği alın. WP-CLI varsa wp db export komutu tüm veritabanının dökümünü alır. Yoksa panelinizin yedek aracını ya da phpMyAdmin'in dışa aktarma ekranını kullanın. Sonra yalnız nedeni belli olan kancalara dokunun. Gerçek bir sorunu olan kancada yığılmış binlerce eylem varsa önce nedeni düzeltin, kuyruğun kendiliğinden erimesini izleyin. WP-CLI çalıştırıcısı devredeyse bu genellikle sandığınızdan hızlı olur.

Kuyruğun düzeldiğini gösteren işaretler

wp action-scheduler status çıktısını ya da ekrandaki sayıları birkaç saat arayla not edin. Bekleyen sayısı düşmeli ve en eski bekleyen eylemin tarihi bugüne yaklaşmalı. Süresi geçmiş filtresi boşalmaya başlamalı, bir gün sonra da yönetim panelindeki uyarı kaybolmalı. Yeni tamamlanan eylemlerin günlüğünde "via WP CLI" ya da "via WP Cron" satırlarını görmelisiniz. Ardından işin kendisini doğrulayın: test siparişinin e-postası geldi mi, ERP'ye düştü mü, sepet oturumu tablosundaki süresi dolmuş satırlar azalıyor mu? Kuyruk sağlıklı çalışmazsa oturumlar birikir ve bu dolaylı olarak WooCommerce sepet ve ödeme sayfasının yavaşlamasına katkı yapar.

Kuyruk bozulduğunda ilk etkilenenlerden biri de e-postalardır. Mağazanız işlem e-postalarını Action Scheduler üzerinden erteliyorsa, bu e-postaların gecikmesi ya da hiç gitmemesi kuyruğun durumuna bağlıdır. Sipariş e-postalarının neden gitmediğini adım adım teşhis ederken kuyruğu da kontrol listesine ekleyin.

Paylaşımlı hostingte sınırlar ve destek

Yönetim panelindeki yavaşlık da bazen bu kuyruğa bağlanır: eşzamansız çalıştırıcı her panel isteğinin sonunda loopback başlatır ve sınırlı kaynakta panel yanıtlarıyla yarışır. wp-admin yavaşlığının diğer nedenleriyle birlikte değerlendirin. Kampanya öncesinde de kuyruğu boşaltın. Binlerce bekleyen senkron işi, kampanya saatinde ödeme isteklerinin kullanacağı PHP işçileriyle yarışır. Bu etkiyi görmek için kampanya öncesi yük testini kuyruk doluyken ve boşken ayrı ayrı koşabilirsiniz.

Netx'te WordPress hosting paketleri cPanel sunucularında çalışır, cron görevleri cPanel'in Cron Jobs ekranından tanımlanır. WP-CLI'nin yolu, komut satırı PHP sürümü ya da loopback isteklerini engelleyen bir sunucu kuralı konusunda emin değilseniz Netx müşteri panelinden destek talebi açın. Talebe wp action-scheduler status çıktısını (ya da ekrandaki durum sayılarını), başarısız bir eylemin günlük satırlarını, Site Sağlığı → Bilgi sekmesindeki kopyalama düğmesiyle alınan site bilgisini ve wp-config.php dosyasında DISABLE_WP_CRON tanımlı olup olmadığını ekleyin. Kuyruk büyüklüğü paylaşımlı paketin kaynaklarını sürekli zorluyorsa WooCommerce için hosting gereksinimlerine bir kez daha bakmanın zamanı gelmiştir.