Yazılım Yavaşladığında Nereye Bakılır? Teşhis Rehberi

Çalışan bir iş yazılımı yavaşladığında doğru ilk hareket sunucuyu büyütmek değil, yavaşlığın neresi olduğunu daraltmaktır. "Sistem yavaş" cümlesi bir teşhis değildir; hangi ekranın, hangi saatte, hangi kullanıcıda ve ne kadar yavaş olduğu bulunmadan yapılan her müdahale tahmine dayanır.

Aşağıda yavaşlığı daraltma sırasını, ölçmenin neden ilk adım olduğunu, en sık karşılaşılan darboğazları ve kalıcı çözümü ele alıyoruz.

Önce "ne yavaş" sorusunu daraltın

Teşhisin tamamı bu daraltmayla başlar ve çoğu zaman burada biter.

• Tek ekran mı, tüm sistem mi? Sadece bir rapor ya da liste yavaşsa sorun o sorgudadır. Her şey yavaşsa veritabanı, sunucu ya da ağ tarafına bakılır.
• Her zaman mı, belirli saatte mi? Sabah ilk saatlerde ya da ay sonunda yoğunlaşan yavaşlık, yük ya da zamanlanmış bir işin çakışmasına işaret eder.
• Herkeste mi, belirli kullanıcıda mı? Tek kullanıcıda ise onun ağı, konumu ya da yetki kapsamı farklı olabilir; geniş yetkili kullanıcı daha çok satır çeker.
• Her veride mi, belirli kayıtta mı? Bazı müşteri ya da ürün kayıtlarında yavaşlık, o kayda bağlı hareket sayısının büyüklüğünü gösterir.
• İlk açılışta mı, sonrasında da mı? Yalnızca ilk açılış yavaşsa önbellek ısınması, her seferinde yavaşsa sorgunun kendisi söz konusudur.
• Ne zaman başladı? Belirli bir tarihten sonra başlayan yavaşlık o tarihteki bir değişiklikle ilişkilidir; veri büyümesi kaynaklı yavaşlık tedricidir.

Bu altı sorunun cevabı bakılacak yeri genellikle tek bir alana indirir. Daraltma yapılmadan başlayan çalışmalar her katmanda aynı anda değişiklik yapıp sonucu ölçemez hâle gelir.

Ölçmeden müdahale edilmez

Kullanıcının "yavaş" dediği şey ile ölçülen süre çoğu zaman aynı değildir. Bir ekran kısa sürede açıldığı hâlde günde yüz kez açıldığı için dayanılmaz bulunabilir; bir rapor çok daha uzun sürdüğü hâlde seyrek kullanıldığı için şikâyet konusu olmaz. Bu yüzden ilk iş süreyi kayda geçirmektir.

Ölçüm basit tutulabilir: hangi işlem, hangi saatte, kaç saniye sürdü ve o sırada kaç kullanıcı vardı. Dört sütunlu bir kayıt bile teşhisi tahminden çıkarır. Müdahaleden sonra aynı ölçüm tekrarlanır; "şimdi daha iyi oldu" ifadesi ölçüm değildir. Sürenin nerede geçtiği de ayrılmalıdır: sorgu mu uzun sürüyor, uygulama mı hesaplıyor, veri mi ağda bekliyor, tarayıcı mı çiziyor? Dört yerin çözümü tamamen farklıdır ve yanlış katmanda yapılan iyileştirme fark yaratmaz.

Belirtiden muhtemel nedene

Sık karşılaşılan nedenler

Eksik indeks. En yaygın tek neden budur. Veri azken tabloyu baştan sona taramak hissedilmez; tablo büyüdükçe aynı sorgu doğrusal olarak uzar. Teşhis, sorgunun planına bakıp tam tablo taraması yapıp yapmadığını görmektir. Çözüm filtrelenen ve birleştirilen kolonlara indeks koymaktır; gereğinden fazlası ise zarar verir, çünkü her yazma işlemi indeksleri de güncellemek zorundadır.

Gereğinden fazla satır çekmek. Ekranın kullanıcıya elli satır göstermesi, veritabanından elli satır çektiği anlamına gelmez; pek çok ekran bütün kayıtları çeker, uygulama içinde filtreler ve ilk elli tanesini basar. Filtreleme ve sıralamanın veritabanında yapılması başka hiçbir şey değişmeden ciddi fark yaratır.

Döngü içinde tek tek sorgu (N+1). Yüz satırlık bir liste çizilirken her satır için müşteri adını ayrı sorguyla okumak yüz bir sorgu demektir. Her biri hızlı olduğu için hiçbiri yavaş sorgu kaydına düşmez, toplam ise kabul edilemez. Bir ekran açılışında kaç sorgu çalıştığına bakılır; çözüm ilişkili veriyi toplu okumaktır.

Rapor yükü ve arşivlenmeyen tablolar. Rapor sorguları geniş tarih aralıklarını tarar; canlı veritabanında koştuklarında işlem gören kayıtlarla yarışır ve bir kişinin aldığı rapor sipariş giren herkesi bekletir. Benzer biçimde hareket, kayıt izi ve bildirim tabloları temizlenmezse yıllar içinde ana veriden kat kat büyür. Arşiv politikası veri silmek değil, veriyi canlı işlem tablosundan ayırmak anlamına gelir.

