guybrush 19 Geschrieben 6. Mai 2010 Melden Teilen Geschrieben 6. Mai 2010 Hallo, ich habe mir gerade einen Proliant DL380G5 mit 2008R2 installiert. Das system läuft auf 4x146GB 10k SAS im RAID5, 8GB RAM sind installiert. Es soll dort Virtual Center und SCCM drauf laufen, eventuell mal der Kaskersky Adminserver. Jetzt habe ich noch 2x36GB, die ich für das Swapfile verwenden möchte. Jetzt hätte ich prinzipiell gesagt, 36GB gespiegelt reichen aus, vom Speicherplatz und von der Performance. Daniel Petri (MVP f. Windows Server und Exchange) schreibt in seinem Artikel folgendes: If you have a RAID-0 (Stripe Set) array, use it to store the Pagefile. Ohne jetzt die Meinung eines MVPs in Frage stellen zu wollen, aber sollte das Pagefile nicht auch redundant untergebracht sein? Lagert Windows Speicherseiten in das Swapfile aus, und das geht flöten, sind ja de facto auch diese Daten weg, oder sehe ich das falsch? Was meint ihr dazu? LG Johannes Zitieren Link zu diesem Kommentar
Windowsbetatest 10 Geschrieben 6. Mai 2010 Melden Teilen Geschrieben 6. Mai 2010 Lagert Windows Speicherseiten in das Swapfile aus, und das geht flöten, sind ja de facto auch diese Daten weg, oder sehe ich das falsch? Wenn dein Pagefile weg ist, ist kurz danach (oder sofort) das Windows auch weg. Was aber bei einem Cluster nicht so das Problem ist, da es einfach schwenkt. ;) Dennoch kann das Windows danach wieder booten, da es eine neue Swap auf dem Sysdrive anlegt. -> Keine "kritischen" Daten sind weg, sonder "nur" ein normaler Absturz. mfg Zitieren Link zu diesem Kommentar
NilsK 2.971 Geschrieben 6. Mai 2010 Melden Teilen Geschrieben 6. Mai 2010 Moin, wenn das Pagefile nicht auf der Systempartition liegt, kannst du keine Memory-Dumps bei Bluescreens erzeugen. Die können im Support aber sehr hilfreich sein, wenn es mal echt knifflig wird. Daher würde ich das Pagefile eher nicht auslagern. RAID-0 würde ich in keinem produktiven System einsetzen. Schneller Zugriff aufs Pagefile ist zwar gut, aber das Risiko nicht wert. Mehr RAM bringt im Zweifel erheblich mehr. Gruß, Nils Zitieren Link zu diesem Kommentar
guybrush 19 Geschrieben 6. Mai 2010 Autor Melden Teilen Geschrieben 6. Mai 2010 @NilsK: Nicht ganz - es müssen mind. 200MB an Swap auf der Systempartition liegen, dann klappts (korrigiere mich, sollte ich falsch liegen). Dieses Miniswap hab ich angelegt, und dann halt noch eine mit 8GB auf dem RAID1 (derzeit wieder). @WindowsBetaTest: Das kann ich so nicht bestätigen. Da auf dem Server noch rein gar nix läuft, hab ichs mal (mit damals noch 4GB) probiert: Swap auf R0 gelegt, und im Betrieb eine der Platten rausgezogen... nach ein paar Minuten is die Mühle immer noch gelaufen. Kann aber nat. auch daran liegen, dass keine Daten ausgelagert wurden. Also doch auf jeden Fall auf Raid1 - schön, dass ihr meine Vermutung belegt habts ;-) Vielen Dank Johannes Zitieren Link zu diesem Kommentar
Dukel 457 Geschrieben 6. Mai 2010 Melden Teilen Geschrieben 6. Mai 2010 Wieso keine 2 Einzelne Platten und jeweils ein entsprechendes Swap File anlegen. Ich wüsste nicht was das bringt, wenn man den Ausgelagerten RAM per Raid sichert. Zitieren Link zu diesem Kommentar
zahni 562 Geschrieben 6. Mai 2010 Melden Teilen Geschrieben 6. Mai 2010 In gut mit RAM ausgestatteten System wird die Auslagerungs-Datei überhaupt nicht benutzt. Das immer die schlechtere Wahl. Kaufe leiber noch etwas RAM. Das VC braucht für den SQL-Server etwas, aber sonst... -Zahni Zitieren Link zu diesem Kommentar
Lian 2.482 Geschrieben 6. Mai 2010 Melden Teilen Geschrieben 6. Mai 2010 @NilsK:Nicht ganz - es müssen mind. 200MB an Swap auf der Systempartition liegen, dann klappts (korrigiere mich, sollte ich falsch liegen). Dieses Miniswap hab ich angelegt, und dann halt noch eine mit 8GB auf dem RAID1 (derzeit wieder). Der minidump bringt beim Debuggen meist wenig, dazu benötigt man idealerweise einen Kernel Memory Dump oder einen Complete Memory Dump. Je nachdem welche Komponente oder Applikation man debuggen will bzw. muss.Mehr dazu: Ask the Performance Team : Understanding Crash Dump Files Zitieren Link zu diesem Kommentar
TorstenM 20 Geschrieben 7. Mai 2010 Melden Teilen Geschrieben 7. Mai 2010 Das system läuft auf 4x146GB 10k SAS im RAID5, 8GB RAM sind installiert. Es soll dort Virtual Center und SCCM drauf laufen, eventuell mal der Kaskersky Adminserver. Die Plattenkonfiguration könnte zu Performance-Engpässen führen, je nachdem, wie viele Clients mal mit ConfigMgr verwaltet werden sollen. Bzw stößt man meist an I/O-Probleme vom Disksubsystem, bevor sich RAM- oder CPU-Engpässe bemerkbar machen (aus ConfigMgr-Sicht!). Zitieren Link zu diesem Kommentar
NilsK 2.971 Geschrieben 7. Mai 2010 Melden Teilen Geschrieben 7. Mai 2010 Moin, In gut mit RAM ausgestatteten System wird die Auslagerungs-Datei überhaupt nicht benutzt. das stimmt so nicht. Gruß, Nils Zitieren Link zu diesem Kommentar
zahni 562 Geschrieben 7. Mai 2010 Melden Teilen Geschrieben 7. Mai 2010 Hm, vielleicht ändert Windows hier nur nicht den Timestamp ? Zitieren Link zu diesem Kommentar
NilsK 2.971 Geschrieben 7. Mai 2010 Melden Teilen Geschrieben 7. Mai 2010 Moin, der Timestamp scheint hier (Windows 7) der vom letzten Reboot zu sein. Jedenfalls swappt mein Windows ordentlich (darf es ja grundsätzlich auch), und der Timestamp ist vorgestern, halb neun. Auch auf einem gut mit RAM bestückten System lagert Windows Speicherseiten aus, die es gerade nicht benötigt. Dadurch steht schnelles RAM für die Seiten bereit, die aktiv sind. .: Daniel Melanchthon :. : Die grösste Angst des PC-Nutzers... Gruß, Nils Zitieren Link zu diesem Kommentar
jaksa 10 Geschrieben 7. Mai 2010 Melden Teilen Geschrieben 7. Mai 2010 Raid 1 finde ich persönlich das Ungünstigste für das Pagefile. Im schlimmsten Fall erfordert jeder Schreibzugriff zwei!! Plattenzugriffe. Ich würde gar kein RAID für das Swap file machen, ich wüsste jetzt nicht wozu das gut sein soll in einem produktivem System, lasse mich aber gerne eines besseren belehren. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.