Sınırlı kaynakta sunucu performansı: önce neyi optimize etmeli

Küçük bir sunucuda performansı korumanın ilk adımı bir ayar değişikliği değil, bir ölçümdür. İşlemci, bellek, disk ve ağ aynı anda tükenmez; biri sınıra önce ulaşır ve sistemin geri kalanı onu bekler. Bekleten bu kaynağa darboğaz denir. Darboğaz bilinmeden yapılan iyileştirme çoğu zaman zaten rahat olan tarafı biraz daha rahatlatır, kullanıcı tarafında ise hiçbir şey değişmez.

Yavaşlama fark edildiğinde en sık verilen karar bellek eklemektir. Oysa yavaşlığın kaynağı disk beklemesiyse bellek eklemek belirtiyi bir süre örter ve sorun ilk yoğun saatte geri döner. Sıra bu yüzden önemlidir: önce ölç, sonra tek bir şeyi değiştir, sonra aynı koşulda yeniden ölç.

Ölçüm olmadan optimizasyon tahmindir

Sağlıklı bir karşılaştırma için sunucunun boşta durumunu bilmek gerekir. Boşta durum, üzerinde ciddi bir iş yokken belleğin ne kadarının kullanıldığı, işlemci yükünün nereye oturduğu ve diskin ne kadar okuma yazma yaptığıdır. Bu kayıt olmadan “sunucu yavaşladı” cümlesi ölçülebilir bir bilgi taşımaz, çünkü karşılaştırılacak bir referans yoktur.

İşlemci tarafında bakılan değerlerden biri yük ortalamasıdır. Yük ortalaması (load average), sistemin işlenmek üzere sıraya aldığı iş miktarını gösterir ve çekirdek sayısıyla birlikte okunur. İki çekirdekli bir sunucuda sürekli ikinin üzerinde seyreden bir yük ortalaması, işlerin beklemeye başladığı anlamına gelir.

1. Sunucu sakinken bellek, işlemci ve disk kullanımını kaydet
2. Aynı değerleri yoğun saatte yeniden al ve iki kaydı yan yana koy
3. En çok sapma gösteren kaynağı darboğaz adayı olarak işaretle
4. Yalnızca tek bir ayarı değiştir, aynı anda birden fazla şeye dokunma
5. Ölçümü aynı yoğunluk koşulunda tekrarla ve sonucu not et

Tek değişiklik kuralı yavaş görünür ama zaman kazandırır. Aynı anda üç ayar birden değiştirildiğinde sonuç iyileşse bile hangisinin işe yaradığı bilinmez ve bir sonraki sorunda aynı belirsizliğe dönülür.

Dört kaynak, dört ayrı belirti

Darboğaz aramak, belirtiden geriye doğru yürümekle kolaylaşır. Aşağıdaki eşleştirme kesin bir teşhis değil, ilk bakılacak yeri daraltan bir başlangıç noktasıdır.

Bu eşleştirmenin her kuruluma birebir uyan sabit bir listeye dönüşmesi beklenmemeli. Bir sunucuda ilk dolan kaynak bellek olurken, benzer görünen bir başkasında disk beklemesi öne çıkabilir; belirleyici olan paketin adı değil, üzerinde çalışan işin karakteridir. Herkes için geçerli tek bir doğru sıralama yoktur, yalnızca o projeye ait bir sıralama vardır.

Belleği ayırmak ile belleği israf etmek

Sınırlı bellekte en sık yapılan hata, mevcut belleğin tamamını tek bir uygulamaya vermektir. İşletim sisteminin de belleğe ihtiyacı vardır; dosya önbelleği ve tampon alanları buradan beslenir. Uygulama belleğin tamamını rezerve ettiğinde sistem sık kullanılan veriyi bellekte tutamaz hale gelir ve her istekte diske gitmeye başlar. Bellek için yapılan hamle, bu noktada diski darboğaza çevirir.

Takas alanı (swap) burada bir güvenlik ağıdır, kapasite artışı değildir. Bellek dolduğunda sistemin çökmek yerine yavaşlayarak devam etmesini sağlar. Takas hareketinin sürekli görünür olması belleğin yetmediğini gösteren en açık işaretlerden biridir; o noktada yapılacak iş takası büyütmek değil, bellek tüketimini azaltmak ya da bellek miktarını gerçekten artırmaktır.

