X

Lütfen Ülke (Bölge) Seçiniz

Türkiye (Türkçe)Türkiye (Türkçe) Worldwide (English)Worldwide (English)
X

Lütfen Para Birimi Seçiniz

₺ Türk Lirası $ US Dollar
X

Lütfen Ülke (Bölge) Seçiniz

Türkiye (Türkçe)Türkiye (Türkçe) Worldwide (English)Worldwide (English)
X

Lütfen Para Birimi Seçiniz

₺ Türk Lirası $ US Dollar

Sunucu Optimizasyonu: Kaynağı Bulup Güvenle İyileştirme

AnasayfaYazılarTeknik RehberlerSunucu Optimizasyonu: Kaynağı Bulup...

Sunucu optimizasyonu, tüm limitleri rastgele yükseltmek değil, yavaşlığın hangi kaynakta oluştuğunu kanıtlayıp yalnızca o noktayı düzeltmektir. Bunun için önce çalışma ortamını ve erişim düzeyini belirleyin; ardından aynı işlemi zaman damgasıyla yeniden çalıştırarak CPU, bellek, disk ve uygulama kayıtlarını karşılaştırın. Her değişiklikten önce mevcut değeri kaydedin ve tek seferde yalnızca bir ayarı değiştirin.

Önce ortamı ve gözlenen belirtiyi sınırlayın

Bu rehber, yönetici erişimi olan Linux tabanlı bir VPS veya özel sunucu için uygundur. Paylaşımlı hosting kullanıyorsanız işletim sistemi servislerine ve çekirdek ayarlarına erişemezsiniz; kontrol panelindeki kaynak grafikleri, PHP veya uygulama sürümü ve siteye ait hata kayıtlarıyla sınırlı kalmanız gerekir. Yönetici erişimi yoksa sistem servisini yeniden başlatmaya ya da global limitleri değiştirmeye çalışmayın.

Belirtiyi önce sınıflandırın. Her istekte yavaşlık varsa web sunucusu, uygulama havuzu veya veritabanı yolu incelenmelidir. Yalnız yoğun saatlerde gecikme oluşuyorsa kaynak doygunluğu ve eşzamanlı istek sayısı daha olasıdır. Dosya yükleme veya yedekleme sırasında sorun çıkıyorsa disk kapasitesi ve yazma gecikmesi, uzun süren raporlarda ise işlem süresi ve veritabanı sorguları ayrıca değerlendirilmelidir.

Sunucu optimizasyonu için kaynak ayrımını yapın

Yönetici panelindeki izleme ekranında CPU kullanımı, bellek tüketimi, takas alanı, disk doluluğu ve disk bekleme değerlerini aynı zaman aralığında inceleyin. Terminal erişiminiz varsa aşağıdaki salt-okunur komutlar hızlı bir ilk görüntü sağlar:

uptime
free -h
df -h

Buradaki çıktı bir ölçüm sonucu değil, yalnızca örnek bir inceleme yöntemidir. uptime sistem yükünün zaman içindeki görünümünü, free -h belleğin ve takas alanının durumunu, df -h ise dosya sistemlerinin doluluk oranını gösterir. Yüksek CPU ile birlikte tek bir uygulama işlemi öne çıkıyorsa uygulama profiline bakın; bellek azalıp takas kullanımı artıyorsa yeni PHP çalışanları veya başka süreçler açmak yerine eşzamanlı çalışan sayısını ele alın. Disk doluluğu yüksekse önce güvenli bir yedekleme ve saklama politikası planlayın; rastgele dosya silmeyin.

