PHP-FPM Nedir? Process Manager Ayarları Nasıl Çalışır? teşhisinde önce belirtinin hangi katmanda oluştuğunu ayırmak gerekir: işletim sistemi, web sunucusu, PHP/runtime, disk, ağ veya kontrol paneli. Bu ayrım yapılmadan uygulanan değişiklikler yeni sorunlar üretebilir.
PHP-FPM Nedir? Process Manager Ayarları Nasıl Çalışır için doğru başlangıç
Sunucu tarafında ilk adım değişiklik yapmak değil ölçüm almaktır. Servis durumu, disk/inode, RAM, load ve ilgili error log aynı zaman aralığında kaydedildiğinde semptomun gerçek kaynağı daha hızlı ayrılır.
1. pool
pool aşamasında önce mevcut servis durumunu, kaynak kullanımını ve ilgili log zaman aralığını kaydedin. Bir servisi yeniden başlatmadan veya konfigürasyon değiştirmeden önce hatanın tekrar üretilebilir olup olmadığını doğrulamak teşhisi kolaylaştırır.
- pool: mevcut değer ile hedef sonucu yan yana kaydedin.
- Disk, inode, RAM ve process durumunu ölçün.
- Değişiklikten önce konfigürasyon/yedek alın.
- Düzeltme sonrası web, cron ve bağımlılık testlerini yapın.
2. pm dynamic/ondemand
pm dynamic/ondemand için panel arayüzü tek başına yeterli değildir. İşletim sistemi ve servis seviyesindeki loglar, disk/inode kullanımı, process durumu ve port dinleme bilgisi birlikte incelendiğinde sorunun gerçek katmanı ortaya çıkar.
- Servis ve sistem loglarını aynı zaman aralığında inceleyin.
- pm dynamic/ondemand: mevcut değer ile hedef sonucu yan yana kaydedin.
- Değişiklikten önce konfigürasyon/yedek alın.
- Düzeltme sonrası web, cron ve bağımlılık testlerini yapın.
3. worker kapasitesi
worker kapasitesi üzerinde düzeltme yaparken önce düşük riskli adımı uygulayın. Dosya silme, paket yükseltme veya servis konfigürasyonu değiştirme gibi geri dönüşü zor işlemlerden önce yedek alın ve önceki yapılandırmayı ayrı dosyada saklayın.
- Servis ve sistem loglarını aynı zaman aralığında inceleyin.
- Disk, inode, RAM ve process durumunu ölçün.
- worker kapasitesi: mevcut değer ile hedef sonucu yan yana kaydedin.
- Düzeltme sonrası web, cron ve bağımlılık testlerini yapın.
4. slow log
slow log sonrasında yalnız ana sayfayı açmakla yetinmeyin. PHP çalışması, cron, SSL, mail/API bağlantıları ve gerekiyorsa panel işlemleri ayrı ayrı test edilmelidir; çünkü servis ayağa kalksa bile uygulama bağımlılıklarından biri bozuk kalabilir.
- Servis ve sistem loglarını aynı zaman aralığında inceleyin.
- Disk, inode, RAM ve process durumunu ölçün.
- Değişiklikten önce konfigürasyon/yedek alın.
- slow log: mevcut değer ile hedef sonucu yan yana kaydedin.
Önerilen uygulama sırası
- Mevcut yapı ve bağımlılıkları kaydedin.
- Değişikliği mümkün olan en dar kapsamda uygulayın.
- pool: ilk doğrulama noktasını tamamlamadan sonraki adıma geçmeyin.
- Kullanıcı akışını ve bağlı servisleri ayrıca test edin.
- Sonuç beklenen gibi değilse önceki yapılandırmaya dönün ve kök nedeni yeniden ölçün.
Sık yapılan hatalar
Sunucu sorunlarında en riskli yaklaşım, nedeni doğrulamadan log, cache veya yedek dosyalarını topluca silmek ya da servisleri art arda yeniden başlatmaktır. Bu davranış belirtinin kaynağını gizleyebilir. Önce ölçüm alın, sonra tek değişiklik yapın ve sonucu aynı metriklerle karşılaştırın.
Doğrulama ve geri alma
Düzeltme sonrası servis yalnız 'active' görünmemeli; gerçek istek altında doğru cevap vermelidir. HTTP yanıtı, error log, kaynak tüketimi ve arka plan görevlerini birkaç dakika izleyin. Sorun tekrar ederse son değişikliği geri alabilecek dosya/yedek yolunu hazır tutun.
Kaynak ve ilgili hizmet
Teknik ayrıntılarda ürün veya standardın güncel resmî dokümantasyonunu esas alın: resmî teknik kaynak. UST Bilişim tarafında ilgili altyapı veya web projesi için hizmetlerimizi inceleyebilir, mevcut sisteminizin analizi için iletişim sayfasından bize ulaşabilirsiniz.
Bu konuyla birlikte okuyun
Bilgiyi uygulanabilir projeye dönüştürelim.
İhtiyacınızı teknik, operasyonel ve ticari açıdan değerlendirip doğru çözüm yol haritasını birlikte oluşturalım.
Projenizi Anlatın
