Bir sitede 4.600 bekleyen e-posta görünüyor. Yeni job’lar eklenmeye devam ediyor, ancak en eski kaydın zamanı değişmiyor. WP-Cron yalnız sayfa ziyareti olduğunda çalışıyor, bir worker kilidi süresi dolduğu hâlde kalmış ve hatalı bir alıcı her batch’i kayıt tamamlanmadan çökertiyor.
Kuyruk dışındaki başarılı test e-postası yalnız doğrudan SMTP yolunun çalıştığını gösterir. Birikimi silmeden scheduler, worker, kilitler, hatalı job ve sağlayıcı yanıtı incelenmelidir.
Bu konu ne anlama gelir?
E-posta kuyruğu, job’ları asenkron işlemek üzere saklar. Bekleyen bir kayıt ileri bir saate planlanmış, worker bekliyor, kilitli, sağlayıcı tarafından ertelenmiş, sürekli hata veriyor veya çökme sonrasında sahipsiz kalmış olabilir. Kuyruk sağlığı; worker heartbeat’i, en eski kaydın yaşı, işleme hızı ve sonuç türleriyle ölçülür.
Gerçekçi bir WordPress örneği
Ekip, ziyaretçiye bağlı WP-Cron yerine izlenen bir sistem cron’u kurar, yalnız süresi dolduğu doğrulanan kilidi kaldırır ve hatalı alıcı job’unu karantinaya alır. Tek worker önce işaretlenmiş küçük bir grubu işler. Sipariş kayıtlarıyla bildirimler eşleştirildikten sonra kapasite kademeli artırılır.
Neden önemlidir ve ne zaman kullanılır?
Kuyruğu silmek veya tüm job’ları topluca yeniden denemek gerçek parola sıfırlama, makbuz ve hatırlatma iletilerini kaybedebilir ya da iki kez gönderebilir. Job durumunu korumak, sorunun scheduler, worker, veri, kapasite veya sağlayıcı katmanlarından hangisinde olduğunu belirlemeyi sağlar.
Yeni başlayanlar için anlaşılır yol
- Kuyruk verisini yedekleyin; bekleyen ve işlenen sayıları, en eski zamanı, deneme sayısını ve son hataları kaydedin.
- WP-Cron veya sistem cron’unun doğru worker’ı gerçekten başlattığını doğrulayın.
- Heartbeat, kilit, lease, bellek, çalışma süresi ve sağlayıcı yanıtlarını inceleyin.
- Kuyruğu silmek yerine sürekli hata veren tek job’u karantinaya alın.
- İşaretlenmiş küçük bir grubu tek worker ile işleyip sonuçları eşleştirin; sonra kademeli ölçekleyin.
İleri teknik yol
Action Scheduler veya eklenti tablolarını, atomik claim işlemlerini, lease yenilemeyi, transaction sınırlarını, veritabanı indekslerini, loopback durumunu ve sistem cron sorumluluğunu inceleyin. Sürekli hata veren job’lar için idempotency key ve karantina kullanın. Giriş hızı, tamamlanma hızı, en eski kayıt, retry dağılımı ve sağlayıcı kısıtını birlikte izleyin.
Riskler, sık hatalar, yedekleme ve geri alma
Tüm kilitleri sıfırlamayın, aynı anda çok sayıda worker başlatmayın ve kuyruk satırlarını elle değiştirmeyin. Claim’ler çakışırsa, yinelenen ileti oluşursa, ticari kayıtlar beklenmedik biçimde değişirse veya kuyruk şemasının sorumlusu bilinmiyorsa durun. Son kararlı worker ayarına dönüp kritik job’ları eşleştirin.
AIOWS nasıl yardımcı olur?
AIOWS SMTP Yöneticisi
AIOWS SMTP Yöneticisi, kuyruktaki job WordPress’in posta gönderim işlevine bir ileti verdiğinde devreye girer. Testler ve tanı bilgileri WordPress’in sağlayıcıya ulaşıp ulaşmadığını ve hangi yanıtı aldığını gösterir.
Bu veriler kuyruk hatasını SMTP reddinden ayırmaya yardımcı olur. İşaretlenmiş bir kuyruk job’unu doğrudan test e-postası ve sağlayıcı loglarıyla karşılaştırın. Job WordPress posta işleyicisine hiç ulaşmıyorsa önceki katmanı scheduler veya kuyruk sorumlusu düzeltmelidir.
AIOWS WP-Cron’u başlatmaz, Action Scheduler tablolarını onarmaz, eklenti kilitlerini çözmez ve retry işlemlerinin idempotent olmasını garanti etmez. Sağlayıcı verileri ayrı bir SMTP sorunu göstermedikçe kuyruk onarımı sırasında çalışan gönderim yolunu değiştirmeyin.
AIOWS SMTP Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress E-posta Göndermiyor: Nedenleri ve Çözümleri
- Teslimat Sorunları İçin WordPress E-posta Logları Nasıl Kullanılır?
- WordPress SMTP Gönderim Limiti Aşıldı: Nedenler ve Çözümler
Sonuç ve önerilen yol
Kuyruğu silmeden önce ilerlemeyi scheduler, worker, kilit, sürekli hata veren bir job veya sağlayıcının mı durdurduğunu belirleyin. İşaretlenmiş küçük bir grubu izlenen tek worker ile işleyin. Claim işlemleri kararlıysa, sonuçlar açıkça sınıflandırılıyorsa, en eski kaydın yaşı düşüyorsa ve kritik kayıtlar eşleşiyorsa kapasiteyi kademeli artırın.
