Muhasebe veya ERP programı uzak masaüstünde yavaşladığında ilk tepki çoğu zaman “sunucuya daha fazla RAM ekleyelim” olur. Oysa gecikmenin kaynağı disk kuyruğu, tek çekirdeğe yüklenen işlem, kullanıcı profilinin büyümesi, yazıcı yönlendirmesi, antivirüs taraması, veritabanı beklemesi veya ofis bağlantısı olabilir. Sağlıklı bir muhasebe programı sunucusu RDP performans analizi, tahmin yerine aynı zaman aralığındaki ölçümleri karşılaştırır.

Önce “yavaş” ifadesini ölçülebilir hale getirin

Kullanıcıdan yalnızca “sistem yavaş” bilgisini almak teşhis için yeterli değildir. Sorunun giriş sırasında mı, program açılırken mi, rapor alınırken mi, kayıt kaydederken mi yoksa yazdırırken mi oluştuğunu belirleyin. Başlangıç ve bitiş saatini, etkilenen kullanıcı sayısını, kullanılan şubeyi ve işlemin normalde ne kadar sürdüğünü kaydedin.

• Problem tek kullanıcıda mı, tüm aktif oturumlarda mı?
• RDP ekranı mı takılıyor, uygulama mı yanıt vermiyor?
• Aynı işlem sunucu konsolunda da yavaş mı?
• Belirli saat, rapor veya veri setiyle tekrar ediyor mu?
• Son güncelleme, yedekleme veya güvenlik taramasıyla aynı zamana mı denk geliyor?

CPU: toplam oran tek başına yeterli değildir

Toplam CPU kullanımı düşük görünürken muhasebe uygulamasının tek iş parçacığı bir çekirdeği tamamen kullanabilir. Bu durumda ortalama yüzde, darboğazı gizler. İşlem bazında CPU tüketimini, çekirdek dağılımını ve problem anındaki sürekliliği inceleyin. Kısa bir anlık sıçrama ile dakikalarca süren doygunluk aynı değildir.

Çok sayıda RDP oturumu olduğunda arka planda açık kalan raporlar, tarayıcılar ve yardımcı uygulamalar da CPU zamanı tüketir. Kullanıcı başına çalışan süreçleri ayırın. Daha fazla vCPU eklemeden önce uygulamanın paralel çalışıp çalışmadığını ve darboğazın veritabanı ya da disk beklemesi olmadığını doğrulayın.

RAM: kullanım oranından çok bellek baskısını okuyun

Yüksek RAM kullanımı her zaman sorun değildir; işletim sistemi boş belleği önbellek için değerlendirebilir. Asıl sinyal, sürekli paging, çalışan setlerin küçülmesi ve uygulamaların diskten veri beklemesidir. Kullanıcı oturumu sayısı arttıkça her profil, uygulama ve yardımcı süreç ayrı bellek tüketir. Sabah açılan fakat gün boyu kullanılmayan bağlantılar kapasiteyi sessizce azaltabilir.

• Aktif, bağlantısı kesilmiş ve uzun süredir boşta olan oturumları ayırın.
• Commit kullanımı ile fiziksel belleği birlikte değerlendirin.
• Paging eğilimini problem zamanıyla eşleştirin.
• Tek bir process’in zaman içinde büyüyüp büyümediğini izleyin.
• Planlı oturum kapatma politikasını iş akışına zarar vermeden tanımlayın.

Disk gecikmesi: ERP deneyiminin görünmeyen darboğazı

Program açılışı, rapor, veri tabanı ve kullanıcı profili aynı storage katmanında yoğunlaşabilir. Disk doluluk oranı düşük olsa bile gecikme ve kuyruk artabilir. Okuma/yazma latency, IOPS, throughput ve queue length değerlerini birlikte inceleyin. Tek başına “SSD kullanılıyor” bilgisi, problem anındaki performansı kanıtlamaz.

Yedekleme, indeks bakımı, antivirüs taraması ve güncelleme işi mesai içi yoğun saate denk geliyorsa uygulama şikâyeti periyodik olur. Görev zaman çizelgesini performans grafiğinin üzerine koyun. İşleri rastgele kapatmak yerine çalışma saatini, kaynak limitini ve çakışmayı düzenleyin. Yedekleme performans için iptal edilmemeli; uygun pencereye taşınmalı ve sonuç yine doğrulanmalıdır.

RDP bağlantısı ile sunucu performansını ayırın

Ekran yenilemesi, klavye gecikmesi veya kopma yaşanırken uygulama sunucuda normal çalışabilir. Kullanıcının bağlantı gecikmesi, paket kaybı, Wi-Fi kalitesi ve VPN rotası ayrıca ölçülmelidir. Aynı anda sunucuya yakın bir test noktasından karşılaştırma yapmak, ağ ile uygulama sorununu ayırmaya yardımcı olur.

