3
GDATA Dienst bremst Server
Moin zusammen!
alle Server (VM´s) in Domäne mit BS 2012R2; GDATA Version 14.0.1.122 mit MSSQL2014Express
Seit einiger Zeit kämpfe ich mit einem Problem. In unserer Firma haben wir einen zentralen GDATA-Server und eine ganze Reihe an
GDATA-SubServern, welche die Clients an den jeweiligen Standorten versorgen. Die SubServer laufen als VM´s auf Hostsystemen
welche sich an den jeweiligen Standorten befinden. Die SubServer dienen nebenbei noch zur lokalen Datenablage. An verschiedenen
Standorten passiert es zu ganz unterschiedlichen Zeiten, daß der Speicherhunger des GDATA Managementdienstes (gdmms) plötzlich alles an
RAM belegt was vorhanden ist. Wenn dies passiert, ist es so gut wie unmöglich sich an dem Server anzumelden. Oft ist es nur noch
über die HyperV Console des Hostsystems möglich den gdmms-Dienst zu beenden. Ist der gdmms-Dienst gekillt, normalisiert sich das
Betriebsverhalten nach kurzer Zeit wieder. Alle unseren bisherigen Versuche das Problem beim Schopfe zu packen liefen ins Leere. Leider
hält sich der GDATA-Support auch sehr bedeckt und rückt nur sehr spärlich mit Informationen raus.
Was haben wir bisher versucht:
Überprüfung der GDATA Logfiles sowie der Ereignisprotokolle von Windows; (LogFiles wurden zu auch zu GDATA eingeschickt)
komplette Deinstallation von GDATA inkl. MSSQL mit Bereinigung (AVCleaner Tool, manuelles Löschen der Verzeichnisse) + Neuinstallation;
Überprüfung der Firewalleinstellungen, (Telnet auf Port 7161 zwischen den SubServern und Zentralserver funktioniert)
Überprüfung DNS und der Netzwerkeinstellungen, Installation SP2 für MSSQL2014, ....
Langsam gehen mir bei der Fehlersuche die Ideen aus.
Vielleicht hat sich jemand von Euch mit dem gleichen Problem herumschlagen müssen. Bin für jede Idee dankbar.
Viele Grüße
festus
alle Server (VM´s) in Domäne mit BS 2012R2; GDATA Version 14.0.1.122 mit MSSQL2014Express
Seit einiger Zeit kämpfe ich mit einem Problem. In unserer Firma haben wir einen zentralen GDATA-Server und eine ganze Reihe an
GDATA-SubServern, welche die Clients an den jeweiligen Standorten versorgen. Die SubServer laufen als VM´s auf Hostsystemen
welche sich an den jeweiligen Standorten befinden. Die SubServer dienen nebenbei noch zur lokalen Datenablage. An verschiedenen
Standorten passiert es zu ganz unterschiedlichen Zeiten, daß der Speicherhunger des GDATA Managementdienstes (gdmms) plötzlich alles an
RAM belegt was vorhanden ist. Wenn dies passiert, ist es so gut wie unmöglich sich an dem Server anzumelden. Oft ist es nur noch
über die HyperV Console des Hostsystems möglich den gdmms-Dienst zu beenden. Ist der gdmms-Dienst gekillt, normalisiert sich das
Betriebsverhalten nach kurzer Zeit wieder. Alle unseren bisherigen Versuche das Problem beim Schopfe zu packen liefen ins Leere. Leider
hält sich der GDATA-Support auch sehr bedeckt und rückt nur sehr spärlich mit Informationen raus.
Was haben wir bisher versucht:
Überprüfung der GDATA Logfiles sowie der Ereignisprotokolle von Windows; (LogFiles wurden zu auch zu GDATA eingeschickt)
komplette Deinstallation von GDATA inkl. MSSQL mit Bereinigung (AVCleaner Tool, manuelles Löschen der Verzeichnisse) + Neuinstallation;
Überprüfung der Firewalleinstellungen, (Telnet auf Port 7161 zwischen den SubServern und Zentralserver funktioniert)
Überprüfung DNS und der Netzwerkeinstellungen, Installation SP2 für MSSQL2014, ....
Langsam gehen mir bei der Fehlersuche die Ideen aus.
Vielleicht hat sich jemand von Euch mit dem gleichen Problem herumschlagen müssen. Bin für jede Idee dankbar.
Viele Grüße
festus
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: 334835
Url: https://administrator.de/contentid/334835
Ausgedruckt am: 25.11.2024 um 14:11 Uhr
3 Kommentare
Neuester Kommentar
Hallo,
Wohin werden denn die Logfiles geschrieben?
Gruß
Dobby
Langsam gehen mir bei der Fehlersuche die Ideen aus.
Wie viel CPU Kerne und vor allen anderen Dingen wie viel RAM sind denn den VMs zugeteilt?Wohin werden denn die Logfiles geschrieben?
Gruß
Dobby
Moin Dobby,
den VM´s sind zwei virtuelle Prozessoren und 512 bis 4096 MB RAM dynamisch zugewiesen.
Die RAM Zuweisung mag etwas eng bemessen sein, wir haben aber auch VM´s dabei denen 16 GB
zugewiesen wurden und hier zickt der gdmms-Dienst ebenfalls. Andererseits gibt es andere VM´s
mit max. 4096 MB auf denen der G DATA Subserver von Beginn an sauber läuft. Trotz intensiver
Suche sind uns noch keine nennenswqerten Unterschiede zwischen den VM´s aufgefallen.
Die Logfiles werden unter c:\ProgramData\G DATA\Antivirus ManagementServer\Log abgelegt.
Dort finden sich die Gdmms.log, die GdmmsError.log und die SetupSVC.log.
Grüße
festus
den VM´s sind zwei virtuelle Prozessoren und 512 bis 4096 MB RAM dynamisch zugewiesen.
Die RAM Zuweisung mag etwas eng bemessen sein, wir haben aber auch VM´s dabei denen 16 GB
zugewiesen wurden und hier zickt der gdmms-Dienst ebenfalls. Andererseits gibt es andere VM´s
mit max. 4096 MB auf denen der G DATA Subserver von Beginn an sauber läuft. Trotz intensiver
Suche sind uns noch keine nennenswqerten Unterschiede zwischen den VM´s aufgefallen.
Die Logfiles werden unter c:\ProgramData\G DATA\Antivirus ManagementServer\Log abgelegt.
Dort finden sich die Gdmms.log, die GdmmsError.log und die SetupSVC.log.
Grüße
festus
Dort finden sich die Gdmms.log, die GdmmsError.log und die SetupSVC.log.
Und dort ist nichts zu sehen von Fehlern? Ich dachte das eventuell auch der Logfile und somit die VM (HDD Platz) vollläuft, und dann eben alles in den RAM der schnell vollläuft geschrieben wird. Kann das eventuell sein?
Gruß
Dobby
