5
Win2008R2 Terminal clients mit langsamer Graphik
Hallo liebe Experten,
ich verwalte ein kleines Unternehmensnetzwerk bestehend u.a. aus einem Win2008R2 Server, über den fünf Clients via VPN angeschlossen sind.
Auf diesen (meist Core I3 Haswell mit 4 GB Ram und Win7 Pro 32 Bit) läuft jeweils die selbe Anwendung (ein Kassensystem) via RemoteDesktop- Verbindung.
Der Server ist ein HP Server mit Xeon X3460, 8 GB Ram und einer Samsung 850 Pro SSD.
Einen Überblick über die Infrastruktur findet ihr im Anhang.
Dabei arbeiten nur die Clients auf dem Win- Server, der dann seinerseits auf dem Linux- Server arbeitet. Die Rechner 1-5 arbeiten ausschließlich auf dem Linux- Server.
Als Datenbank- Server (SUSE) werkelt ein Fujitsu PRIMERGY TX100 S3 Server mit Intel® Xeon®-Prozessor E3-1220, 8 GB RAM und 500 GB SATA- HDD.
Nun ist mein Problem, dass der Bildaufbau auf den Clients im angeschlossenen Mandanten sehr langsam ist. Allerdings sehe ich auf dem Win- Server keine/ kaum Last (i.d.R. 0-1%).
Das Programm, ein Kassen- Programm, muß allerdings oft eine komplett andere Maske anzeigen.
Prüfe ich die Geschwindigkeit des VPN per NET-IO kommt es zu folgendem Ergebnis:
Prüfung im LAN:
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 77.15 MByte/s Tx, 96.27 MByte/s Rx.
Packet size 2k bytes: 101.31 MByte/s Tx, 108.67 MByte/s Rx.
Packet size 4k bytes: 110.72 MByte/s Tx, 112.74 MByte/s Rx.
Packet size 8k bytes: 109.77 MByte/s Tx, 112.76 MByte/s Rx.
Packet size 16k bytes: 110.74 MByte/s Tx, 112.31 MByte/s Rx.
Packet size 32k bytes: 111.23 MByte/s Tx, 113.02 MByte/s Rx.
Done.
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
UDP connection established.
Packet size 1k bytes: 100.10 MByte/s (0%) Tx, 84.89 MByte/s (0%) Rx.
Packet size 2k bytes: 104.49 MByte/s (5%) Tx, 17.18 MByte/s (1%) Rx.
Packet size 4k bytes: 107.96 MByte/s (1%) Tx, 25.62 MByte/s (0%) Rx.
Packet size 8k bytes: 60.08 MByte/s (2%) Tx, 37.64 MByte/s (0%) Rx.
Packet size 16k bytes: 78.36 MByte/s (3%) Tx, 57.93 MByte/s (0%) Rx.
Packet size 32k bytes: 80.26 MByte/s (3%) Tx, 68.77 MByte/s (0%) Rx.
Done.
und über das VPN
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 551.05 KByte/s Tx, 483.88 KByte/s Rx.
Packet size 2k bytes: 565.39 KByte/s Tx, 531.09 KByte/s Rx.
Packet size 4k bytes: 569.24 KByte/s Tx, 489.20 KByte/s Rx.
Packet size 8k bytes: 568.59 KByte/s Tx, 533.77 KByte/s Rx.
Packet size 16k bytes: 569.55 KByte/s Tx, 535.42 KByte/s Rx.
Packet size 32k bytes: 575.61 KByte/s Tx, 533.23 KByte/s Rx.
Done.
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
UDP connection established.
Packet size 1k bytes: 552.67 KByte/s (99%) Tx, 476.39 KByte/s (98%) Rx.
Packet size 2k bytes: 36.67 KByte/s (99%) Tx, 365.94 KByte/s (92%) Rx.
Packet size 4k bytes: 14.00 KByte/s (99%) Tx, 327.48 KByte/s (96%) Rx.
Packet size 8k bytes: 10.67 KByte/s (99%) Tx, 63.76 KByte/s (99%) Rx.
Packet size 16k bytes: 13.34 KByte/s (99%) Tx, 56.25 KByte/s (99%) Rx.
Packet size 32k bytes: 10.67 KByte/s (99%) Tx, 15.17 KByte/s (99%) Rx.
Done.
In einem anderen Thread von euch habe ich schon gelesen, man solle die Farbtiefe herunterschrauben und auch die Verbindung beim Client auf "Modem" setzen.
Leider scheint auch das nichts zu bringen (oder ich erhoffe mir zu viel bei dieser alten Server- Hardware).
Wenn aber die Server- Hardware wirklich überfordert wäre, dann müssten doch CPU- Auslastung etc. am Anschlag liegen, oder nicht?
Danke und schönes Wochenende,
EuroPC
ich verwalte ein kleines Unternehmensnetzwerk bestehend u.a. aus einem Win2008R2 Server, über den fünf Clients via VPN angeschlossen sind.
Auf diesen (meist Core I3 Haswell mit 4 GB Ram und Win7 Pro 32 Bit) läuft jeweils die selbe Anwendung (ein Kassensystem) via RemoteDesktop- Verbindung.
Der Server ist ein HP Server mit Xeon X3460, 8 GB Ram und einer Samsung 850 Pro SSD.
Einen Überblick über die Infrastruktur findet ihr im Anhang.
Dabei arbeiten nur die Clients auf dem Win- Server, der dann seinerseits auf dem Linux- Server arbeitet. Die Rechner 1-5 arbeiten ausschließlich auf dem Linux- Server.
Als Datenbank- Server (SUSE) werkelt ein Fujitsu PRIMERGY TX100 S3 Server mit Intel® Xeon®-Prozessor E3-1220, 8 GB RAM und 500 GB SATA- HDD.
Nun ist mein Problem, dass der Bildaufbau auf den Clients im angeschlossenen Mandanten sehr langsam ist. Allerdings sehe ich auf dem Win- Server keine/ kaum Last (i.d.R. 0-1%).
Das Programm, ein Kassen- Programm, muß allerdings oft eine komplett andere Maske anzeigen.
Prüfe ich die Geschwindigkeit des VPN per NET-IO kommt es zu folgendem Ergebnis:
Prüfung im LAN:
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 77.15 MByte/s Tx, 96.27 MByte/s Rx.
Packet size 2k bytes: 101.31 MByte/s Tx, 108.67 MByte/s Rx.
Packet size 4k bytes: 110.72 MByte/s Tx, 112.74 MByte/s Rx.
Packet size 8k bytes: 109.77 MByte/s Tx, 112.76 MByte/s Rx.
Packet size 16k bytes: 110.74 MByte/s Tx, 112.31 MByte/s Rx.
Packet size 32k bytes: 111.23 MByte/s Tx, 113.02 MByte/s Rx.
Done.
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
UDP connection established.
Packet size 1k bytes: 100.10 MByte/s (0%) Tx, 84.89 MByte/s (0%) Rx.
Packet size 2k bytes: 104.49 MByte/s (5%) Tx, 17.18 MByte/s (1%) Rx.
Packet size 4k bytes: 107.96 MByte/s (1%) Tx, 25.62 MByte/s (0%) Rx.
Packet size 8k bytes: 60.08 MByte/s (2%) Tx, 37.64 MByte/s (0%) Rx.
Packet size 16k bytes: 78.36 MByte/s (3%) Tx, 57.93 MByte/s (0%) Rx.
Packet size 32k bytes: 80.26 MByte/s (3%) Tx, 68.77 MByte/s (0%) Rx.
Done.
und über das VPN
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 551.05 KByte/s Tx, 483.88 KByte/s Rx.
Packet size 2k bytes: 565.39 KByte/s Tx, 531.09 KByte/s Rx.
Packet size 4k bytes: 569.24 KByte/s Tx, 489.20 KByte/s Rx.
Packet size 8k bytes: 568.59 KByte/s Tx, 533.77 KByte/s Rx.
Packet size 16k bytes: 569.55 KByte/s Tx, 535.42 KByte/s Rx.
Packet size 32k bytes: 575.61 KByte/s Tx, 533.23 KByte/s Rx.
Done.
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel
UDP connection established.
Packet size 1k bytes: 552.67 KByte/s (99%) Tx, 476.39 KByte/s (98%) Rx.
Packet size 2k bytes: 36.67 KByte/s (99%) Tx, 365.94 KByte/s (92%) Rx.
Packet size 4k bytes: 14.00 KByte/s (99%) Tx, 327.48 KByte/s (96%) Rx.
Packet size 8k bytes: 10.67 KByte/s (99%) Tx, 63.76 KByte/s (99%) Rx.
Packet size 16k bytes: 13.34 KByte/s (99%) Tx, 56.25 KByte/s (99%) Rx.
Packet size 32k bytes: 10.67 KByte/s (99%) Tx, 15.17 KByte/s (99%) Rx.
Done.
In einem anderen Thread von euch habe ich schon gelesen, man solle die Farbtiefe herunterschrauben und auch die Verbindung beim Client auf "Modem" setzen.
Leider scheint auch das nichts zu bringen (oder ich erhoffe mir zu viel bei dieser alten Server- Hardware).
Wenn aber die Server- Hardware wirklich überfordert wäre, dann müssten doch CPU- Auslastung etc. am Anschlag liegen, oder nicht?
Danke und schönes Wochenende,
EuroPC
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 336510
Url: https://administrator.de/contentid/336510
Ausgedruckt am: 22.11.2024 um 13:11 Uhr
5 Kommentare
Neuester Kommentar
Hm, 8 GB RAM auf Server 2008R2 ist a sehr bissel wenig. Ich habe in einem Testsystem 32 drinnen.
Hallo XPFanUwe,
Laut unserem IT- Dienstleister sind sogar 4 GB ausreichend. Ich habe dann 4 GB zusätzlich verbaut.
Der RAM ist idR zu 2-3 GB belegt. Von daher sollten 8 GB locker reichen. Außerdem müssten dann Taskmanager und Performancemonitor doch entsprechend darauf hinweisen, oder?
Laut unserem IT- Dienstleister sind sogar 4 GB ausreichend. Ich habe dann 4 GB zusätzlich verbaut.
Der RAM ist idR zu 2-3 GB belegt. Von daher sollten 8 GB locker reichen. Außerdem müssten dann Taskmanager und Performancemonitor doch entsprechend darauf hinweisen, oder?
Moin,
ich würde hier mal auf den VPN-Tunnel tippen...
Kannst du einsehen, wie ausgelastet die (beiden?) VDSL-Leitung in beiden Richtungen sind?
Also DSL am Hauptstandort: TX und RX
Also DSL am Nebenstandort: TX und RX
Wenn nämlich eine der beiden WAN-Seiten voll ausgelastet ist (weil 3 MAs am Hauptstandort HD-Videos bei Youtube schauen), bringt auch das Tuning am RDP selbst nichts.
Prüfe auch mal, ob die MTU-Size auf beiden Seiten stimmt.
Gerade wenn VPN im Einsatz ist, muss man hier vom klassischen 1492 auf meist 1456 o.Ä. reduzieren; und zwar auf beiden Seiten:
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on- ...
Wer baut den VPN auf?
Die Elmegs? Wenn Ja, sind die Fritzboxen nur als Modem eingerichtet oder als voll-aktive Router?
Ich denke nämlich nicht, dass es zunächst die Clients/ der Server selbst ist.
Wäre es ein Serverproblem, müsste das mit hoher Wahrscheinlichkeit sich auch auf den Clients beim Hauptmandanten auswirken....
Gruß
em-pie
ich würde hier mal auf den VPN-Tunnel tippen...
Kannst du einsehen, wie ausgelastet die (beiden?) VDSL-Leitung in beiden Richtungen sind?
Also DSL am Hauptstandort: TX und RX
Also DSL am Nebenstandort: TX und RX
Wenn nämlich eine der beiden WAN-Seiten voll ausgelastet ist (weil 3 MAs am Hauptstandort HD-Videos bei Youtube schauen), bringt auch das Tuning am RDP selbst nichts.
Prüfe auch mal, ob die MTU-Size auf beiden Seiten stimmt.
Gerade wenn VPN im Einsatz ist, muss man hier vom klassischen 1492 auf meist 1456 o.Ä. reduzieren; und zwar auf beiden Seiten:
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on- ...
Wer baut den VPN auf?
Die Elmegs? Wenn Ja, sind die Fritzboxen nur als Modem eingerichtet oder als voll-aktive Router?
Ich denke nämlich nicht, dass es zunächst die Clients/ der Server selbst ist.
Wäre es ein Serverproblem, müsste das mit hoher Wahrscheinlichkeit sich auch auf den Clients beim Hauptmandanten auswirken....
Gruß
em-pie
Hi em-pie,
das VPN wird von den Elmegs aufgebaut. Diese hängen als Exposed host hinter der Fritze. Zudem stellen sie den DynDNS- Zugang bereit (über selfhost).
Das mit der mtu prüfe ich mal. Die müsste dann in den Elmegs geändert werden?
Hier kommt das Ergebnis ping via VPN:
Hauptmandant --> angeschlossener Mandant
C:\>ping 10.52.51.90 -f -l 1390
Ping wird ausgeführt für 10.52.51.90 mit 1390 Bytes Daten:
Antwort von 10.52.51.90: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.51.90: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.51.90: Bytes=1390 Zeit=43ms TTL=62
Antwort von 10.52.51.90: Bytes=1390 Zeit=44ms TTL=62
Ping-Statistik für 10.52.51.90:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 43ms, Maximum = 44ms, Mittelwert = 43ms
C:\>
und umgekehrt:
C:\>ping 10.52.52.1 -f -l 1390
Ping wird ausgeführt für 10.52.52.1 mit 1390 Bytes Daten:
Antwort von 10.52.52.1: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.52.1: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.52.1: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.52.1: Bytes=1390 Zeit=44ms TTL=62
Ping-Statistik für 10.52.52.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 44ms, Maximum = 44ms, Mittelwert = 44ms
Die Clients im Hauptmandanten sind werden direkt vom Linux- Server bedient. Nur der angeschlossene Mandant läuft via Terminal- Server.
Vorstellbar wäre zwar, dass eigentlich dieser überlastet ist, auch wenn er der neuere Server ist. Ich kann dort aber leider nichts einsehen und müsste indirekt messen.
Danke und schönen Sonntag,
EuroPC
das VPN wird von den Elmegs aufgebaut. Diese hängen als Exposed host hinter der Fritze. Zudem stellen sie den DynDNS- Zugang bereit (über selfhost).
Das mit der mtu prüfe ich mal. Die müsste dann in den Elmegs geändert werden?
Hier kommt das Ergebnis ping via VPN:
Hauptmandant --> angeschlossener Mandant
C:\>ping 10.52.51.90 -f -l 1390
Ping wird ausgeführt für 10.52.51.90 mit 1390 Bytes Daten:
Antwort von 10.52.51.90: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.51.90: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.51.90: Bytes=1390 Zeit=43ms TTL=62
Antwort von 10.52.51.90: Bytes=1390 Zeit=44ms TTL=62
Ping-Statistik für 10.52.51.90:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 43ms, Maximum = 44ms, Mittelwert = 43ms
C:\>
und umgekehrt:
C:\>ping 10.52.52.1 -f -l 1390
Ping wird ausgeführt für 10.52.52.1 mit 1390 Bytes Daten:
Antwort von 10.52.52.1: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.52.1: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.52.1: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.52.1: Bytes=1390 Zeit=44ms TTL=62
Ping-Statistik für 10.52.52.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 44ms, Maximum = 44ms, Mittelwert = 44ms
Die Clients im Hauptmandanten sind werden direkt vom Linux- Server bedient. Nur der angeschlossene Mandant läuft via Terminal- Server.
Vorstellbar wäre zwar, dass eigentlich dieser überlastet ist, auch wenn er der neuere Server ist. Ich kann dort aber leider nichts einsehen und müsste indirekt messen.
Danke und schönen Sonntag,
EuroPC
Hallo,
leider kann ich auf den Elmeg nicht zugreifen, da mir die Berechtigungen fehlen. Die hat nur unser Dienstleister.
Ich habe mal eine Graphik des Performance Monitors beigelegt. Mit den csv- Dateien kann ich nun gar nichts anfangen, reiche die aber bei Bedarf nach. Die Counter sind die die auch im Terminal Server Sizig guide (http://sp.ts.fujitsu.com/dmsp/Publications/public/Terminal_Server_Sizin ..) empfohlen werden.
Gruß,
EuroPC
leider kann ich auf den Elmeg nicht zugreifen, da mir die Berechtigungen fehlen. Die hat nur unser Dienstleister.
Ich habe mal eine Graphik des Performance Monitors beigelegt. Mit den csv- Dateien kann ich nun gar nichts anfangen, reiche die aber bei Bedarf nach. Die Counter sind die die auch im Terminal Server Sizig guide (http://sp.ts.fujitsu.com/dmsp/Publications/public/Terminal_Server_Sizin ..) empfohlen werden.
Gruß,
EuroPC