Yazıcı, disk, clipboard ve ses yönlendirmeleri oturum davranışını etkileyebilir. Özellikle büyük yazdırma işleri veya sorunlu sürücüler login ve uygulama tepkisini bozabilir. Güvenlik gereksinimleri korunarak yalnızca gerekli yönlendirmeleri etkin tutun. Sorunu çözmek için RDP’yi doğrudan internete açmak doğru bir performans yöntemi değildir; erişim güvenliği ayrı bir zorunluluktur.

Kullanıcı profili ve oturum hijyeni

Büyümüş kullanıcı profilleri, geçici dosyalar, tarayıcı cache’i ve masaüstünde tutulan büyük içerikler giriş/çıkış süresini uzatabilir. Profil boyutunu, yükleme süresini ve hata kayıtlarını kullanıcı bazında izleyin. Profili silip yeniden oluşturmak hızlı görünse de kullanıcı ayarları ve dosyaları için veri kaybı riski yaratır; yedek ve onay olmadan uygulanmamalıdır.

Bağlantısı kesilmiş oturumlar çalışmaya devam edebilir. Bu oturumlarda açık kalan rapor, Excel aktarımı veya tarayıcı sekmeleri kaynak tüketir. Boşta kalma ve bağlantısı kesilmiş oturum politikası, muhasebe ekibinin gerçek çalışma düzeniyle birlikte belirlenmelidir. Devam eden kritik işlemi zaman aşımıyla sonlandırmak veri bütünlüğü riski doğurabilir.

Veritabanı ve uygulama katmanını unutmayın

RDP oturumu hızlı olsa bile ERP uygulaması veritabanı lock, yavaş sorgu, büyümüş tablo veya bakım eksikliği nedeniyle bekleyebilir. Uygulamanın desteklediği teşhis araçlarıyla sorgu süresi ve lock zinciri incelenmelidir. Veritabanına doğrudan ve plansız müdahale etmek yerine yazılım üreticisinin veya yetkili bayinin destek sınırları korunmalıdır.

Uygulama, işletim sistemi ve veritabanı sürüm uyumluluğunu kaydedin. Son güncellemeden sonra başlayan sorunlarda değişiklik zamanı güçlü bir ipucudur; ancak korelasyon tek başına neden değildir. Eski yapılandırmanın yedeği, test ortamı ve geri dönüş adımı olmadan production üzerinde deneme yapılmamalıdır.

Ölçüm süresince saat senkronizasyonunu da kontrol edin. Kullanıcı bildirimi, Windows olay kaydı, uygulama logu ve altyapı grafiği farklı zaman gösteriyorsa aynı olayı yanlış eşleştirebilirsiniz. Sunucu ve izleme sistemlerinin saat dilimi ile NTP durumunu kaydedin. Ayrıca performans verisini müşteri veya çalışan bilgileriyle gereksiz yere birleştirmeyin; teşhis için gereken en az veriyle çalışın ve erişimi yetkili kişilerle sınırlayın.

Ölçüm için 24 saatlik kısa çalışma planı

1. Kullanıcılardan üç somut yavaşlık örneği ve zaman damgası toplayın.
2. Aynı dönem için CPU process dağılımı, bellek baskısı, disk latency ve oturum sayısını kaydedin.
3. Yedekleme, tarama, rapor ve bakım görevlerini zaman çizelgesine ekleyin.
4. Sunucu içinden ve uzak ofisten aynı işlemi karşılaştırın.
5. En güçlü darboğaz hipotezi için tek bir kontrollü değişiklik yapın.
6. Değişiklik öncesi ve sonrası aynı işlemi aynı veri setiyle ölçün.

Kapasite artırmadan önce kontrol listesi

• Yavaşlığın adımı, zamanı ve etkilenen kullanıcıları belli.
• Toplam CPU yerine process ve çekirdek davranışı incelendi.
• RAM oranı yanında paging ve commit baskısı ölçüldü.
• Disk latency, kuyruk ve görev çakışmaları karşılaştırıldı.
• RDP ağ kalitesi ile uygulama süresi birbirinden ayrıldı.
• Aktif ve bağlantısı kesilmiş oturumlar sınıflandırıldı.
• Veritabanı lock ve sorgu beklemeleri yetkili ekipçe kontrol edildi.
• Yapılan değişikliğin geri dönüş adımı hazır.

Doğru kapasite kararı, kullanıcı sayısını tek başına bir paket tablosuna çevirmekten değil; uygulamanın gerçek CPU, RAM, disk ve bağlantı profilini ölçmekten çıkar. Narweb’in Muhasebe Programı Sunucusu yaklaşımını ve iş yüküne göre VDS teklif seçeneklerini inceleyebilirsiniz.