Uzak masaüstü sunucu yavaş: Logo ve Mikro'da RDP gecikmesi, SQL, bellek ve disk darboğazını adım adım bulma

Logo ya da Mikro'yu bir uzak masaüstü sunucu üzerinden kullanıyorsanız "program çok yavaş" şikâyeti büyük olasılıkla dört yerden birinden geliyor: ağ ve RDP bağlantısı, oturumların tükettiği bellek ve CPU, SQL Server ayarları ya da disk. Sorun şu ki bu dört katman kullanıcıya aynı görünür: ekran donar, fiş geç açılır. Bu rehber muhasebe ekibini dinleyen sistem yöneticisi ya da KOBİ sahibi için hazırlandı. Amaç, tahmin yürütmeden, katmanları sırayla ölçüp darboğazı bulmak.

Önce belirti: yavaşlık herkeste mi, tek kullanıcıda mı?

Kontrollere başlamadan önce iki dakikanızı alacak üç soruyu yanıtlayın. Yanıtlar, hangi katmandan başlayacağınızı büyük ölçüde belirler.

1. Kimde yavaş? Yalnız bir ya da iki kullanıcıdaysa önce o kullanıcıların internet bağlantısına ve RDP istemci ayarlarına bakın. Ofisteki ve evdeki herkeste aynı anda yavaşsa sorun sunucu tarafındadır.
2. Ne yavaş? Fare imleci ve pencere sürükleme bile takılıyorsa ağ ya da RDP katmanını düşünün. Ekran akıcı ama rapor, fiş listesi ya da mizan geç geliyorsa sorun büyük olasılıkla SQL ya da disktir.
3. Ne zaman yavaş? Sabah herkes aynı anda bağlandığında, ay sonu kapanışında ya da gece yedeği uzayıp mesai saatine taştığında yavaşlıyorsa kaynak yetersizliğine ya da çakışan işlere bakın.

Bu üç yanıtı bir kenara not edin. Aşağıdaki sıra, en ucuz ve en hızlı kontrolden en pahalısına doğru ilerler.

Kontrol 1: ağ ve RDP bağlantı ayarları

Gecikmeyi ölçün

Yavaş olan kullanıcının bilgisayarından sunucuya ping atın. Aşağıdaki komut Windows 10/11 ve PowerShell 5.1 için hazırlandı; yalnız okuma yapar, geri alınacak bir değişiklik içermez. 192.0.2.10 yerine kendi sunucu adresinizi yazın.

# Sunucuya 50 ICMP paketi gönderir, ortalama ve en yüksek gecikmeyi özetler
# ORNEK: 192.0.2.10 yerine kendi sunucu IP adresinizi yazın
$sonuc = Test-Connection -ComputerName 192.0.2.10 -Count 50 -ErrorAction SilentlyContinue
$sonuc | Measure-Object -Property ResponseTime -Average -Maximum |
    Select-Object @{n='OrtalamaMs';e={[math]::Round($_.Average,1)}}, @{n='EnYuksekMs';e={$_.Maximum}}
"Kayip paket: " + (50 - $sonuc.Count)

Ortalama düşük ama en yüksek değer sık sık sıçrıyorsa ya da paket kaybı varsa sorun kullanıcının hattında, Wi-Fi'da ya da arada bir VPN'dedir. Sunucuda bir şeyi değiştirmeden önce aynı testi kablolu bağlantıdan tekrarlayın. Sunucu güvenlik duvarı ICMP'ye kapalıysa bu test sonuç vermez; o durumda yalnız RDP istemcisindeki bağlantı bilgisini kullanın.

UDP kullanılıyor mu?

RDP, TCP'nin yanında UDP taşımasını da kullanabilir ve kayıplı ya da gecikmeli hatlarda UDP ekranı belirgin şekilde daha akıcı tutar. Bağlantı açıkken RDP penceresinin üst çubuğundaki sinyal simgesine tıklayın. "UDP etkin" ya da benzeri bir ifade görüyorsanız sorun yok. Yalnız TCP görünüyorsa şu üç noktayı kontrol edin:

• Sunucuda grup ilkesi: Bilgisayar Yapılandırması > Yönetim Şablonları > Windows Bileşenleri > Uzak Masaüstü Hizmetleri > Uzak Masaüstü Oturum Ana Bilgisayarı > Bağlantılar altındaki "RDP aktarım protokollerini seç" ilkesi yalnız TCP'ye ayarlanmış olabilir.
• Arada bir güvenlik duvarı ya da modem UDP 3389'u engelliyor olabilir.
• Kullanıcı bir SSL VPN ya da TCP tabanlı tünel üzerinden bağlanıyorsa UDP zaten taşınmaz.

Uyarı: Güvenlik duvarında RDP kurallarıyla oynarken mevcut TCP 3389 (ya da kullandığınız özel port) iznini kaldırmayın. Kuralı yanlış yazarsanız sunucuya erişimi kaybedersiniz. Değişiklikten önce sağlayıcınızın web konsoluna ya da VNC konsoluna erişebildiğinizi doğrulayın; kendinizi kilitlerseniz geri dönüş yolu yalnız odur.

Renk derinliği ve deneyim seçenekleri

Logo ve Mikro ekranları grafik açısından ağır değildir, ama masaüstü arka planı, pencere animasyonları ve 32 bit renk her oturumda bant genişliği harcar. Uzak Masaüstü Bağlantısı (mstsc) içinde "Deneyim" sekmesinde bağlantı hızını "Bağlantı kalitesini otomatik algıla" olarak bırakın; yavaş hatlardaki kullanıcılar için masaüstü arka planını ve yazı tipi yumuşatma dışındaki görsel efektleri kapatın. Çok sayıda kullanıcıyı tek tek uğraşmadan ayarlamak için sunucu tarafında "En yüksek renk derinliğini sınırla" ilkesini kullanabilirsiniz. Yazıcı ve sürücü yönlendirmesi de bağlantı açılışını uzatır; kullanılmayan yerel sürücü eşlemesini kapatmak oturum açılış süresini kısaltır.

Karar ölçütü: Bu ayarlardan sonra yavaşlık yalnız belirli kullanıcılarda kaldıysa sorun büyük olasılıkla onların hattıdır. Herkeste devam ediyorsa sunucuya geçin.

Kontrol 2: oturum başına bellek ve CPU

Uzak masaüstü sunucusunda her kullanıcı kendi Logo ya da Mikro sürecini, kendi tarayıcısını ve kendi Excel'ini çalıştırır. On kişi açık bıraktığı tarayıcı sekmeleriyle SQL Server'ın belleğini sıkıştırabilir.

Görev Yöneticisi ve Kaynak İzleyicisi

Görev Yöneticisi'nde "Kullanıcılar" sekmesi her oturumun toplam CPU ve bellek kullanımını gösterir. Kaynak İzleyicisi'nde (resmon) "Bellek" sekmesindeki "Sabit hata/sn" sütunu sürekli yüksekse sistem diske sayfalama yapıyordur, bu da RAM yetmiyor demektir. "Kullanılabilir" bellek mesai saatinde sürekli toplamın küçük bir kısmına düşüyorsa bellek darboğazı vardır.

Oturum bazında bellek listesi

Aşağıdaki betik Windows Server 2019, 2022 ve 2025 ile PowerShell 5.1 için hazırlandı. Yalnız okur, sistemde değişiklik yapmaz; geri alınacak bir şey yoktur. Yönetici olarak çalıştırın.

# Her RDP oturumundaki süreçlerin toplam bellek kullanımını MB olarak listeler
# ve en çok bellek kullanan 3 süreci gösterir. Değişiklik yapmaz.
Get-Process -IncludeUserName -ErrorAction SilentlyContinue |
    Where-Object { $_.SessionId -ne 0 } |
    Group-Object SessionId |
    ForEach-Object {
        $kullanici = ($_.Group | Where-Object UserName | Select-Object -First 1).UserName
        [PSCustomObject]@{
            Oturum    = $_.Name
            Kullanici = $kullanici
            BellekMB  = [math]::Round(($_.Group | Measure-Object WorkingSet64 -Sum).Sum / 1MB)
            EnBuyuk   = ($_.Group | Sort-Object WorkingSet64 -Descending |
                         Select-Object -First 3 -ExpandProperty ProcessName) -join ', '
        }
    } | Sort-Object BellekMB -Descending | Format-Table -AutoSize

