📊 ixtif.com Performans Analizi

📅 Tarih: 2025-11-30 03:38 | 🎯 Tenant: ixtif.com | 👤 Talep: Canlı ortam aşırı yavaş, kaynak analiz ve aksiyon planı

🚦 Durum Özeti

  • Sunucu yükü load average 16.95 / 15.14 / 14.92 (yüksek) – çok sayıda PHP/Horizon prosesi CPU tüketiyor.
  • Horizon birden fazla master ve onlarca worker aynı anda çalışıyor; ps çıktısı 6+ master seti (ZkT3, yZ59, rwGp, 6KJ6, heML, HKPJ, OLr0) gösteriyor.
  • DB bağlantıları tenant-resource-tracking logunda "Too many connections" hatası; bağlantı şişmesi yaşanıyor.
  • Debug araçları APP_DEBUG ve APP_DEBUG_TOOLS prod\'da açık; Debugbar storage 1.6 GB, Pulse/Telescope kayıt yapıyor.
  • Loglar queue health check her dakikada Horizon\'ı nohup ile başlatmaya çalışıyor (tekrarlı "Horizon otomatik başlatıldı" logları); Pulse kayıtları 111 ms yazım ve modül sorgusu 145 ms olarak işaretlenmiş.

🎯 Öncelikli Aksiyonlar

1. Horizon süreç patlamasını durdur Yüksek

Horizon için 6'dan fazla master ve çok sayıda worker aynı anda koşuyor; her biri 10-16% CPU kullanıyor. Bu yoğunluk load average'ı 15+ seviyesine çekiyor ve MySQL bağlantı sınırını zorluyor.

Kök neden: queue:health-check komutu her dakika runInBackground çalışıyor, QueueHealthService içinde nohup ile yeni Horizon başlatıyor; AutoQueueHealthCheck middleware admin trafikte de tetikliyor; mevcut süreçler terminate edilmediği için katlanarak artıyor.

Aksiyon: Tek bir supervisor/systemd ile Horizon'ı yönetecek yapılandırmaya geç; queue:health-check içindeki otomatik Horizon başlatmayı kapat ve tek seferlik horizon:terminate ile fazlalıkları temizle; cron'da queue:ensure-workers/health-check frekansını düşür veya devre dışı bırak.

Beklenen sonuç: CPU yükü ve DB bağlantı sayısı düşer, ixtif.com yanıt süreleri stabil hale gelir.

2. Prod ortamda debug araçlarını kapat Yüksek

APP_DEBUG ve APP_DEBUG_TOOLS üretimde true; Debugbar tüm kolektörlerle aktif ve storage/debugbar klasörü 1.6 GB. Pulse ve Telescope da açık, her istekte veritabanına pulse_entries vb. yazıyor.

Risk: Dosya I/O ve DB yazımları sayfa yanıtlarını geciktiriyor, disk tüketimi artıyor.

Aksiyon: APP_DEBUG ve APP_DEBUG_TOOLS değerlerini prod için false'a çek; Debugbar/Telescope/Pulse'ı sadece lokal için aç; storage/debugbar içeriğini ve Pulse/Telescope kayıtlarını temizle; log seviyesini INFO altına düşür.

Beklenen sonuç: I/O yükünde ve sorgu sayısında belirgin azalma, önbellek hit oranında artış.

3. Veritabanı bağlantı sağlığını toparla Orta

"Too many connections" hataları merkezi DB'yi kilitlemiş; Horizon süreç fazlalığı bağlantı havuzunu tüketiyor. Pulse ve Debugbar da ek yazımlarla bağlantı süresini uzatıyor.

Aksiyon: Horizon çoğalmasını durdurduktan sonra MySQL max_connections ile PHP-FPM/Horizon worker sayısını hizala; uzun yaşayan işlemleri (AI, HLS) timeout ve maxJobs limitleriyle izleyip erken sonlandır; DB bağlantı reuse/pooling ayarlarını gözden geçir.

Beklenen sonuç: Bağlantı satürasyonu kalkar, 500/1040 hata riski düşer.

4. Cron ve health-check yoğunluğunu sadeleştir Orta

queue:health-check her dakika runInBackground çalışıyor; queue:ensure-workers komutu her 5 dakikada docker inspect/restart deniyor; AutoQueueHealthCheck middleware her admin trafiğinde job dispatch ediyor.

Aksiyon: Tek bir sağlam Supervisor/Systemd izleme hattı bırakıp diğer otomatik restart mekanizmalarını kapat; middleware tetiklemesini kaldır veya per-request'ten çıkar; docker tabanlı ensure-workers komutunu canlı ortamda devre dışı bırak.

Beklenen sonuç: Gereksiz proses açılışları durur, cron kuyruk yoğunluğu ve log gürültüsü azalır.

5. Uygulama katmanı optimizasyonları Düşük

PULSE slow request kaydı 111 ms (pulse_entries yazımı) ve module_tenants join'i 145 ms görünüyor. Şu anki ana sorun CPU/IO olduğundan, altyapı sakinleştirildikten sonra sorgu planlarını ve index'leri (module_tenants tenant_id/module_id/is_active) gözden geçirmek faydalı.

Beklenen sonuç: Altyapı stabilize olduktan sonra istek başına DB süresi düşer, responsecache etkisi artar.

🧭 Sonraki Adım Notları

  • Önce Horizon çoğalmasını durdurup tek instance'a düşür; ardından load average ve MySQL bağlantı sayısını takip et.
  • Debug araçlarını kapattıktan sonra storage/debugbar ve Telescope/Pulse verisini temizleyip disk alanını geri kazan.
  • Cron ve middleware'lerdeki otomatik queue restart/start kurgusunu sadeleştir; izleme için Supervisor veya systemd yeterli olacak.
  • Altyapı normale döndüğünde Pulse'ı sadece gözlem aracı olarak düşük örnekleme ile tut veya tamamen kapat.