Kaynak dengesi donanım tarafında da farklı kurulabilir. Saganetwork’ün sanal sunucuları Vodafone Veri Merkezi’nin kurumsal altyapısında barındırılmaktadır ve VDS seviyeleri bu dengeyi ayrıştırır: Ekonomik VDS, SSD üzerinde çalışan temel yapıyı; Premium VDS, yüksek çekirdek sayısı isteyen ve bot çalıştıran kurulumları; Performans VDS ise yeni nesil işlemci ve NVMe SSD ile disk beklemesinin belirleyici olduğu işleri hedefler. Dar bütçeyle ilerleyen bir projede uygun fiyatlı vds tarafında kalmak mümkündür; kritik olan, seçilen yapının bellek ve çekirdek sınırının hangi noktada dolacağını baştan bilmektir. VDS paketlerinde belleğin 2 GB ile 32 GB, çekirdek sayısının 2 ile 6 arasında değiştiği bilgisi bu hesabın çıkış noktasıdır.

Disk ve ağ tarafındaki kolay kazanımlar

Disk üzerinde en hızlı geri dönüş çoğu zaman büyüyen kayıt dosyalarından gelir. Uygulama ve sistem kayıtları döndürülmezse, yani belirli bir boyutta arşivlenip eskisi silinmezse, hem yer kaplar hem de sürekli yazma yükü üretir. Aynı diskte tutulan yedekler de benzer bir maliyet doğurur; yedek almak gereklidir, ancak asıl işin çalıştığı diskle aynı yeri paylaştığında yoğun saatte onunla rekabet eder.

Veritabanı kullanan projelerde disk yükünün görünür bölümü sorgu tarafından gelir. Sık çalışan bir sorgu uygun bir indeks olmadan çalıştığında sistem gerekenden çok daha fazla veriyi okumak zorunda kalır. Bu, disk kapasitesiyle değil işin biçimiyle ilgili bir sorundur ve donanım büyütülerek kalıcı biçimde çözülmez.

Ağ tarafında bant genişliği küçük projelerde nadiren ilk darboğazdır; Saganetwork sunucularında ağ portu 1 Gbps olarak belirtilir. Sıkışma genellikle eş zamanlı bağlantı sayısında ve isteğin sunucu tarafında ne kadar sürede işlendiğinde ortaya çıkar. Statik dosyaların sıkıştırılması, gereksiz isteklerin azaltılması ve bağlantıların yeniden kullanılması, ağ ayarlarına dokunmadan hissedilir fark üretebilir.

Arka planda çalışan her şeyin bir bedeli var

Küçük bir sunucuda kaynak yönetimi çoğu zaman ekleme değil çıkarma işidir. Kurulumla birlikte gelen ama kullanılmayan servisler, ikinci bir izleme aracı ya da denenip bırakılmış bir yönetim aracı boşta bile bellek tutar ve zaman zaman işlemciyi uyandırır. Çalışan servis listesini gözden geçirip gerçekten kullanılmayanları kapatmak, ayar inceliği gerektirmeyen ve etkisi ölçülebilen bir adımdır.

Zamanlanmış görevlerin çakışması benzer bir sessiz yük üretir. Yedekleme, güncelleme ve bakım işleri aynı saate ayarlandığında sunucu günün belirli bir dakikasında ihtiyacın çok üzerinde bir yüke girer. Bu işleri yoğunluğun düştüğü saatlere yaymak, kaynak eklemeden elde edilen belirgin bir kazançtır.

Optimizasyonun bittiği yer

Her iyileştirmenin bir tavanı vardır. İsraf temizlendikten, kayıtlar düzene girdikten ve gereksiz servisler kapatıldıktan sonra kaynak normal yükte hâlâ doluyorsa karşılaşılan şey bir ayar sorunu değil kapasite sorunudur. İki durumun maliyeti farklıdır: optimizasyon zaman ister ve genellikle bir kez yapılır, kapasite değişikliği ise kurulumun yeniden planlanmasını gerektirir.

Bu ayrımı erken görmek hem gereksiz uğraşıyı hem de gereksiz büyümeyi engeller. Ölçüm kaydı tutulan bir kurulumda soru “sunucu yetiyor mu” olmaktan çıkar, “hangi kaynak hangi saatte ne kadar doluyor” haline gelir. Bu soruya sayıyla cevap verebilen bir yönetici sonraki kararını tahminle değil kendi verisiyle verir.