Seltsame RAM auslastung an 2012 R2 Terminalserver
Hallo zusammen,
ich habe wirklich ein seltsames Problem an einem Terminalserver wo ich durch googlen leider nichts verwertbares gefunden habe.
Das System ist ein HP DL380 G9 mit 32 GB RAM
Aktuell wird dieser von ca. 5 Usern genutzt (Office, Lexware, GDI, DATEV).
Bis vor 3 Wochen lief alles einwandfrei und dann plötzlich konnten sich Leute nicht mehr anmelden, bzw. sind direkt rausgeflogen und/oder Programme stürzen ab.
Das einzige was ich sehen kann ist dass der Arbeitsspeicher bei 95% liegt, aber wenn ich die Zahlen der Prozesse grob Addiert habe komme ich auf ca. 40% Auslastung.
Allerdings habe ich einen grossen "Geändert" Bereich, siehe Bild.
Wenn ich den Server reboote ist für 2-3 Tage ruhe und plötzlich tritt das aus dem nichts auf.
Wie kann ich herausfinden was das ganze verursacht, bzw. wie ich es vermeiden kann?!
Hoffe jemand kann mir helfen.
Viele Grüße
Patrick
ich habe wirklich ein seltsames Problem an einem Terminalserver wo ich durch googlen leider nichts verwertbares gefunden habe.
Das System ist ein HP DL380 G9 mit 32 GB RAM
Aktuell wird dieser von ca. 5 Usern genutzt (Office, Lexware, GDI, DATEV).
Bis vor 3 Wochen lief alles einwandfrei und dann plötzlich konnten sich Leute nicht mehr anmelden, bzw. sind direkt rausgeflogen und/oder Programme stürzen ab.
Das einzige was ich sehen kann ist dass der Arbeitsspeicher bei 95% liegt, aber wenn ich die Zahlen der Prozesse grob Addiert habe komme ich auf ca. 40% Auslastung.
Allerdings habe ich einen grossen "Geändert" Bereich, siehe Bild.
Wenn ich den Server reboote ist für 2-3 Tage ruhe und plötzlich tritt das aus dem nichts auf.
Wie kann ich herausfinden was das ganze verursacht, bzw. wie ich es vermeiden kann?!
Hoffe jemand kann mir helfen.
Viele Grüße
Patrick
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 345852
Url: https://administrator.de/contentid/345852
Ausgedruckt am: 22.11.2024 um 19:11 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
Meinst du das deine 32 GB RAM wirklich ausreichen für deinOffice, Lexware, GDI (was immer das ist), DATEV.
Im zweiten Bild idt klar zu erkennen das du dort 19,4 GByte im Cache hast. Viele Plattenzugriffe?
Gruß,
Peter
Meinst du das deine 32 GB RAM wirklich ausreichen für deinOffice, Lexware, GDI (was immer das ist), DATEV.
Das einzige was ich sehen kann ist dass der Arbeitsspeicher bei 95% liegt, aber wenn ich die Zahlen der Prozesse grob Addiert habe komme ich auf ca. 40% Auslastung.
Eher ne Milchmädchenrechnung. Da wirst du schon zu Processexplorer oder Processmonitor greifen müssen um genaueres zu erfahren.Im zweiten Bild idt klar zu erkennen das du dort 19,4 GByte im Cache hast. Viele Plattenzugriffe?
Gruß,
Peter
Moin,
Grundsätzlich gilt: Freier RAM ist verschwendeter RAM!
Dann: Das RamMap, das du ja schon am laufen hast, sollte ziemlich genau zeigen was welcher Prozess an RAM verbraucht.
Und dann läuft da offensichtlich noch ein SQL Server auf dem TS... der hat da auch nicht unbedingt was zu suchen (und könnte die Menge an verwendeten Cache erklären). Und Teamviewer würd ich mir da auch verkneifen...
Und zum Schluss die üblichen Fragen:
Im Eventlog steht nichts?
Sind OS und Apps auf dem aktuellen Patchstand?
Sind die verwendeten Programme und (Drucker-)Treiber auch für TS "zugelassen" bzw. geeignet?
/EDIT: Aus Erfahrung: Starte den TS einmal pro Woche neu, dann läuft das um einiges sauberer
lg,
Slainte
Grundsätzlich gilt: Freier RAM ist verschwendeter RAM!
Dann: Das RamMap, das du ja schon am laufen hast, sollte ziemlich genau zeigen was welcher Prozess an RAM verbraucht.
Und dann läuft da offensichtlich noch ein SQL Server auf dem TS... der hat da auch nicht unbedingt was zu suchen (und könnte die Menge an verwendeten Cache erklären). Und Teamviewer würd ich mir da auch verkneifen...
Und zum Schluss die üblichen Fragen:
Im Eventlog steht nichts?
Sind OS und Apps auf dem aktuellen Patchstand?
Sind die verwendeten Programme und (Drucker-)Treiber auch für TS "zugelassen" bzw. geeignet?
/EDIT: Aus Erfahrung: Starte den TS einmal pro Woche neu, dann läuft das um einiges sauberer
lg,
Slainte
Zitat von @SlainteMhath:
/EDIT: Aus Erfahrung: Starte den TS einmal pro Woche neu, dann läuft das um einiges sauberer
/EDIT: Aus Erfahrung: Starte den TS einmal pro Woche neu, dann läuft das um einiges sauberer
Inoffiziell sogar alle 2-3 Tage, aber ja, SQL/Datev auf einem TS installieren ist eher zum Scheitern verurteilt, als sinnvoll.
Zitat von @chgorges:
Inoffiziell sogar alle 2-3 Tage, aber ja, SQL/Datev auf einem TS installieren ist eher zum Scheitern verurteilt, als sinnvoll.
Zitat von @SlainteMhath:
/EDIT: Aus Erfahrung: Starte den TS einmal pro Woche neu, dann läuft das um einiges sauberer
/EDIT: Aus Erfahrung: Starte den TS einmal pro Woche neu, dann läuft das um einiges sauberer
Inoffiziell sogar alle 2-3 Tage, aber ja, SQL/Datev auf einem TS installieren ist eher zum Scheitern verurteilt, als sinnvoll.
Und GDI läuft auf einer Firebird Datenbank falls das ganze auch auf dem System Rennt, also DBs ohne ende
Hallo,
Gruß,
Peter
Zitat von @fisi-pjm:
Und GDI läuft auf einer Firebird Datenbank falls das ganze auch auf dem System Rennt, also DBs ohne ende
Ich hätte jetzt auf https://de.wikipedia.org/wiki/Gottlieb_Duttweiler_Institut oder https://de.wikipedia.org/wiki/Geodateninfrastruktur oder https://de.wikipedia.org/wiki/Direkteinspritzung#Anwendung_im_PKW (Mitsubishi Bezeichnung für Direkteinspritzung) oder gar noch an https://de.wikipedia.org/wiki/Graphics_Device_Interface gedacht. Und GDI läuft auf einer Firebird Datenbank falls das ganze auch auf dem System Rennt, also DBs ohne ende
Gruß,
Peter
Zufällig arbeitet der DATEV SQL im Standard mit dynamischem RAM, nimmt also alles bis auf 5% was frei ist in Beschlag. Die SQL.exe ist dabei nur das DBMS, der Rest sind gecachte Daten.
Abhilfe wird dir eine fixe RAM Einstellung im DATEV SQL Manager unter Konfigurieren bei "max server memory" und ein Reboot schaffen. Eine DB gehört trotzdem nicht auf einen TS.
Abhilfe wird dir eine fixe RAM Einstellung im DATEV SQL Manager unter Konfigurieren bei "max server memory" und ein Reboot schaffen. Eine DB gehört trotzdem nicht auf einen TS.
Also im Falle eines DATEV SQL wäre der "geänderte Bereich" nach einem frischen reboot erstmal klein aber durch Nutzung der Software würde er wachsen bis nur noch 5% frei sind (sofern die Default Einstellungen aktiv sind). Das wäre grundsätzlich auf einem DATEV SQL auch kein Problem, der hat sonst nichts zu tun.
Nun ist zwar kein DATEV SQL auf der Maschine wie du sagst, allerdings ist der DATEV SQL natürlich auch von Microsoft, die Dinger arbeiten grundsätzlich recht ähnlich, kann also damit zusammen hängen.
Nun ist zwar kein DATEV SQL auf der Maschine wie du sagst, allerdings ist der DATEV SQL natürlich auch von Microsoft, die Dinger arbeiten grundsätzlich recht ähnlich, kann also damit zusammen hängen.
Zitat von @bGn:
Die Frage wie ich genau herausfinden kann was den "Geändert" Bereich wachsen lässt wurde mir leider nicht beantwortet.
Die Frage wie ich genau herausfinden kann was den "Geändert" Bereich wachsen lässt wurde mir leider nicht beantwortet.
doch wurde gesagt. Mehrfach. Mit RAMMap !