Çıktıda bir oturum diğerlerinden çok yüksek çıkıyorsa nedeni çoğu zaman tarayıcıdır, Logo ya da Mikro değil. Boşta ve kopuk kalan oturumlar da belleği tutmaya devam eder; bunların nasıl listelenip güvenle kapatılacağını RDP oturum yönetimi rehberinde bulabilirsiniz.

CPU tarafında sqlservr.exe mesai boyunca yüksekse sorun sorgu ve indeks tarafındadır, Kontrol 3'e geçin. CPU'yu kullanıcı süreçleri yiyorsa ve toplam kullanım uzun süre üst sınırdaysa çekirdek sayısı yetmiyordur. Tek anlık görüntüyle karar vermeyin; birkaç gün boyunca ölçüm almak için Windows sunucu kaynak ölçüm betiğini kullanabilirsiniz.

Kontrol 3: SQL Server bellek sınırı, LGCONFIG ve DNS

Max server memory ayarlı mı?

SQL Server varsayılan olarak bulabildiği tüm belleği alır ve kolay kolay geri vermez. Ayrı bir veritabanı sunucusunda bu doğru davranıştır. Ama aynı makinede uzak masaüstü oturumları da çalışıyorsa SQL Server ile kullanıcı oturumları belleği paylaşmak zorunda kalır ve sunucu sayfalamaya başlar. Önce mevcut durumu okuyun. Aşağıdaki T-SQL, SQL Server 2016 ve sonrası için hazırlandı; yalnız okur.

-- Mevcut bellek sınırını ve SQL Server'ın şu an kullandığı belleği gösterir
SELECT name, value_in_use
FROM sys.configurations
WHERE name IN ('max server memory (MB)', 'min server memory (MB)');

SELECT physical_memory_in_use_kb / 1024 AS sql_kullanilan_mb,
       memory_utilization_percentage
FROM sys.dm_os_process_memory;

SELECT total_physical_memory_kb / 1024 AS toplam_ram_mb,
       available_physical_memory_kb / 1024 AS bos_ram_mb,
       system_memory_state_desc
FROM sys.dm_os_sys_memory;

max server memory (MB) değeri 2147483647 görünüyorsa sınır hiç konmamıştır. system_memory_state_desc sütununda düşük bellek ifadesi görüyorsanız işletim sistemi baskı altındadır.

Sınırı belirlerken şu mantığı izleyin: toplam RAM'den işletim sistemi için bir pay ve eşzamanlı kullanıcı başına oturum belleğini (Kontrol 2'deki ölçümünüzden) düşün, kalanı SQL Server'a verin. Ayarlama komutu aşağıda; 12288 yalnız örnektir, kendi hesabınızdaki değeri yazın. Geri almak için ilk sorguda okuduğunuz eski değeri aynı komutla tekrar girin. Ayar anında etkinleşir, hizmetin yeniden başlatılması gerekmez.

-- ORNEK_DEGER_MB: kendi hesapladığınız değer (örnekte 12288 MB)
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max server memory (MB)', 12288;
RECONFIGURE;

SQL Express kullanıyorsanız sürümün kendi bellek tavanı vardır; o tavanın üstüne çıkmanın yolu ayar değil sürüm değişikliğidir. Ayrıntı için Microsoft'un sunucu belleği yapılandırma belgesine bakın.

LGCONFIG'te sunucu adı mı, IP mi?

Logo ürünlerinde veritabanı bağlantısı LGCONFIG ile tanımlanır; Mikro'da da benzer şekilde bağlantı ayarlarında SQL sunucusunun adı ya da adresi yazılır. Program ve SQL aynı uzak masaüstü sunucusundaysa ad çözümlemesi sorunsuz olmalıdır. Ama SQL ayrı bir makinedeyse ya da sunucu adı DNS'te yanlış ya da eski bir adrese çözülüyorsa, program her açılışta önce yanlış adresi dener, zaman aşımını bekler, sonra doğruya gider. Bu durum "program açılırken uzun süre bekliyor, açıldıktan sonra normal" belirtisini verir.

Kontrol için uzak masaüstü sunucusunda şu komutu çalıştırın. Windows Server 2019, 2022 ve 2025 ile PowerShell 5.1 için hazırlandı, yalnız okur:

# SQL sunucu adının hangi adrese çözüldüğünü ve 1433 portuna erişimi kontrol eder
# ORNEK_SQL_SUNUCU yerine LGCONFIG'te ya da Mikro ayarında yazan adı girin
Resolve-DnsName ORNEK_SQL_SUNUCU
Test-NetConnection -ComputerName ORNEK_SQL_SUNUCU -Port 1433

Resolve-DnsName beklemeden doğru adresi döndürmeli, Test-NetConnection çıktısında TcpTestSucceeded : True görünmelidir. Ad çözümlemesi gecikiyorsa ya da birden fazla adres dönüyorsa DNS kaydını düzeltin ya da bağlantı ayarında sabit IP ve port kullanın. Adlandırılmış örnek (ör. SUNUCU\LOGO) kullanılıyorsa SQL Browser hizmetine bağımlılık oluşur; sabit port tanımlamak bu adımı da ortadan kaldırır. Ayarı değiştirmeden önce mevcut bağlantı tanımını ekran görüntüsüyle kaydedin ki geri dönebilesiniz.

Bakım yapılıyor mu?

Bellek ve bağlantı yerindeyse ama raporlar yine yavaşsa sıra indeks parçalanmasına ve güncel olmayan istatistiklere gelir. Bu iş tek seferlik bir ayar değil düzenli bakım ister: indeks yeniden düzenleme ya da yeniden oluşturma, istatistik güncelleme ve bunların mesai dışına zamanlanması. Bakım işinin kimde olduğunu (sizde mi, sağlayıcıda mı, yazılım bayisinde mi) yazılı olarak netleştirin.

Kontrol 4: disk gecikmesi, NVMe ve antivirüs dışlamaları

Disk gecikmesini ölçün

Aşağıdaki betik Windows Server 2019, 2022 ve 2025 ile PowerShell 5.1 için hazırlandı. Bir dakika boyunca 5 saniyede bir disk gecikmesi ve kuyruk uzunluğu örnekler; değişiklik yapmaz. Ölçümü yavaşlık şikâyetinin geldiği saatte alın.

# Disk okuma/yazma gecikmesini milisaniye olarak ve kuyruk uzunluğunu örnekler
$sayaclar = '\PhysicalDisk(*)\Avg. Disk sec/Read',
            '\PhysicalDisk(*)\Avg. Disk sec/Write',
            '\PhysicalDisk(*)\Current Disk Queue Length'
Get-Counter -Counter $sayaclar -SampleInterval 5 -MaxSamples 12 |
    ForEach-Object { $_.CounterSamples } |
    Where-Object { $_.InstanceName -ne '_total' } |
    Group-Object Path |
    ForEach-Object {
        $ort = ($_.Group | Measure-Object CookedValue -Average).Average
        if ($_.Name -like '*sec/*') { $ort = $ort * 1000 }   # saniyeyi ms'ye çevir
        [PSCustomObject]@{ Sayac = $_.Name; Ortalama = [math]::Round($ort, 2) }
    } | Format-Table -AutoSize

SSD ve NVMe disklerde okuma ve yazma gecikmesi normalde birkaç milisaniyenin altında kalır. Veritabanı ve log dosyalarının bulunduğu diskte gecikme düzenli olarak onlarca milisaniyeye çıkıyor ve kuyruk uzunluğu sürekli yüksek kalıyorsa disk darboğazı vardır. Bulut sunucuda bu, paylaşılan depolama ya da IOPS sınırı anlamına gelebilir; sağlayıcınıza diskin türünü ve sınırını sorun.

Antivirüs dışlamaları

Antivirüs her .mdf ve .ldf erişimini taramaya kalkarsa SQL Server'ın her yazması beklemeye girer. Microsoft, SQL Server veri ve log dosyaları ile sqlservr.exe süreci için dışlama tanımlamayı önerir. Aşağıdaki betik Windows Server 2019, 2022 ve 2025 üzerinde Microsoft Defender için hazırlandı. Yolları kendi kurulumunuza göre değiştirin; geniş klasörler (tüm C: sürücüsü gibi) dışlamayın. Geri alma komutları betiğin sonunda yorum olarak verildi.