Kuyruk, depolama ve ağ. Dış sistemlere giden işlemler kuyruğa alınıyorsa kuyruğun uzunluğu bir sağlık göstergesidir; tüketici yetişemediğinde kuyruk şişer ve kullanıcı bunu "işlem geçmiyor" olarak hisseder. Belge ekleri ve çıktı dosyaları düzenlenmediğinde depolama dolar, tek dizinde on binlerce dosya birikir. VPN üzerinden bağlanan kullanıcılar içinse her istek fazladan gecikme taşır; sunucu ölçümleri normalken kullanıcı yavaşlık yaşıyorsa ölçüm onun bulunduğu noktadan tekrarlanır.

Donanım büyütmek ne zaman çözüm, ne zaman erteleme

Kaynak gerçekten tükeniyorsa büyütmek doğru karardır: işlemci sürekli üst sınırdaysa, bellek yetmediği için disk takası yapılıyorsa ya da disk yükün altında kalıyorsa sonuç doğrudan alınır. İşlem hacmi gerçekten arttıysa da büyütme kaçınılmazdır.

Buna karşılık darboğaz bir sorgunun yapısındaysa donanım yalnızca zaman kazandırır; indeksi olmayan bir sorgu daha hızlı makinede de aynı tabloyu baştan sona tarar ve aynı yavaşlık birkaç ay sonra daha pahalı bir makinede geri döner. Ayırt etmenin basit yolu şudur: kaynak kullanımı yüksek değilken sistem yavaşsa sorun kaynakta değildir. En sağlıklı sıra, ölçüp en pahalı birkaç sorguyu düzeltmek, sonra kalan ihtiyacı donanımla karşılamaktır.

Önbellek: nerede işe yarar, nerede risk

Önbellek, aynı sonucun tekrar tekrar hesaplanmasını önlediği yerde çok etkilidir; nadiren değişen veriler için neredeyse bedava bir kazançtır: kategori ağacı, il listeleri, birim tanımları, menü ve yetki şablonları.

Riskli olduğu yer sık değişen ve kararı etkileyen veridir. Stok miktarı, güncel fiyat, cari bakiye ve açık sipariş durumu önbellekten eski değerle okunduğunda yazılım yanlış bir sayıyı doğru gibi gösterir; bu yavaşlıktan daha büyük bir sorundur, çünkü yavaş sistem fark edilir, yanlış sayı fark edilmez. Bu yüzden iki şey yazılı olmalıdır: hangi verinin ne kadar süre tutulacağı ve o veri değiştiğinde önbelleğin nasıl geçersiz kılınacağı. Geçersiz kılma kuralı yoksa önbellek gecikmeli bir veri hatası kaynağıdır.

Raporları işlem yükünden ayırmak

Rapor yükünün en temiz çözümü raporları canlı işlem veritabanından ayırmaktır.

1. Ayrı okuma kopyası: Canlı veritabanının bir kopyası okuma için tutulur, raporlar oradan çalışır; işlem gören veritabanı etkilenmez. Kopyanın birkaç saniye geride olabileceği kabul edilir, bu raporlama için çoğu zaman sorun değildir.
2. Gece hesaplanan özet tablolar: Satış, stok hareketi ve cari özetleri gece bir kez hesaplanıp hazır tablolara yazılır; rapor ağır birleştirmeleri her seferinde yeniden yapmaz. Dün ve öncesini kapsayan raporlar için en ekonomik yoldur.

Seçim raporun ne kadar güncel olması gerektiğine bağlıdır. "Anlık olmalı" ihtiyacı çoğu rapor için sorgulanmadan kabul edilmiş bir varsayımdır.

Kalıcı çözüm: ölçüm ve uyarı düzeni

Tek seferlik müdahale aynı sorunun geri dönmesini engellemez. Kalıcı çözüm, sistemin kendi durumunu sürekli ölçmesi ve eşik aşıldığında haber vermesidir.

• Yavaş sorgu kaydı: Belirlenen süreyi aşan sorgular kaydedilir ve düzenli gözden geçirilir; en pahalı birkaç sorgu toplam yükün büyük kısmını oluşturur.
• İşlem süreleri: Kritik ekran ve raporların süresi izlenir; eğilim tek bir ölçümden daha bilgilendiricidir.
• Hata kaydı: Uygulama hataları merkezî toplanır; yavaşlık çoğu zaman artan zaman aşımı hatalarıyla gelir.
• Kuyruk uzunluğu: Kuyruğun uzunluğu ve en eski bekleyen mesajın yaşı izlenir.
• Kaynak ve kapasite: İşlemci, bellek, disk doluluğu ve bağlantı sayısı için eşikli uyarı kurulur.
• Tablo büyümesi: En büyük tabloların satır sayısı dönemsel kaydedilir; büyüme hızı arşiv ihtiyacını gösterir.

Kısa kontrol listesi

• Yavaşlık tek ekrana, tek saate ya da tek kullanıcıya indirildi mi?
• Süre ölçülüp kayda geçirildi mi; müdahaleden sonra tekrarlandı mı?
• Sürenin sorguda, uygulamada, ağda yoksa tarayıcıda geçtiği ayırt edildi mi?
• Yavaş sorguların planına bakılıp tam tablo taraması aranıyor mu?
• Bir ekran açılışında kaç sorgu çalıştığı sayıldı mı?
• Raporlar canlı işlem veritabanından ayrıldı mı?
• Büyüyen hareket ve kayıt izi tabloları için arşiv politikası var mı?
• Önbelleğe alınan her veri için geçersiz kılma kuralı yazılı mı?
• Kaynak kullanımı yüksek değilken donanım büyütme kararı sorgulandı mı?

KAV Yazılım, işletmelerin kullandığı yazılımlarda bu teşhis sırasını izler: önce ölçüm, sonra darboğazın düzeltilmesi, ardından tekrarı önleyecek izleme düzeninin kurulması.