70866
05.12.2008
5792
1
0
Windows 2003 Terminal Server und Citrix - instabile CAD Anwendung und Performance Schwankungen
Ich hab da ein schwerwiegendes Problem mit einer CAD Anwendung in einer Terminalserverumgebung
Ich betreue da eine CAD Anwendung mit dem Namen Comos, die ähnlich wie Autocad gigantische technische Zeichnungen verwalten kann - ist komplett in C++ 6 SP6 und VB6 gebaut worden. Es greift auf einen Fileserver, einen Datenbankserver und einen Lizenzserver zu. Die stehen wiederum in einem zentralen Rechenzentrum.
Die Server sind zwar nicht die Allerneuesten, aber 4 Xeon CPUs mit 2,7 GHz (noch aus der Prescott Zeit) und 4 GB an Ram sollten eigentlich ausreichen. Im Produktivbetrieb sind das gerade mal 30% Auslastung an CPU und Speicher ist acuh genuch da. Das OS ist ein Windows 2003 32 Bit, Citrix 4.5 mit Rollup 2, SQL Server 2005, irgendein Fileserver....
Auf den Terminalservern ist besagte Anwendung installiert, welche ca. 100 OCX Komponenten registriert und knap 90 DLLs mitgeliefert kriegt, die alle bei der Installation mit einem Regsvr32 Aufruf registriert werden.
Dazu gibts noch nen Office 2003 Paket und so die Standarddödelprogramme von Windows wie Paint....
Die Anwendung ist als published app über Citrix verfügbar, kann auch im Remotedesktop bzw. TS Client gestartet werden, und benimmt sich dabei äußerst komisch. Zunächst hatten wir das Netz im Verdacht - mittlerweile haben wir als Servicegüte auch eine Latenzzeit von 50 ms vorgegeben. Manchmal friert eine Session einfach so ein, Mausklicks gehen verloren, die Reaktionszeit schwankt zwischen Sofort und extrem träge.
Gibts da was auf dem Terminalserver was man einstellen muß damit speicherintensive Anwendungen stabiler laufen?
Gibts irgendwas wo man auf nem Terminalserver die CPU Temperatur auslesen kann?
Wir hatten dann einen SErver aus der Farm genommen und mit ins Büro genommen um das Netz als Störfaktor auszuschließen - und alles lokal installiert. Teilweise knallt die CAD Anwendung weg wenn man "Datei / Öffnen" aufruft - und da ist ja keine Magic drin, das sind 3 Mausklicks im Visual Studio mit denen man eine Hello World Anwendung machen kann. Das ist alles klassischer MFC 4.2 Kram.
Gibts für solche Phänomene irgendwelche Diagnosewerkzeuge, oder gibts irgendwelche Einstellungen im Terminalserver die für die Stabilität von Anwendungen beitragen können die aus 200 Einzelkomponenten gebaut sind?
Wir hatten dann ne technische Zeichnung geladen, die 200 MB frißt. Beim 1. Versuch dauert das 5 Minuten, beim zweiten Versuch 2 Minuten, beim dritten Versuch wieder 5 Minuten. Hin und wieder friert auch die Anwendung ohne erfindlichen Grund ein.
Der Support vom Hersteller sagt, daß diese Citrix Probleme bei anderen Kunden nicht auftreten, und wir sollen mal unsere Server genau anschauen. Nur bin ich mit meinem Latein so irgendwie am Ende....
Ich betreue da eine CAD Anwendung mit dem Namen Comos, die ähnlich wie Autocad gigantische technische Zeichnungen verwalten kann - ist komplett in C++ 6 SP6 und VB6 gebaut worden. Es greift auf einen Fileserver, einen Datenbankserver und einen Lizenzserver zu. Die stehen wiederum in einem zentralen Rechenzentrum.
Die Server sind zwar nicht die Allerneuesten, aber 4 Xeon CPUs mit 2,7 GHz (noch aus der Prescott Zeit) und 4 GB an Ram sollten eigentlich ausreichen. Im Produktivbetrieb sind das gerade mal 30% Auslastung an CPU und Speicher ist acuh genuch da. Das OS ist ein Windows 2003 32 Bit, Citrix 4.5 mit Rollup 2, SQL Server 2005, irgendein Fileserver....
Auf den Terminalservern ist besagte Anwendung installiert, welche ca. 100 OCX Komponenten registriert und knap 90 DLLs mitgeliefert kriegt, die alle bei der Installation mit einem Regsvr32 Aufruf registriert werden.
Dazu gibts noch nen Office 2003 Paket und so die Standarddödelprogramme von Windows wie Paint....
Die Anwendung ist als published app über Citrix verfügbar, kann auch im Remotedesktop bzw. TS Client gestartet werden, und benimmt sich dabei äußerst komisch. Zunächst hatten wir das Netz im Verdacht - mittlerweile haben wir als Servicegüte auch eine Latenzzeit von 50 ms vorgegeben. Manchmal friert eine Session einfach so ein, Mausklicks gehen verloren, die Reaktionszeit schwankt zwischen Sofort und extrem träge.
Gibts da was auf dem Terminalserver was man einstellen muß damit speicherintensive Anwendungen stabiler laufen?
Gibts irgendwas wo man auf nem Terminalserver die CPU Temperatur auslesen kann?
Wir hatten dann einen SErver aus der Farm genommen und mit ins Büro genommen um das Netz als Störfaktor auszuschließen - und alles lokal installiert. Teilweise knallt die CAD Anwendung weg wenn man "Datei / Öffnen" aufruft - und da ist ja keine Magic drin, das sind 3 Mausklicks im Visual Studio mit denen man eine Hello World Anwendung machen kann. Das ist alles klassischer MFC 4.2 Kram.
Gibts für solche Phänomene irgendwelche Diagnosewerkzeuge, oder gibts irgendwelche Einstellungen im Terminalserver die für die Stabilität von Anwendungen beitragen können die aus 200 Einzelkomponenten gebaut sind?
Wir hatten dann ne technische Zeichnung geladen, die 200 MB frißt. Beim 1. Versuch dauert das 5 Minuten, beim zweiten Versuch 2 Minuten, beim dritten Versuch wieder 5 Minuten. Hin und wieder friert auch die Anwendung ohne erfindlichen Grund ein.
Der Support vom Hersteller sagt, daß diese Citrix Probleme bei anderen Kunden nicht auftreten, und wir sollen mal unsere Server genau anschauen. Nur bin ich mit meinem Latein so irgendwie am Ende....
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 103381
Url: https://administrator.de/forum/windows-2003-terminal-server-und-citrix-instabile-cad-anwendung-und-performance-schwankungen-103381.html
Ausgedruckt am: 06.05.2025 um 18:05 Uhr
1 Kommentar
ok, vermutlich war es alte Hardware. Die haben doch tatsächlich noch Xeons der allerersten Generation mit 3066 MHz im Einsatz - als die ersten Prescott-CPUs rauskamen und der Sockel 603/604 aktuell war. In einem Server stecken 4 CPUs
in einer VM und einer moderneren CPU kam das in der Form nicht mehr vor. Ebenso mit von Bedeutung war das Hyperthreading - der Xeon für den Sockel 604 war damals noch kein echter Dualcore, sondern hatte nur einen doppelten Registersatz. Läuft auf der einen CPU ein Programm, und startet man eine zweite Instanz - dann sinkt die Performance dramatisch ein. Hat man auf 4 echten CPUs 5 Instanzen einer Software X laufen, dann teilen sich zwei Instanzen einen CPU Kern und genau dann, wenn diese zwei Instanzen Vollast brauchten, dann steht noch knapp 45% der CPU Leistung zur Verfügung.
in einer VM und einer moderneren CPU kam das in der Form nicht mehr vor. Ebenso mit von Bedeutung war das Hyperthreading - der Xeon für den Sockel 604 war damals noch kein echter Dualcore, sondern hatte nur einen doppelten Registersatz. Läuft auf der einen CPU ein Programm, und startet man eine zweite Instanz - dann sinkt die Performance dramatisch ein. Hat man auf 4 echten CPUs 5 Instanzen einer Software X laufen, dann teilen sich zwei Instanzen einen CPU Kern und genau dann, wenn diese zwei Instanzen Vollast brauchten, dann steht noch knapp 45% der CPU Leistung zur Verfügung.