# Defender'a yalnız SQL veri/log klasörü ve sqlservr.exe için dışlama ekler.
# Tekrar çalıştırmak zararsızdır; aynı dışlama zaten varsa yeniden eklenmez.
# ORNEK_VERI_YOLU ve ORNEK_LOG_YOLU değerlerini kendi yollarınızla değiştirin.
$veriYolu = 'D:\SQLData'      # ORNEK_VERI_YOLU
$logYolu  = 'E:\SQLLog'       # ORNEK_LOG_YOLU
$surec    = 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Binn\sqlservr.exe'

$mevcut = Get-MpPreference
foreach ($yol in @($veriYolu, $logYolu)) {
    if ($mevcut.ExclusionPath -notcontains $yol) { Add-MpPreference -ExclusionPath $yol }
}
if ($mevcut.ExclusionProcess -notcontains $surec) { Add-MpPreference -ExclusionProcess $surec }

# Doğrulama
(Get-MpPreference).ExclusionPath
(Get-MpPreference).ExclusionProcess

# Geri almak için:
# Remove-MpPreference -ExclusionPath $veriYolu, $logYolu
# Remove-MpPreference -ExclusionProcess $surec

sqlservr.exe yolu SQL Server sürümüne ve örnek adına göre değişir; Hizmetler konsolunda SQL Server hizmetinin özelliklerinden doğru yolu alın. Üçüncü taraf bir antivirüs kullanıyorsanız aynı dışlamaları onun yönetim konsolundan tanımlayın. Dışlama, o klasörlerin fidye yazılımına karşı korumasını zayıflatır; bu yüzden ayrı ve değiştirilemez bir yedeğiniz olduğundan emin olun.

Kullanıcı sayısına göre doğru boyut: ne zaman ayrı SQL sunucusu gerekir?

Küçük ekiplerde program, uzak masaüstü oturumları ve SQL Server'ın aynı makinede çalışması hem ucuz hem yönetilebilirdir. Aşağıdaki işaretlerden ikisi ya da daha fazlası mesai saatinde düzenli görülüyorsa SQL Server'ı ayrı bir sunucuya almayı değerlendirin:

• max server memory doğru ayarlı olduğu halde ya SQL'e ya da oturumlara bellek yetmiyor.
• Kullanıcı oturumlarının CPU'su ile sqlservr.exe CPU'su aynı anda yükseliyor ve birbirini bekliyor.
• Ay sonu raporları ya da toplu işlemler sırasında diğer kullanıcıların ekranı da donuyor.
• Kullanıcı sayısı artmaya devam ediyor ve tek sunucuyu büyütmek lisans ya da maliyet açısından mantıksızlaşıyor.

Ayrı SQL sunucusunun artıları: bellek ve CPU çakışması biter, veritabanı tarafını bağımsız büyütürsünüz, uzak masaüstü sunucusunu yeniden başlatmak veritabanını etkilemez.

Eksileri: ikinci bir Windows ve SQL lisansı, iki makine arası ağ gecikmesi (iki sunucu aynı veri merkezinde ve aynı özel ağda olmalı), yönetilecek iki sistem. Ağ gecikmesi yüksekse ayırmak durumu iyileştirmek yerine kötüleştirebilir. Veritabanını ayrı tutmayı düşünüyorsanız NVMe diskli bir SQL Server veritabanı sunucusu seçeneklerden biri olabilir; kararı yukarıdaki ölçümlerle verin.

Sık yapılan hatalar

• Önce RAM eklemek. Sorun DNS zaman aşımı ya da antivirüs taramasıysa RAM eklemek hiçbir şey değiştirmez, yalnız faturayı büyütür.
• Tek anlık ölçümle karar vermek. Görev Yöneticisi'ne bir kez bakıp "CPU boşta" demek yanıltıcıdır; ölçümü şikâyet anında ve birkaç gün boyunca alın.
• max server memory'yi çok düşük ayarlamak. SQL Server'ı aşırı kısmak, oturumları rahatlatırken her sorguyu diske yönlendirir. Ayardan sonra bos_ram_mb ve disk gecikmesini tekrar ölçün.
• Geniş antivirüs dışlaması. Tüm sürücüyü ya da tüm program klasörünü dışlamak güvenlik açığıdır. Yalnız veri, log ve süreç.
• Güvenlik duvarında konsol erişimi olmadan değişiklik yapmak. Yanlış bir kural sizi sunucunun dışında bırakır.
• Gece yedeğini mesaiye taşırmak. Yedek ya da bakım işi sabah dokuza sarkıyorsa ilk saatlerdeki yavaşlığın nedeni odur; zamanlamayı ve süreyi kontrol edin.