Beş adımda ölçerek ve tek değişkenle ilerleyin

  1. Başlangıç değerlerini kaydedin. Paneldeki kaynak grafiğinin zamanını, ilgili URL veya işlemi ve mevcut uygulama havuzu, önbellek ya da servis ayarlarını not edin. Sunucu yapılandırmasının yedeğini alın veya ilgili dosyanın ayrı bir kopyasını oluşturun. Böylece sonraki gözlemde hangi değişikliğin etkili olduğunu ayırabilirsiniz.
  2. Aynı işlemin yeni kaydını bulun. Test ettiğiniz URL'yi veya arka plan görevini bir kez çalıştırın; başlangıç ve bitiş saatini not edin. Web sunucusu erişim kaydında yanıt süresini, uygulama hata günlüğünde aynı dakikadaki kayıtları ve mümkünse işlem kimliğini arayın. Kayıt belirli bir eklenti, sorgu veya uygulama bileşenini gösteriyorsa önce o bileşenin sürümünü ve son değişikliğini inceleyin; sistem genelindeki tüm limitleri artırmayın.
  3. Kaynakla belirtiyi eşleştirin. İşlem sırasında CPU sürekli doygunsa yavaş çalışan kod, sorgu veya aşırı paralel çalışan görevleri inceleyin. CPU normal, bellek baskısı ve takas kullanımı yüksekse uygulama çalışanlarının eşzamanlı sayısını azaltmayı veya bellek tüketen görevi zamanlamayı değerlendirin. Disk beklemesi öne çıkıyorsa önbellek, günlük ve veritabanı yazma davranışını ayrı ele alın. Sonuçlar birbiriyle örtüşüyorsa ilk görülen hatayı tek neden kabul etmeyin.
  4. Tek ve geri alınabilir bir düzeltme uygulayın. Örneğin yalnızca uygulama havuzunun çalışan sayısını küçük bir adımla değiştirin; mevcut değeri ve değişiklik saatini kaydedin. Bu ayarı artırmak CPU'yu veya belleği daha fazla tüketebilir, azaltmak ise isteklerin kuyrukta beklemesine yol açabilir. Değişiklik sağlayıcı paneline bağlıysa yalnızca o panelde belgelenen alanları kullanın; çekirdek, güvenlik veya TLS ayarlarını ilgisiz bir performans düzeltmesi olarak değiştirmeyin.
  5. Aynı işlemi tekrarlayıp yeni kanıtı karşılaştırın. Değişiklikten sonra aynı URL'yi veya görevi yeniden çalıştırın ve yalnızca değişiklikten sonraki erişim kaydı ile hata günlüğünü inceleyin. Yanıt süresi düzelirken hata oluşmuyorsa ve bellek takası artmıyorsa ayar kabul edilebilir bir yönde ilerlemiş olabilir; yine de daha uzun bir yoğunluk aralığı izleyin. Sorun sürerse önceki değeri geri yükleyin ve bir sonraki kaynağı tek başına inceleyin.

Belirtiye göre doğru düzeltmeyi seçin

Belirti CPU yoğunluğuysa, tek bir işlemin sürekli üst sıralarda görünmesi uygulama veya sorgu incelemesini gerektirir; tüm sunucunun işlemci önceliğini rastgele değiştirmek güvenli bir ilk adım değildir. Belirti bellek baskısıysa, önce süreç başına tüketimi ve çalışan sayısını karşılaştırın. Uygulama havuzunu büyütmek yalnızca boş bellek yeterliyse anlamlıdır; takas alanı aktifken bu değişiklik gecikmeyi artırabilir.

Belirti disk doluluğuysa, hangi dosya sisteminin dolduğunu ve büyümenin günlükler, yedekler veya yüklenen içerik kaynaklı olup olmadığını belirleyin. Saklama süresini kontrollü biçimde düzenleyin ve silmeden önce yedekleme politikasını doğrulayın. Belirti yalnız bir URL'de görülüyorsa, sunucu genel ayarlarını değiştirmek yerine o URL'nin uygulama kaydını, veritabanı sorgusunu ve önbellek davranışını karşılaştırın.

Hipotetik bir seçim örneği

Örneğin, bir içerik yönetim sitesinde yönetici paneli yalnız yoğun saatlerde yavaşlıyor ve aynı dakikadaki kayıtlarda CPU'nun yükseldiği, belleğin ise sabit kaldığı varsayılsın. Bu gözlem, önce uygulamanın pahalı sorgusunu veya eşzamanlı görevini incelemeyi destekler; bellek limitini artırmak doğrudan gerekçeli değildir. Eğer yeni incelemede CPU normal, takas kullanımı yüksek bulunursa karar değişir ve çalışan sayısı ile bellek tüketimi ele alınır. Her iki sonuçta da önceki yapılandırma korunur ve ilk değişiklik geri alınabilir tutulur.

İlk iyileştirmeden sonra izleme sınırını belirleyin

Bir ayarın tek başarılı istekte düzelmesi yeterli kanıt değildir. Aynı işlemi normal ve yoğun kullanım aralıklarında karşılaştırın; hata oranı, yanıt süresi, CPU, bellek ve disk beklemesini birlikte izleyin. Yeni hata kaydı oluşuyor veya takas kullanımı belirgin biçimde yükseliyorsa önceki ayara dönün. Sorunun kapsamını belirlemek için sunucu kiralama çözümleri hakkında ortam seçeneklerini inceleyebilirsiniz; ancak bağlantı, mevcut uygulamadaki darboğazın kendiliğinden düzeldiğini göstermez. Güvenli sonraki adım, değişiklik günlüğünü ve yeni zaman damgalı kayıtları kullanarak yalnızca bir sonraki kanıtlanmış darboğaza yönelmektir.


Top