Jump to content

XP SP2: Zugriff auf große dateien auf großer HDD langsam


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

hallo,

 

und nabend @lle ;)

 

ich habe folgendes problem:

 

einen etwas angetagten rechner betreibe ich als fileserver in meinem netzwerk, wo z.b. meine dbox fernsehsendungen aufzeichnet. das system ist ein xp sp2 mit einer 80gb system und einer 300gb datenplatte. das system hat 384 mb ram und einen 1ghz pIII prozzi. nun das problem macht sich wie folgt bemerkbar:

 

beim zugriff auf große dateien fängt die 300gb platte inmitten des ersten gigabytes der datei an zu rödeln wie ****e und die datenübertragungsrate fällt von durchschnittlich 50 mb/s auf 10 mb/s. die platte ist auf jeden fall sauber defragmentiert.

 

die selben dateien von der kleineren platte gelesen machen da keine probleme. um einen defekt der platte auszuschließen, habe ich die mal in meinem hauptrechner (3ghz und 1.5 gb ram) eingebaut und konnte diesen effekt (mit denselben dateien) dann erst wesentlich später feststellen. nun der einzige unterschied zwischen den systemen ist ja so gesehen das ram und die cpu, weshalb ich das ram dann von 1,5gb auf 256 mb beschränkt habe, und siehe da, das rödeln der platte tritt nun wieder vieeel eher auf.

 

meine vermutung:

durch den dateicache von windows füllt die datei während des kopierens immer mehr das ram auf. der verwaltungsvorgang der 300gb hdd mit vielen dateien (durch ein forum und und und insgesamt 60 000 dateien) ist natürlich (vom dateisystem her) wesentlich aufwändiger. der dateicache schmeißt dann irgendwann (wenns ram voll ist) teile des dateiSYSTEM cahces aus dem ram, weshalb die platte das dateisystem immer neu laden muss

 

vermutl. lösung:

der dateicache muss weiter beschränkt werden, oder der freiraum für den dateiSYSTEM cache muss an die größe des für die große platte

 

kann das jemand bestätigen oder mich auf den richtigen weg weisen?

 

wäre echt nett.

 

einen defekt der platte kann ich absolut ausschließen, da sie beim sequentiellen lesen von a bis z mit 56 -> 30 mb/s liest

und ein zu langsames schreiben schließe ich auch aus, da ich die messungen mit dem PAT (performance assessment tool) von HP durchgeführt habe, welches so gesehen nach NUL liest. (habe die daten nicht einfach von der einen auf die andere platte kopiert)

lg

 

dirk

Link zu diesem Kommentar
  • 3 Wochen später...

Hallo Dirk,

 

also der Dateisystemcache ist ja dafür da, daß der Zugriff SCHNELLER geht. Je kleiner Du den also einstellst, desto mehr wird der Effekt auch bei kleineren Dateien auftreten. Der Rechner ist schnell genug, das geht sogar mit einem PII-Server...

 

Was Du machen solltest: Den RAM-Speicher erhöhen, je mehr, desto besser. Und den virtuellen Speicher auf fest einstellen (minimale und maximale Größe auf den gleichen Wert), damit Windows keine Zeit verschwendet mit dem Anpassen des Auslagerungsspeichers. Wenn die 300GB-Platte die Datenplatte ist, sollte der Auslagerungsspeicher wiederum auf der anderen Platte liegen (wenn es physikalisch getrennte Platten sind, sonst macht es keinen Sinn).

 

Darüber hinaus kannst Du die reichhaltigen Indikatoren von Windows Server dazu verwenden, Leistungsmessungen durchzuführen. Darüber gibt es ganze Bücher...

 

Viele Grüße

 

Christian

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...