“Netsis’in açılması dakikalar sürüyor”, “rapor bir türlü gelmiyor”, “fatura kaydederken herkes bekliyor” şikâyetleri çoğu zaman tek bir nedene değil, birden fazla katmanın bileşkesine işaret eder. Rastgele ayar değiştirmek yerine katmanları belirli bir sırayla test etmek, hem sorunu daha hızlı bulur hem de gereksiz donanım harcamasını önler. Bu rehber, 10 yılı aşkın sahada edindiğimiz sıralamayı adım adım anlatır.
Adım 1: Belirtiyi Doğru Katmana Yerleştirin
Herhangi bir müdahaleden önce üç soruya yanıt verin:
| Soru | Yanıt A | Yanıt B |
|---|---|---|
| Kim yavaş? | Tüm kullanıcılar → sunucu/veritabanı | Tek kullanıcı → o bilgisayar veya ağ ucu |
| Ne yavaş? | Her işlem → genel kaynak sorunu | Belirli rapor/ekran → sorgu ve indeks |
| Ne zaman yavaş? | Gün boyu → kalıcı darboğaz | Belirli saatler → yoğunluk, toplu işlem, yedek saati |
Bu tabloyu doldurmadan yapılan her müdahale tahminden ibarettir. Örneğin tek kullanıcının yavaşlığında sunucuya RAM eklemek hiçbir şey değiştirmez.
Adım 2: Sunucu ve Donanım Kontrolü
Tüm kullanıcılar etkileniyorsa önce sunucuya bakın:
- Disk türü: Veritabanı dosyaları SSD/NVMe üzerinde mi? Mekanik diskte çalışan veritabanı, en sık gördüğümüz yapısal darboğazdır
- Bellek: SQL Server’a ayrılan bellek ile işletim sistemi ve diğer uygulamaların ihtiyacı dengeli mi? Sunucuda sürekli %90 üzeri bellek kullanımı varsa yetersizlik işaretidir
- Sanallaştırma: Sanal sunucuda kaynaklar başka makinelerle paylaşılıyorsa, yoğun saatlerdeki yavaşlığın kaynağı komşu yükler olabilir
- Aynı sunucuda başka yükler: Dosya sunucusu, kamera kayıt yazılımı gibi ek roller veritabanı sunucusundan ayrılmalıdır
Asgari yapılandırma değerleri için donanım gereksinimleri dokümanına bakın.
Adım 3: Veritabanı Tarafı
Donanım yeterli görünüyorsa sıra veritabanı sağlığındadır:
- İndeks ve istatistik bakımı: Uzun süre bakım yapılmamış veritabanında sorgular giderek yavaşlar. Düzenli rutin için SQL Server bakım planı rehberimizi uygulayın
- Veritabanı boyutu: Yıllar içinde büyüyen hareket tabloları rapor sürelerini uzatır; eski dönemleri arşivlemek çoğu zaman donanım yatırımından daha etkilidir
- Timeout belirtileri: Yavaşlık zaman zaman bağlantı kopmasına dönüşüyorsa Timeout Expired hatası yazısındaki kontrolleri de yapın
- Yedek ve bakım saatleri: Tam yedek veya indeks bakımı mesai saatine denk geliyorsa gece saatlerine taşıyın
Adım 4: Ağ ve İstemci Tarafı
Tek kullanıcı veya tek lokasyon yavaşsa buradan ilerleyin:
- Kablolu bağlantı: Yoğun veri taşıyan ERP istemcisi kablosuz ağda tutarsız performans verir; sorun yaşayan kullanıcıyı önce kabloya alın
- Antivirüs istisnaları: Netsis program klasörleri ve SQL Server trafiği gerçek zamanlı taramaya takılıyorsa belirgin yavaşlama olur; kurumsal antivirüs konsolunda istisna tanımlayın
- Uzak lokasyon: Şube veya evden bağlanan kullanıcı istemciyi doğrudan çalıştırıyorsa yavaşlık kaçınılmazdır; doğru mimari için terminal sunucu veya VPN yapısı kurun
- Yazıcı sürücüleri: Döküm ve rapor önizlemede yaşanan takılmalarda varsayılan yazıcının erişilebilir olduğunu kontrol edin
Adım 5: Kullanım Alışkanlıkları
Teknik katmanlar temizse yavaşlığın kaynağı kullanım biçimi olabilir: yıllık tarih aralığıyla alınan hareket raporları, mesai ortasında çalıştırılan toplu işlemler, kapatılmayan oturumların tuttuğu kayıt kilitleri. Bu alışkanlıklar tek tek küçük görünse de toplamda sistemin genel hızını belirler. Kullanıcı başına doğru rapor ve işlem alışkanlığı kazandırmak için yapılandırılmış bir eğitim en kalıcı çözümdür.
Sahada En Sık Gördüğümüz Üç Hata
- Teşhissiz donanım yatırımı: Belirti tek kullanıcıda veya tek rapordayken sunucu yenilemek, en pahalı ve en etkisiz müdahaledir. Yatırım kararı her zaman Adım 1’deki tablonun çıktısına dayanmalıdır
- Rutin shrink alışkanlığı: Disk kazanmak için veritabanını düzenli küçültmek kısa vadede yer açar, orta vadede parçalanmayı artırıp yavaşlığı derinleştirir
- Her şeyi aynı anda değiştirmek: Aynı gün bellek artırıp, indeks bakımı yapıp, antivirüs ayarını değiştirirseniz hangi müdahalenin işe yaradığını asla öğrenemezsiniz. Değişiklikleri tek tek uygulayın, her birinden sonra aynı işlemin süresini ölçün
Kalıcı Çözüm: Düzenli Kontrol Rutini
| Sıklık | Kontrol |
|---|---|
| Günlük | Yedek işinin tamamlandığı, disk doluluk oranı |
| Haftalık | İndeks/istatistik bakım işlerinin sonucu, en yavaş işlemlerin notu |
| Aylık | Veritabanı büyüme eğilimi, kullanıcı şikâyet listesinin gözden geçirilmesi |
| Yıllık | Arşivleme kararı, donanım kapasite planı |
Sıkça Sorulan Sorular
Sunucuyu yenilemek yavaşlığı tek başına çözer mi?
Darboğaz gerçekten donanımdaysa evet; ancak bakımsız veritabanı ve yanlış ağ mimarisi yeni sunucuda da yavaş çalışır. Önce Adım 1’deki teşhisi yapın, yatırımı teşhise göre yönlendirin.
Yavaşlığın Netsis’ten mi SQL Server’dan mı kaynaklandığını nasıl anlarım?
Pratik bir ayrım: aynı rapor sunucu üzerinde hızlı, istemcide yavaşsa sorun ağ/istemci tarafındadır; her yerde yavaşsa veritabanı ve sorgu tarafına bakılır. Kesin teşhis için SQL tarafında sorgu izleme gerekir; bu analizi bayinizden isteyebilirsiniz.
Veritabanını küçültmek (shrink) performansı artırır mı?
Hayır, tersine düzenli shrink indeks parçalanmasını artırır ve önerilmez. Boyut sorununun doğru çözümü arşivlemedir; ayrıntı için arşivleme yazımıza bakın.
Kaç GB veritabanı “büyük” sayılır?
Mutlak bir eşik yoktur; aynı boyut güçlü donanımda sorunsuz, zayıf donanımda yavaş çalışabilir. Karar, boyuta değil belirtiye göre verilmelidir: rapor süreleri uzuyor ve bakım pencereleri yetişmiyorsa arşivleme zamanı gelmiştir.
Wings’e geçmek performans sorununu çözer mi?
Uzak lokasyon kaynaklı yavaşlıklarda mimari fark yarattığı için katkısı olabilir; ancak sunucu ve veritabanı katmanındaki darboğazlar ürün değişikliğiyle kendiliğinden ortadan kalkmaz. Önce teşhis, sonra ürün kararı — sıralama değişmemelidir.
Performans sorununu yerinde analiz ettirmek isterseniz Giza Teknoloji Netsis destek ekibi sunucu, veritabanı ve ağ katmanlarını birlikte inceler. Kullanıcı alışkanlıklarını iyileştirmek için Netsis eğitimi sayfamıza, sorularınız için iletişim sayfamıza göz atın.