Yönetilen iş yazılımı sunucusuna ne zaman geçmeli?

Yukarıdaki dört kontrolü düzenli yapacak ve sonuçları yorumlayacak biri içeride yoksa, ya da her ay sonu aynı yavaşlık tekrar ediyorsa, sorunu yönetilen bir altyapıya devretmek mantıklı hale gelir. Karar verirken şunları tartın: içerideki teknik zaman maliyeti, kesinti olduğunda muhasebe ekibinin bekleme maliyeti ve mevcut donanımın yaşı. Yönetilen hizmetin eksi tarafı, aylık bir gider olması ve bazı ayarlarda sağlayıcıyla birlikte çalışmanızın gerekmesidir. Sözleşmede SQL bakımının, yedeğin ve RDP oturum yönetiminin kimde olduğunu açıkça yazdırın.

Sık sorulan sorular

Logo sadece açılışta yavaş, sonra normal çalışıyor. Neden?

Bu belirti çoğunlukla bağlantı aşamasındaki beklemeye işaret eder: SQL sunucu adının yavaş ya da yanlış çözülmesi, adlandırılmış örnekte SQL Browser beklemesi ya da oturum açılışındaki yazıcı ve sürücü yönlendirmesi. Resolve-DnsName ve Test-NetConnection ile bağlantıyı kontrol edin, gerekirse LGCONFIG'te sabit IP ve port kullanın.

Uzak masaüstü sunucu için max server memory değerini kaç vermeliyim?

Sabit bir sayı yok. Toplam RAM'den işletim sistemi payını ve ölçtüğünüz eşzamanlı oturum belleğini düşün, kalanı SQL Server'a verin. Ayardan sonra boş bellek ve disk gecikmesini tekrar ölçerek değeri ince ayarlayın.

UDP'yi açınca RDP gerçekten hızlanır mı?

Kayıplı ya da gecikmesi değişken hatlarda ekran akıcılığı genellikle belirgin şekilde iyileşir. Hat zaten temiz ve gecikmesi düşükse fark sınırlı kalır. Yavaşlığın kaynağı SQL ya da diskse UDP hiçbir şey değiştirmez.

Antivirüsü tamamen kapatmak sorunu çözer mi?

Kapatmak denemek için bir ipucu verebilir, ama kalıcı çözüm değildir ve sunucuyu korumasız bırakır. Doğru yol yalnız SQL veri, log klasörleri ve sqlservr.exe için dar dışlama tanımlamaktır.

Ayrı SQL sunucusuna geçmek her zaman daha hızlı mı?

Hayır. Bellek ve CPU çakışması varsa evet, ama iki sunucu arasındaki ağ gecikmesi yüksekse Logo ve Mikro'nun çok sayıda küçük sorgusu yavaşlar. İki makine aynı veri merkezinde ve özel ağda olmalıdır.

Bu işi hazır yapmak isterseniz

Ölçüm, SQL ayarı, oturum yönetimi ve yedek işlerini kendiniz yürütmek yerine hazır bir yapı istiyorsanız uzak masaüstü çözümü sayfasında Logo ve Mikro gibi programların bulut sunucuda nasıl çalıştırıldığını ve hangi işlerin size kaldığını inceleyebilirsiniz.

Sonuç

Yavaş bir uzak masaüstü sunucuda doğru sıra şudur: önce kimde ve ne zaman yavaş olduğunu belirleyin, sonra ağ ve RDP, oturum belleği ve CPU, SQL Server ayarları ve son olarak disk. Her adımda ölçün, tek bir değişiklik yapın, tekrar ölçün. Bu disiplinle çoğu zaman yeni donanım almadan darboğazı bulursunuz. Bulamazsanız da elinizde, büyütme ya da SQL'i ayırma kararını gerekçelendiren somut veriler olur.