Sabah 09:00. Mesai başlıyor, herkes aynı anda sisteme giriyor. Ve ERP, her gün olduğu gibi, sürünmeye başlıyor. Bir ekran açılması 8-10 saniye. Rapor çekmek bir kahve molası. Muhasebe arıyor, üretim arıyor, satış arıyor — hepsi aynı cümleyle: "Sistem yine yavaş."
Bu tabloyu tanıyorsanız, yalnız değilsiniz. ERP yavaşlığı, BT yöneticilerinin masasına en sık gelen şikayetlerden biri. Ama ilginç olan şu: en sık yanlış teşhis edilen sorunlardan biri de bu.
Çünkü "ERP yavaş" bir hastalık değil. Bir semptom. Ve aynı semptomun arkasında birbirinden çok farklı nedenler olabilir. Tıpkı baş ağrısının arkasında susuzluktan tansiyona kadar onlarca farklı sebep olabilmesi gibi.
Bu yazıda, yıllardır yaptığımız performans analizlerinde en sık karşılaştığımız 5 gerçek nedeni ve bunları nasıl ayırt edeceğinizi anlatacağız. Amacımız net: bir dahaki sefere "yavaş" şikayeti geldiğinde, tahmin etmek yerine doğru yere bakabilmeniz.
Önce En Pahalı Yanlış: "Donanım Ekleyelim" Refleksi
Çoğu yavaşlık hikayesi şöyle ilerler: sistem yavaşlar, "demek ki kaynak yetmiyor" denir, sunucuya RAM veya CPU eklenir. Birkaç hafta rahatlama olur, sonra sorun geri döner. Çünkü kaynak ekleme, gerçek darboğaz başka yerdeyse yalnızca zaman kazandırır — sorunu çözmez.
Bu yüzden ilk kural şu: ölçmeden ekleme yapma. Yavaşlığın nerede olduğunu bilmeden atılan her donanım adımı, hem bütçeyi hem de güveni eritir. Şimdi gerçek nedenlere bakalım.
Çalışmayan (ya da Hiç Olmayan) SQL Bakım Planı
ERP'lerin büyük kısmı arkada bir SQL veritabanına dayanır. Ve SQL, düzenli bakım isteyen bir motordur: indekslerin yeniden düzenlenmesi, istatistiklerin güncellenmesi, eski kayıtların yönetilmesi.
Sahada en sık gördüğümüz tablo, bu bakım planının ya hiç kurulmamış ya da bir noktada durmuş olması. İndeksler parçalandıkça (fragmentasyon) sorgular giderek yavaşlar. Sistem birinci gün hızlıdır, ikinci yıl sürünür — ve kimse arada ne değiştiğini fark etmez, çünkü değişim yavaş ve sessizdir.
Nasıl ayırt edilir?
Yavaşlık zamanla kademeli arttıysa ve özellikle raporlama/sorgu işlemlerinde belirginse, ilk bakılacak yer burasıdır. Bakım planının en son ne zaman başarıyla çalıştığını kontrol edin.
Disk I/O Darboğazı
Sunucunuzun RAM'i ve CPU'su boşta gözükebilir, ama sistem yine de yavaştır. Bu durumda şüphe çoğu zaman disk performansındadır. Özellikle veritabanı, yoğun okuma/yazma yapan bir yük bindiriyorsa ve disk altyapısı bunu karşılayamıyorsa, her işlem diskte kuyruğa girer.
Burada kritik metrik disk doluluğu değil, disk gecikmesidir (latency) ve kuyruk uzunluğudur. Dolu olmayan bir disk de yavaş olabilir; mesele kapasiteden çok hızdır.
Nasıl ayırt edilir?
CPU ve RAM kullanımı makul, ama uygulama yine de yavaşsa ve disk kuyruk değerleri yüksekse, darboğaz büyük olasılıkla buradadır.
Şişmiş, Hiç Temizlenmemiş Veritabanı
Yıllar içinde veritabanları birikir: loglar, geçici tablolar, silinmemiş eski kayıtlar, arşivlenmesi gerekirken canlı tabloda duran milyonlarca satır. Veritabanı büyüdükçe her sorgu daha fazla veriyi taramak zorunda kalır.
Çoğu şirkette "veri silmek" korkutucu olduğu için hiçbir şey silinmez ve hiçbir şey arşivlenmez. Sonuçta 8 yıllık operasyonel veriyi her gün tarayan bir sistem ortaya çıkar — oysa günlük işlerin %95'i son 12 ayın verisiyle ilgilidir.
Nasıl ayırt edilir?
Veritabanı boyutunun olağandışı büyük olması ve en çok yavaşlayan işlemlerin geçmişe dönük arama/raporlama olması bu nedene işaret eder.
Ağ ve Switch Katmanı
Bazen sorun sunucuda hiç değildir. Kullanıcı ile sunucu arasındaki yolda — switch'lerde, kablolamada, yanlış yapılandırılmış bir ağ segmentinde — saklanır. Özellikle birden fazla lokasyon, VPN bağlantısı veya eski bir switch altyapısı varsa, gecikme buradan gelir.
Klasik belirti: aynı ERP, sunucuya yakın bir kullanıcıda hızlı, uzak şubede sürünüyorsa, şüphe sunucudan çok ağdadır.
Nasıl ayırt edilir?
Yavaşlık kullanıcının/lokasyonun konumuna göre değişiyorsa, ağ ve switch performansını ölçmek gerekir.
Yanlış Boyutlandırılmış veya Yanlış Yapılandırılmış Sunucu
Bazen donanım gerçekten yetersizdir — ama "yetersiz" sandığınız şekilde değil. Örneğin sanallaştırma katmanında kaynaklar yanlış dağıtılmıştır, ERP sunucusu gereğinden fazla başka yükle aynı host'u paylaşır, ya da veritabanı için ayrılan bellek yanlış ayarlanmıştır.
Burada sorun miktar değil, yapılandırmadır. Aynı donanım, doğru yapılandırmayla iki kat hızlı çalışabilir.
Nasıl ayırt edilir?
Diğer dört neden elendiyse ve sistem kuruluşundan beri yavaşsa (zamanla bozulmadıysa), yapılandırma ve boyutlandırmaya bakmak gerekir.
Peki Ne Yapmalı? Tahmin Değil, Ölçüm
Bu beş nedenin ortak noktası şu: hiçbirini tahminle doğru bilemezsiniz. Belirti hepsinde aynı görünür — "sistem yavaş" — ama çözüm her birinde tamamen farklıdır. SQL bakım planı sorununa RAM eklemek, disk darboğazına veritabanı temizliği yapmak, hepsi boşa giden zaman ve bütçedir.
Doğru yaklaşım, bir doktorun yaklaşımıdır: önce ölç, sonra teşhis et, sonra müdahale et. Performans analizinde baktığımız da tam olarak budur — sunucu kaynakları, disk metrikleri, SQL sağlığı, ağ gecikmesi ve yapılandırma; hepsi tek tek, somut sayılarla.
Bir üretim firmasında yaptığımız analizde, aylardır "sunucu yetersiz" denilerek donanım yükseltmesi planlanan bir sistemde, gerçek sorunun durmuş bir SQL bakım planı olduğunu ölçtük. Planlanan donanım yatırımı gereksiz hale geldi; çözüm, yapılması gereken bakımın yeniden devreye alınmasıydı.
Bu makale NovatekCloud Teknik Ekip tarafından hazırlanmıştır. İçerikte yer alan bilgiler, 24+ yıllık saha deneyimine ve gerçek vaka analizlerine dayanmaktadır.