Ich habe ein seltsames Problem, das offenbar vor Kurzem aufgetreten ist.
Wenn ich eine große Datei (ca. 6 GB) von meinem Laptop auf einen unserer älteren Dateiserver kopiere, geht dem Server nach einigen Sekunden der Arbeitsspeicher aus.
Dies hat erst vor Kurzem begonnen, möglicherweise seit Patch Tuesday, aber ich kann es nicht genau sagen.
Bei diesem Server handelt es sich um eine Windows 2000 SP4-Maschine, einen Dell 2950 mit 1 GB RAM (Hinweis: Ich bin sicher, dass dieser Server mehr als 1 GB hatte! Ich kann das erst am Ende des Tages physisch überprüfen, wenn ich ihn herunterfahren kann), 3 GHz Xeon-Prozessor, 4 x 250 GB 7,5k RPM SATA-Laufwerke in RAID 10 und eine 1 Gigabit-Netzwerkkarte, die an einen 1 GB-Port eines von Intel verwalteten Switches angeschlossen ist.
(Anscheinend kann ich keine Bilder posten, also muss ein Link genügen)
Diagramm zur Speichernutzung + Informationen während des Kopierens
Sobald ich den Kopiervorgang stoppe, wird der Speicher sofort freigegeben:
Diagramm zur Speichernutzung + Informationen direkt nach dem Stoppen des Kopiervorgangs
Ich habe das Antivirenprogramm entfernt, was jedoch keine Auswirkungen hatte. Ich habe die Optionen „Datei- und Druckerfreigabe für Microsoft-Netzwerke“ auf „Ausgewogen“ geändert.
Wir haben einen weiteren Server, Windows 2000 SP4 mit 2 GB RAM, 2,8 GHz Intel Quad Core, 6 x 300 GB 15k SAS in Raid 10.
Wenn ich die gleiche 6 GB große Datei hierher kopiere, ändert sich die Menge des verfügbaren Speichers nicht.
Gibt es sonst noch etwas, das ich mir ansehen kann, während der Server läuft? Da er in Gebrauch ist und von kleinen Dateikopien nicht wirklich betroffen ist, kann ich ihn noch nicht neu starten.
Hier ist ein Screenshot einiger Leistungsmonitor-Zähler, die ich geöffnet hatte, als dem Server der Arbeitsspeicher ausging.
Perfmon-Zähler während des Kopierens
Danke
, Gareth
Antwort1
Ich stehe vor dem gleichen Problem.
Versuch, eine P2V-Konvertierung auf einem 64-Bit-Server mit Windows Server 2008 durchzuführen. Alle normalen Dateiübertragungsmethoden für die VMDK-Datei (44 GB groß) führen dazu, dass Windows auf dem Zielserver aufgrund des Dateisystem-Cachings nach einigen Minuten seinen 14 GB großen RAM ausgeht.
Beim Ausführen der P2V-Konvertierung oder des Dateikopierens auf einem 32-Bit-Server tritt dieses Problem nicht auf und die Speichernutzung bleibt in einem vernünftigen Rahmen.
Beim Versuch, die VMDK-Datei auf den Ziel-VMWare-Server zu kopieren, tritt dasselbe Problem auf.
Diese Seite beschreibt genau, was ich sehe:
http://blogs.technet.com/askperf/archive/2007/05/08/slow-large-file-copy-issues.aspx
Basierend auf meiner Arbeit scheint dieses AM ESEUtil die beste Lösung zu sein. Es war nicht so schnell wie erwartet, aber es hat Windows auch nicht aus der Fassung gebracht.
Der Windows-FTP-Client verwendet eine temporäre Datei auf C:\, bevor er die Datei zum Zielort verschiebt. Vorsicht! :-)
Das istsehrfrustrierend.
Antwort2
Ich weiß, das ist ein bisschen nervig, aber haben Sie schon mal ein Dienstprogramm zum Kopieren von Dateien von Drittanbietern ausprobiert? Windows ist beim Kopieren von Dateien manchmal etwas dumm/langsam. Lifehacker hat eine Top-5-Liste dieser Dienstprogramme erstellt. Probieren Sie eines davon aus und prüfen Sie, ob Sie immer noch das gleiche Problem haben.
http://lifehacker.com/5280976/five-best-alternative-file-copiers
Überprüfen Sie außerdem, wie bereits erwähnt, Ihre virtuellen Speichereinstellungen. Die beste Vorgehensweise ist, dass Ihre Auslagerungsdatei das 1,5-fache Ihres Speichers beträgt (d. h. 1 GB Speicher = 1024 MB; 1024*1,5 = 1536 MB Auslagerungsdatei).
Antwort3
Es gibt bekannte Probleme mit den Netzwerkdateikopierprozessen auf W2K - wenn das Remote-System den Schreibcache nicht schneller leeren kann, als die Dateidaten über das Netzwerk eintreffen, wird es, wenn die Datei groß genug ist, den gesamten physischen Speicher auf dem Server verbrauchen. Mark Russinovich hat einige Details dazu, wie dies passieren kann.In diesem Artikelzu Änderungen an den Dateikopiermechanismen von Windows Vista. Das von Ihnen gepostete Leistungsdiagramm sieht nach diesem Problem aus, und ich habe genau dieses Verhalten in der Vergangenheit gesehen, als ich ein Zielsystem mit sehr langsamen Festplatten und einem schnellen Netzwerk hatte.
Obwohl Ihr Zielbetriebssystem etwas älter ist, ist die Hardware nicht allzu schwach und ein RAID 10-Setup mit 4x7,2K SATA-Laufwerken sollte für Schreibgeschwindigkeiten zwischen 60 und 120 MBit/s ausreichen, was deutlich höher ist als die 39 MBit/s, die Vista für Ihre Kopie angibt. Das Seltsame dabei ist, dass Sie bei einer soliden, gut konfigurierten GigE-Verbindung Netzwerkübertragungsraten von bis zu 70 MBit/s (und vielleicht etwas mehr) für eine dauerhafte Kopie einer so großen Datei erreichen könnten. Allerdings sind 38 MBit/s auch nicht ungewöhnlich, wenn anderer Datenverkehr vom oder in den Client oder Server fließt oder (was wahrscheinlicher ist) diese Rate hauptsächlich durch die Geschwindigkeit der lokalen Festplatte Ihres Laptops begrenzt wird.
Ich würde auf jeden Fall prüfen, ob Ihr RAID 10 tatsächlich fehlerfrei ist. Aufgrund der hier gezeigten Symptome vermute ich, dass die Schreibgeschwindigkeit nicht die ist, die Sie benötigen.
Antwort4
Möglicherweise müssen Sie den virtuellen Speicher Ihrer Systemfestplatte erweitern, da geringer Festplattenspeicher das Problem möglicherweise verursacht hat.
Aus logischer Sicht muss der Server beim Kopieren von einem Dateisystem in ein anderes auch keine Datei im Speicher speichern. Er weist lediglich einen Puffer im Speicher zu, durch den die Datei geht. Je nachdem, wie Sie Dateien kopieren, speichern einige Anwendungen die Datei jedoch zunächst vollständig im Speicher und schreiben sie dann auf die Festplatte.
Versuchen Sie, ein Protokoll wie FTP zu verwenden. Wenn das Problem weiterhin auftritt, sollten Sie sich nach Netzwerkproblemen umsehen.
Die interessante Frage wäre hier, wie der Server die Dateien tatsächlich speichert – wie Sie sehen, ist die E/A-Last einfach sehr gering, was bedeutet, dass die Datei nirgendwo geschrieben, sondern nur im Speicher gepuffert wird.