- Konu sahibi
- #1
İlk kez sunucu optimize ediyorsanız doğrudan ayar değiştirmek yerine önce mevcut durumu ölçün, yedek alın ve darboğazı belirleyin. Ardından işletim sistemi ile paketleri güncelleyin, gereksiz servisleri kapatın, web sunucusu ve veritabanı ayarlarını mevcut RAM, CPU ve trafik miktarına göre düzenleyin. Her değişiklikten sonra aynı ölçümü tekrarlayarak gerçekten iyileşme olup olmadığını kontrol edin; ölçmeden yapılan optimizasyon, sorunun nedenini gizleyebilir veya yeni kesintilere yol açabilir.
Sunucuda işlem yapmadan önce yönetici erişiminizin çalıştığını, acil durumda kullanabileceğiniz ikinci bir erişim yöntemini ve güncel yedeği hazır bulundurun. Özellikle yapılandırma dosyalarını değiştirecekseniz, dosyanın önceki hâlini ayrı bir konuma kopyalayın. Sanal sunucularda sağlayıcının anlık görüntü özelliği kullanılabilir; ancak bu görüntünün geri yüklenebilir olduğunu ayrıca doğrulamak gerekir.
İlk ölçümde en az şu bilgileri kaydedin:
Optimizasyonun ilk hedefi “her şeyi hızlandırmak” değil, isteği yavaşlatan veya kaynak tüketimini artıran noktayı bulmaktır. CPU sürekli yüksekse işlemciye yük bindiren uygulama, PHP işlemleri, arka plan görevleri veya veritabanı sorguları incelenir. RAM tükeniyorsa çalışan süreçlerin bellek kullanımı, önbellek boyutları ve uygulamanın süreç sayısı kontrol edilir. Disk beklemesi yüksekse büyük günlükler, yavaş depolama, yoğun veritabanı işlemleri veya gereksiz disk yazma işlemleri araştırılır.
Aşağıdaki ayrım, ilk müdahalenin hangi alanda yapılacağını belirlemeye yardımcı olur:
Bir kaynağın kısa süreli olarak yüksek kullanılması tek başına problem kanıtı değildir. Örneğin yedekleme sırasında disk veya CPU kullanımı artabilir. Sorun sayılabilmesi için yoğunluğun normal çalışma sırasında tekrarlanması, yanıt süresini veya hata oranını etkilemesi ve ölçümlerde aynı bileşenle ilişkilendirilebilmesi gerekir.
Önce işletim sistemi güvenlik ve hata düzeltmelerini, kullandığınız dağıtımın desteklediği güncelleme yöntemiyle uygulayın. Güncelleme öncesinde çalışan uygulamanın, kullandığı çalışma zamanı sürümünün ve kritik eklentilerin uyumluluğunu kontrol edin. Güncelleme tamamlandıktan sonra yalnızca komutun başarıyla bitmesine bakmayın; web sitesi, SSH erişimi, veritabanı bağlantısı ve arka plan görevlerini de test edin.
Çalışmadığı hâlde otomatik başlayan servisleri belirleyin. Bir servisi kapatmadan önce hangi uygulamanın ona bağlı olduğunu, yeniden başlatma sonrasında tekrar gerekip gerekmediğini ve yapılandırmasının yedeklenip yedeklenmediğini kontrol edin. Kullanılmayan servisi kapatmak RAM ve CPU tüketimini azaltabilir; fakat yalnızca portu kapatmak servisin gerçekten gereksiz olduğunu kanıtlamaz. Bağımlı bir uygulama çalışmayı bırakırsa servisi yeniden etkinleştirip günlüklerdeki hata mesajını inceleyin.
Disk doluluğunu da erken aşamada kontrol edin. Günlük dosyaları, önbellekler, eski yedekler ve geçici dosyalar zamanla alanı tüketebilir. Dosya silmeden önce bunların uygulama tarafından hâlâ kullanılıp kullanılmadığını ve yedekleme amacı taşıyıp taşımadığını doğrulayın. Disk doluluğu düzeltildiğinde yanıt süresi iyileşebilir; ancak bu, uygulama kodunun veya veritabanı sorgularının verimli olduğu anlamına gelmez.
Web sunucusunda ilk kontrol edilmesi gerekenler bağlantı sayısı, çalışan işçi veya süreç sayısı, keep-alive davranışı, statik dosyaların sunumu ve sıkıştırma öncesi trafik miktarıdır. Ayarları sunucunun RAM miktarına bakmadan yükseltmek doğru değildir. Her ek süreç veya işçi bellekte yer tüketebilir; sayı fazla artırılırsa istekler hızlanmak yerine RAM tükenmesi ve takas nedeniyle yavaşlayabilir.
Statik dosyaları uygulama sürecinden ayırmak, tarayıcı önbelleklemesini uygun şekilde kullanmak ve gereksiz büyük dosyaları küçültmek genellikle ilk güvenli iyileştirmelerdendir. Dinamik sayfalarda ise asıl kazanç, yavaş sorguların ve gereksiz uygulama işlemlerinin bulunmasıyla elde edilir. Önbellek eklemek, hatalı sorguyu ortadan kaldırmaz; yalnızca aynı isteğin bazı tekrarlarını geçici olarak gizleyebilir.
Değişiklikleri şu sırayla uygulamak daha güvenlidir:
Veritabanı yavaşlığı çoğunlukla bellek miktarından önce sorgu planı, eksik veya yanlış indeks, gereksiz veri çekme ve uzun süren kilitlerle ilgilidir. Önce en uzun süren ve en sık çalışan sorguları belirleyin. Sorgunun hangi tabloları taradığını, kaç satır döndürdüğünü ve indeks kullanıp kullanmadığını inceleyin. Bir indeksi eklemeden önce ilgili sütunun aramalarda, sıralamalarda veya birleştirmelerde gerçekten kullanıldığını kontrol edin; gereksiz indeksler okuma işlemini hızlandırırken yazma işlemlerini ağırlaştırabilir ve disk alanı tüketebilir.
Veritabanı önbelleklerini mevcut RAM’e göre ayarlayın. İşletim sistemi, web sunucusu, uygulama süreçleri ve veritabanı aynı belleği paylaşır. Veritabanına ayrılan alanı artırmak diğer süreçleri takasa itiyorsa toplam performans düşebilir. Değişiklikten sonra yalnız veritabanı sorgu süresini değil, takas kullanımını, uygulama hatalarını ve toplam yanıt süresini birlikte izleyin.
Güvenlik ayarlarını kapatmak veya erişimleri genişletmek performans optimizasyonu değildir. Yönetim portlarını mümkün olduğunca kısıtlayın, kullanılmayan servisleri kaldırın, güçlü kimlik doğrulama kullanın ve günlüklerde başarısız giriş denemelerini izleyin. Web uygulamasında oran sınırlama, istek boyutu sınırı ve uygun zaman aşımı değerleri; kötüye kullanımı azaltırken kaynak tüketiminin kontrol altında tutulmasına yardımcı olabilir.
Yedekleme işlemini de performans planına dahil edin. Yedekleme sırasında CPU, disk ve ağ kullanımı artabilir. Bu nedenle yedekleme zamanını yoğun trafikle çakıştırmamak, yedeklerin tamamlandığını doğrulamak ve gerektiğinde tek bir dosya veya veritabanı kaydını geri yükleyebilmek gerekir. Yedek dosyasının mevcut olması, geri yüklemenin başarılı olduğunu tek başına göstermez.
Optimizasyon sonrası değerlendirmeyi tek bir değere göre yapmayın. En azından yanıt süresi, hata oranı, CPU, RAM, disk beklemesi ve trafik düzeyini birlikte karşılaştırın. Yanıt süresi düşerken hata oranı yükseliyorsa değişiklik başarılı sayılmaz. CPU kullanımı azalırken RAM ve takas artıyorsa yük başka bir kaynağa taşınmış olabilir. Kaynak kullanımı yükselse bile yanıt süresi ve hata oranı kabul edilebilir düzeyde kalıyorsa bu, sunucunun daha fazla iş yaptığı anlamına gelebilir; yine de kapasite sınırına yaklaşılıp yaklaşılmadığı izlenmelidir.
Sorun devam ediyorsa destek veya altyapı sağlayıcısına belirsiz bir “sunucu yavaş” bildirimi göndermek yerine şu bilgileri ekleyin: sorunun başladığı tarih ve saat, etkilenen alan adı veya hizmet, örnek istek zamanı, hata kodu, yanıt süresi değişimi, CPU-RAM-disk ölçümleri, ilgili günlük satırları ve son yapılan değişiklik. Talebiniz, örneğin “2026-10-25 14:00-14:20 UTC arasında istekler 800 ms’den 4 saniyeye çıktı; CPU yüzde 35 civarında, disk beklemesi yükseliyor ve şu işlem günlükte tekrarlanıyor; depolama gecikmesinin incelenmesini istiyorum” gibi ölçülebilir olmalıdır.
Başlangıç seviyesinde en doğru hedef, bütün ayarları değiştirmek değil; ölçülebilir bir darboğazı küçük bir değişiklikle azaltıp sonucu doğrulamaktır. Sorunun kaynağı uygulama sorgusuysa daha büyük sunucuya geçmek yalnızca sorunu geciktirebilir. Kaynaklar sürekli sınırda kalıyor ve uygulama tarafı düzeltildiği hâlde yanıt süresi yükseliyorsa o zaman daha fazla RAM, CPU, hızlı depolama veya yatay ölçekleme seçeneği mevcut ölçümlerle gerekçelendirilmelidir.
Değişiklik yapmadan önce mevcut durumu kaydedin
Sunucuda işlem yapmadan önce yönetici erişiminizin çalıştığını, acil durumda kullanabileceğiniz ikinci bir erişim yöntemini ve güncel yedeği hazır bulundurun. Özellikle yapılandırma dosyalarını değiştirecekseniz, dosyanın önceki hâlini ayrı bir konuma kopyalayın. Sanal sunucularda sağlayıcının anlık görüntü özelliği kullanılabilir; ancak bu görüntünün geri yüklenebilir olduğunu ayrıca doğrulamak gerekir.
İlk ölçümde en az şu bilgileri kaydedin:
- CPU kullanımının normal, yoğun ve trafik almayan zamandaki seviyesi.
- Toplam ve kullanılabilir RAM miktarı; takas alanının kullanılıp kullanılmadığı.
- Disk doluluk oranı ve disk bekleme süresi.
- Ortalama yanıt süresi, hata oranı ve aynı anda çalışan istek sayısı.
- Çalışan servisler, dinleyen portlar ve son dönemde oluşan sistem uygulama günlükleri.
top veya htop CPU ve RAM kullanımını, free -h bellek durumunu, df -h disk doluluğunu, ss -tulpn ise dinleyen servisleri incelemek için kullanılabilir. Bu komutların çıktısı tek başına sorun teşhisi koymaz; yalnızca hangi kaynağın daha ayrıntılı incelenmesi gerektiğini gösterir.Darboğazı ayırt ederek ilerleyin
Optimizasyonun ilk hedefi “her şeyi hızlandırmak” değil, isteği yavaşlatan veya kaynak tüketimini artıran noktayı bulmaktır. CPU sürekli yüksekse işlemciye yük bindiren uygulama, PHP işlemleri, arka plan görevleri veya veritabanı sorguları incelenir. RAM tükeniyorsa çalışan süreçlerin bellek kullanımı, önbellek boyutları ve uygulamanın süreç sayısı kontrol edilir. Disk beklemesi yüksekse büyük günlükler, yavaş depolama, yoğun veritabanı işlemleri veya gereksiz disk yazma işlemleri araştırılır.
Aşağıdaki ayrım, ilk müdahalenin hangi alanda yapılacağını belirlemeye yardımcı olur:
| Belirti | Muhtemel neden | İlk kontrol | Sonraki adım |
|---|---|---|---|
| CPU uzun süre yüksek | Yoğun uygulama işlemleri, hatalı sorgular veya fazla süreç | En çok CPU kullanan süreç ve uygulama günlükleri | Sorgu, kod veya süreç sayısını düzeltip yeniden ölçmek |
| RAM sürekli dolu, takas artıyor | Yetersiz bellek, fazla çalışan süreç veya büyük önbellek | Süreçlerin bellek kullanımı ve takas hareketi | Gereksiz süreçleri azaltmak, ayarları küçültmek veya RAM planlamak |
| Disk beklemesi yüksek | Yavaş depolama, yoğun yazma veya dolu disk | Disk doluluğu, günlükler ve disk kullanımını oluşturan süreçler | Günlükleri düzenlemek, yazma yükünü azaltmak veya depolamayı iyileştirmek |
| Yanıt süresi artıyor, CPU normal | Veritabanı, ağ, dış API veya uygulama beklemesi | İstek izleri, sorgu süreleri ve dış bağlantılar | Bekleme noktasını ayrı ölçüp ilgili bileşeni düzeltmek |
İşletim sistemi ve servisleri sadeleştirin
Önce işletim sistemi güvenlik ve hata düzeltmelerini, kullandığınız dağıtımın desteklediği güncelleme yöntemiyle uygulayın. Güncelleme öncesinde çalışan uygulamanın, kullandığı çalışma zamanı sürümünün ve kritik eklentilerin uyumluluğunu kontrol edin. Güncelleme tamamlandıktan sonra yalnızca komutun başarıyla bitmesine bakmayın; web sitesi, SSH erişimi, veritabanı bağlantısı ve arka plan görevlerini de test edin.
Çalışmadığı hâlde otomatik başlayan servisleri belirleyin. Bir servisi kapatmadan önce hangi uygulamanın ona bağlı olduğunu, yeniden başlatma sonrasında tekrar gerekip gerekmediğini ve yapılandırmasının yedeklenip yedeklenmediğini kontrol edin. Kullanılmayan servisi kapatmak RAM ve CPU tüketimini azaltabilir; fakat yalnızca portu kapatmak servisin gerçekten gereksiz olduğunu kanıtlamaz. Bağımlı bir uygulama çalışmayı bırakırsa servisi yeniden etkinleştirip günlüklerdeki hata mesajını inceleyin.
Disk doluluğunu da erken aşamada kontrol edin. Günlük dosyaları, önbellekler, eski yedekler ve geçici dosyalar zamanla alanı tüketebilir. Dosya silmeden önce bunların uygulama tarafından hâlâ kullanılıp kullanılmadığını ve yedekleme amacı taşıyıp taşımadığını doğrulayın. Disk doluluğu düzeltildiğinde yanıt süresi iyileşebilir; ancak bu, uygulama kodunun veya veritabanı sorgularının verimli olduğu anlamına gelmez.
Web sunucusu ve uygulama katmanını ayarlayın
Web sunucusunda ilk kontrol edilmesi gerekenler bağlantı sayısı, çalışan işçi veya süreç sayısı, keep-alive davranışı, statik dosyaların sunumu ve sıkıştırma öncesi trafik miktarıdır. Ayarları sunucunun RAM miktarına bakmadan yükseltmek doğru değildir. Her ek süreç veya işçi bellekte yer tüketebilir; sayı fazla artırılırsa istekler hızlanmak yerine RAM tükenmesi ve takas nedeniyle yavaşlayabilir.
Statik dosyaları uygulama sürecinden ayırmak, tarayıcı önbelleklemesini uygun şekilde kullanmak ve gereksiz büyük dosyaları küçültmek genellikle ilk güvenli iyileştirmelerdendir. Dinamik sayfalarda ise asıl kazanç, yavaş sorguların ve gereksiz uygulama işlemlerinin bulunmasıyla elde edilir. Önbellek eklemek, hatalı sorguyu ortadan kaldırmaz; yalnızca aynı isteğin bazı tekrarlarını geçici olarak gizleyebilir.
Değişiklikleri şu sırayla uygulamak daha güvenlidir:
- Mevcut yapılandırma dosyasını yedekleyin ve hangi satırı neden değiştirdiğinizi not edin.
- Önce tek bir küçük değişiklik yapın; aynı anda web sunucusu, PHP çalışma zamanı ve veritabanı ayarlarını değiştirmeyin.
- Yapılandırma sözdizimini, ilgili yazılımın desteklediği test yöntemiyle doğrulayın.
- Değişikliği yeniden yükleyin veya yeniden başlatın; kesinti oluşturup oluşturmadığını izleyin.
- Örnek sayfa, giriş işlemi, dosya yükleme, yönetim paneli ve API isteklerini test edin.
- Yanıt süresi, hata oranı ve kaynak kullanımını önceki ölçümle karşılaştırın.
Veritabanını rastgele büyütmeyin
Veritabanı yavaşlığı çoğunlukla bellek miktarından önce sorgu planı, eksik veya yanlış indeks, gereksiz veri çekme ve uzun süren kilitlerle ilgilidir. Önce en uzun süren ve en sık çalışan sorguları belirleyin. Sorgunun hangi tabloları taradığını, kaç satır döndürdüğünü ve indeks kullanıp kullanmadığını inceleyin. Bir indeksi eklemeden önce ilgili sütunun aramalarda, sıralamalarda veya birleştirmelerde gerçekten kullanıldığını kontrol edin; gereksiz indeksler okuma işlemini hızlandırırken yazma işlemlerini ağırlaştırabilir ve disk alanı tüketebilir.
Veritabanı önbelleklerini mevcut RAM’e göre ayarlayın. İşletim sistemi, web sunucusu, uygulama süreçleri ve veritabanı aynı belleği paylaşır. Veritabanına ayrılan alanı artırmak diğer süreçleri takasa itiyorsa toplam performans düşebilir. Değişiklikten sonra yalnız veritabanı sorgu süresini değil, takas kullanımını, uygulama hatalarını ve toplam yanıt süresini birlikte izleyin.
Güvenlik ve performansı birlikte koruyun
Güvenlik ayarlarını kapatmak veya erişimleri genişletmek performans optimizasyonu değildir. Yönetim portlarını mümkün olduğunca kısıtlayın, kullanılmayan servisleri kaldırın, güçlü kimlik doğrulama kullanın ve günlüklerde başarısız giriş denemelerini izleyin. Web uygulamasında oran sınırlama, istek boyutu sınırı ve uygun zaman aşımı değerleri; kötüye kullanımı azaltırken kaynak tüketiminin kontrol altında tutulmasına yardımcı olabilir.
Yedekleme işlemini de performans planına dahil edin. Yedekleme sırasında CPU, disk ve ağ kullanımı artabilir. Bu nedenle yedekleme zamanını yoğun trafikle çakıştırmamak, yedeklerin tamamlandığını doğrulamak ve gerektiğinde tek bir dosya veya veritabanı kaydını geri yükleyebilmek gerekir. Yedek dosyasının mevcut olması, geri yüklemenin başarılı olduğunu tek başına göstermez.
Sonuçları nasıl yorumlayacağınızı belirleyin
Optimizasyon sonrası değerlendirmeyi tek bir değere göre yapmayın. En azından yanıt süresi, hata oranı, CPU, RAM, disk beklemesi ve trafik düzeyini birlikte karşılaştırın. Yanıt süresi düşerken hata oranı yükseliyorsa değişiklik başarılı sayılmaz. CPU kullanımı azalırken RAM ve takas artıyorsa yük başka bir kaynağa taşınmış olabilir. Kaynak kullanımı yükselse bile yanıt süresi ve hata oranı kabul edilebilir düzeyde kalıyorsa bu, sunucunun daha fazla iş yaptığı anlamına gelebilir; yine de kapasite sınırına yaklaşılıp yaklaşılmadığı izlenmelidir.
Sorun devam ediyorsa destek veya altyapı sağlayıcısına belirsiz bir “sunucu yavaş” bildirimi göndermek yerine şu bilgileri ekleyin: sorunun başladığı tarih ve saat, etkilenen alan adı veya hizmet, örnek istek zamanı, hata kodu, yanıt süresi değişimi, CPU-RAM-disk ölçümleri, ilgili günlük satırları ve son yapılan değişiklik. Talebiniz, örneğin “2026-10-25 14:00-14:20 UTC arasında istekler 800 ms’den 4 saniyeye çıktı; CPU yüzde 35 civarında, disk beklemesi yükseliyor ve şu işlem günlükte tekrarlanıyor; depolama gecikmesinin incelenmesini istiyorum” gibi ölçülebilir olmalıdır.
Başlangıç seviyesinde en doğru hedef, bütün ayarları değiştirmek değil; ölçülebilir bir darboğazı küçük bir değişiklikle azaltıp sonucu doğrulamaktır. Sorunun kaynağı uygulama sorgusuysa daha büyük sunucuya geçmek yalnızca sorunu geciktirebilir. Kaynaklar sürekli sınırda kalıyor ve uygulama tarafı düzeltildiği hâlde yanıt süresi yükseliyorsa o zaman daha fazla RAM, CPU, hızlı depolama veya yatay ölçekleme seçeneği mevcut ölçümlerle gerekçelendirilmelidir.
