Linux sunucu performans analizi: ölçüm, teşhis ve ayar

Linux performans ayarı neden ölçümle başlar?

Linux sunucusu yavaşladığında ilk refleks çekirdek parametrelerini değiştirmek olur; oysa performans sorunlarının çoğu ayardan önce teşhis gerektirir. Yanlış parametre ya da tahmine dayalı değişiklik sorunu çözmez, bazen yenisini ekler. Doğru sıra şöyledir: sorunu tanımla, ölçüm al, darboğazı bul, tek bir değişiklik yap, tekrar ölç.

Darboğaz temel kaynaklardan birinde olur: işlemci, bellek, depolama ya da ağ. Uygulamanın kendi kodu veya veritabanı sorguları da yavaşlığın kaynağı olabilir; bu durumda sistem ayarı yalnızca belirtiyi gizler. Sistem yöneticisinin ilk işi, sorunun işletim sisteminde mi uygulamada mı olduğunu ayırt etmektir.

Yöntem: USE yaklaşımı ve sistematik teşhis

Teşhiste yaygın kullanılan bir yöntem, her kaynak için şu soruları sormaktır: kullanım (utilization) ne kadar, doygunluk (saturation) var mı yani işler sırada bekliyor mu, hata (errors) var mı. Bu sorular işlemci, bellek, disk ve ağ için sırayla yanıtlanır. Yüksek kullanım tek başına sorun değildir; doygunluk, yani bekleyen iş, asıl sinyaldir.

Bir diğer ilke, değişmeyen bir sıra izlemektir: önce olay anının zamanını ve etkilenen hizmeti belirle, sonra son değişiklikleri kontrol et, sonra kaynakları tara. Rastgele komut denemek yerine hipotez kurup onu doğrulayan ya da çürüten ölçümle ilerlemek zaman kazandırır. Hiçbir ölçüm geçmişi tutulmuyorsa yalnızca olay anındaki durum görünür; bu yüzden sürekli izleme sistemi kurmak ayarın ön koşuludur.

İşlemci ve süreç tarafında neye bakılır?

İşlemci tarafında temel araçlar top ve htop (süreç bazında kullanım), pidstat (süreç başına işlemci ve disk dağılımı) ve vmstat'tır. Yük ortalaması (load average) çalışan ve çalışmayı bekleyen süreçlerin ortalamasıdır; işlemci çekirdek sayısıyla birlikte yorumlanır. Yük yüksek ama işlemci boştaysa, süreçler muhtemelen disk ya da ağ beklemektedir.

İşlemci kullanımının dağılımı da bilgi verir: kullanıcı alanındaki yoğunluk uygulamayı, çekirdek alanındaki yoğunluk sistem çağrılarını ya da sürücüleri, bekleme oranı ise disk takılmalarını işaret eder. Tek bir sürecin neden yavaş olduğunu anlamak için strace ile sistem çağrılarına, perf ile işlemci örnekleme profiline bakılır. Süreç önceliği ve çekirdek ilişkilendirme ayarları ancak teşhisten sonra, gerçekten gerekliyse devreye alınır.

Bellek ve depolama teşhisi

Bellekte en sık yanlış yorumlanan şey, boş belleğin az görünmesidir. Linux kullanılmayan belleği disk önbelleği olarak kullanır; bu normaldir ve gerektiğinde serbest bırakılır. Asıl endişe verici işaretler, sürekli takas (swap) kullanımı, sayfa hatalarının artması ve çekirdeğin bellek yetersizliği nedeniyle süreç sonlandırmasıdır (OOM killer). free ve vmstat ile durum izlenir, dmesg ve günlüklerde çekirdek mesajları kontrol edilir; takas eğilimi için çekirdeğin ilgili parametresi bilinçli olarak ayarlanabilir.

Depolamada iostat ile disk bekleme süresi, kuyruk derinliği ve işlem hacmi okunur. Disk yoğun görünüyorsa sorun gerçekten diskte midir, yoksa yetersiz bellek yüzünden önbelleğin etkisiz kalması mı sorusu sorulur. Dosya sistemi seçimi, bağlama seçenekleri ve I/O zamanlayıcı ayarları iş yükü türüne göre değerlendirilir; veritabanı gibi rastgele erişimli iş yükü ile toplu yazan bir günlük sunucusu aynı ayarı istemez.

Ağ yığını ve servis yönetimi

Ağ tarafında ss ile bağlantı durumları ve kuyrukları, ip ile arayüz istatistiklerini, sar ile geçmiş trafik verisini görebilirsiniz. Bağlantı kuyruğunun dolması, yeniden iletim artışı ya da paket kayıpları, uygulama yavaşlığı gibi görünen ağ sorunlarının tipik işaretleridir. Çekirdeğin ağ tamponları ve bağlantı sınırları yoğun trafik alan sunucularda ayarlanır, ama varsayılanlar çoğu iş yükü için makuldür.

Servis yönetimi systemd ile yapılır: systemctl servis durumunu gösterir, journalctl günlüklere ulaştırır, systemd-analyze açılış süresini inceler. Servislerin kaynak sınırları (bellek, işlemci payı) cgroup üzerinden tanımlanır; bu, bir servisin diğerlerini boğmasını engeller. Servis yeniden başlatma politikası da dayanıklılığın parçasıdır: çöken bir servis otomatik ayağa kalkmalı ama sonsuz bir yeniden başlatma döngüsüne girmemelidir.

Örnek senaryo: yavaşlayan bir web sunucusu

Örneğin bir web uygulaması öğleden sonra yavaşlıyor. İşlemci kullanımına bakılır; orta düzeyde. Yük ortalaması yüksek, işlemci bekleme oranı da yüksek: işler disk beklemektedir. iostat disk bekleme süresinin yükseldiğini gösterir. pidstat hangi sürecin yazdığını gösterir: bir raporlama işi, uygulama ile aynı diske çok büyük geçici dosyalar yazmaktadır.

Çözüm çekirdek ayarı değil, mimari karardır: raporlama işi başka bir zamana alınır ya da geçici dosyalar ayrı bir diske yönlendirilir. Değişiklik sonrası aynı ölçümler tekrarlanır ve bekleme süresinin düştüğü doğrulanır. Bu örnekte parametre ayarı hiç gerekmemiştir; teşhis doğru yapıldığı için en az müdahaleyle sorun çözülmüştür.

Sık yapılan hatalar ve nasıl öğrenilir

• İnternette bulunan ayar listelerini ölçüm yapmadan uygulamak.
• Aynı anda birden fazla parametre değiştirmek; hangisinin etkisi olduğu anlaşılmaz.
• Yük ortalamasını tek başına yorumlamak ya da boş belleği az görüp panik yapmak.
• Değişiklikleri kayıt altına almamak ve eski haline dönüş yolu bırakmamak.
• Uygulama veya veritabanı sorununu işletim sistemi sorunu sanmak.
• Üretim sunucusunda test etmeden kalıcı ayar yapmak.

Öğrenmek için önce temel Linux yönetimini (süreçler, dosya sistemi, ağ, systemd) pekiştirin, sonra bir test makinesinde yapay yük üretip araçlarla gözlemleyin. Mindset kataloğundaki Linux Sistem Yönetimi ve Performans Ayarlama programı süreç ve işlemci yönetimi, bellek yönetimi ve teşhisi, depolama ve dosya sistemleri, ağ yığını ve bağlantı teşhisi, systemd ve servis yönetimi, performans metodolojisi ve araçları ile ayarlama ve sıkılaştırma modüllerini içeriyor.