Partition fragmentiert, woher und wie abstellen?

[Eye-Q]

Moin,

ein Kunde hat sich beklagt dass die Antwortzeiten seiner Anwendung, die auf eine SQL-Datenbank zugreift, zu wünschen lassen, deswegen habe ich mal ein wenig nach den Ursachen geforscht.

Erstmal die Umgebung: MS SBS 2003 (ohne R2) SP2 auf FSC Primergy TX150 (P4 2,8 GHz, 2 GB RAM, 2x73 GB SCSI im Hardware-RAID 1, daran hängt ein Terminalserver, der ist allerdings, sobald es um etwas anderes als diese eine Anwendung geht, schnell genug (Windows Server 2003 R2 SP2, Dual Dualcore Xeon 3 GHz, 2 GB RAM, für 7 Benutzer vollkommen ausreichend, in Office läuft auch alles wunderbar). Der letzte Neustart der Server war am Montag Abend, am Dienstag haben wir dann nachgefragt und die Antwortzeiten haben sich nicht geändert.

Nun habe ich mal nach der Fragmentierung der Partitionen geschaut und mir ist folgendes aufgefallen, am besten mit Bildern zu erklären:

So sieht die Dateistruktur der Partition aus, auch die versteckten und Systemdateien werden angezeigt:

So sieht der Bericht der Überprüfung der Defragmentierung aus:

Wo kommen diese angeblichen 555 MB mit 132.000 Fragmenten her? Könnte das vielleicht ein defekter Eintrag in der MFT sein? Hat jemand noch eine andere Idee? Wie bekomme ich diese Fragmente von der Partition, so dass die mal ordentlich defragmentiert werden kann?

[dicka]

Ähm, die 555MB ist die Gesamtgröße der Fragmentierten Dateien. 203MB is die Größe der Dateien unter C:\ ohne Unterordner. Scheint alles korrekt zu sein.

Warum machst du nicht ein "optimize table xxx;" unter SQL? Sollte doch mehr bringen als zu defragmentieren oder?

[Eye-Q]

Danke für die Antwort, aber das ist ziemlich sicher nicht die Gesamtgröße der fragmentierten Dateien. Wenn ich die Überprüfung der Fragmentierung auf der zweiten Partition anschmeiße gibt mir der Bericht keinen Wert nur mit "\" aus.

Das mit dem optimize table werde ich mal schauen, mit SQL kenne ich mich nicht so gut aus, aber da wird sich sicher was finden.

[dicka]

Wieso sollte es nicht die Gesamtgröße sein? Aus den Screenshots kann man das jedenalls nicht schlussfolgern.

Dir ist schon klar was Fragmente sind oder?

Angenommen du hast 3 Dateien die je 3 Cluster belegen xxx, yyy und zzz.

Die werden auf einer leeren Partrition erst mal korrekt hintereinander geschrieben:

xxxyyyzzz

Löscht du z.B. die zweite Datei bleibt ein Zuwischenraum:

xxx___zzz

Wird jetzt z.B. eine neue Datei geschrieben, nnnnnn, die 6 Cluster belegt, wird erst der Zwischenraum aufgefüllt, das beschleunigt die Schreibprozesse, sorgt für optimale Speicherausnutzung und sieht dann so aus:

xxxnnnzzznnn

D.h. die Datei nnnnnn wurde in zwei Fragmente zerlegt. Das kann dann soweit gehen, dass auch mal eine Datei in 979 Stückchen zerlegt ist, wie du auf deinem Screenshot siehst.

Beim defragmentieren wird das ganze nun wieder zusammen geschrieben: xxxzzznnnnnn

Wenn für die zweite Partrition nichts angezeigt wird, ist sie also entweder leer oder die Dateien sind einfach nicht fragmentiert.

PS: Das Windows eigene Tool defrag.exe korrigiert nicht alles in einem Durchlauf. Bei einer stark fragmentierten Platte können schon mal 10-15 Durchläufe notwendig sein.

Bearbeitet 26. Juni 2008 von dicka

[Eye-Q]

Ja, mir ist durchaus klar was Fragmentierung bedeutet.

Auf der zweiten Partition gibt es bei der Überprüfung natürlich auch fragmentierte Dateien, allerdings sind dort bei allen Einträgen die entsprechenden Dateinamen verzeichnet, es gibt keinen Eintrag "xxx MB in Ort \".

Die Datei mit 979 Fragmenten ist ja nicht mein Problem, das wird ja mit der (ggf. mehrfachen) Defragmentierung gelöst, der Eintrag mit 132.000 bleibt aber selbst nach inzwischen dreimaligem Defragmentieren genau der selbe...

[dicka]

Hmm, ach jetzt verstehe ich was du meinst. Ich dachte bisher der oberste Eintrag sei eine Zusammenfassung aller darunter liegender Dateien aber dem ist wohl doch nicht so...

Naja hast du mal "chkdsk" drüber laufen lassen?

[Sch3MmY]

wie schnell sind denn die Platten in dem System?

Wir haben kürzlich eine SQL-DB auf einen anderen Plattenstapel in unserem Storagesystem umgezogen. Sind also von 14*10k Platten auf 14*15k Platten gegangen. Brachte effektiv etwa 25% mehr performance.

Ich denke dass es grade bei zwei "kleinen" Platten nicht so kostspielig ist um das nicht mal versuchen zu können.

Wie groß ist die Datenbank?

[Eye-Q]

Du kennst unsere Kunden schlecht, die knausern wo sie können...

Als DB-Server ist ein Primergy TX150 im Einsatz, RAID 1 aus zwei 73-GB-SCSI-Platten mit 10k U/min, die Datenbank ist 600 MB groß, da greifen sechs Leute drauf zu, also da mit einem RAID 10 oder so zu kommen ist erstens Overkill und zweitens sagt der Kunde "Ihr spinnt wohl, ich zahl doch keine x Euro blablabla", so sind unsere Kunden einfach, wir haben schon gekämpft da einen Terminalserver hinzustellen um den Verwaltungsaufwand zu verringern...

[Sch3MmY]

Mh, dann biete dem Kunden an, das System testweise auf 15k Platten zu stellen und wenns ihm gefällt muss er sich entscheiden, ob er sparen oder performant arbeiten will.

Ob allerdings bei 600 MB schon spürbar was bei rum kommt, weiß ich leider nicht.

Wie sieht die Systemauslastung aus? CPU, RAM, HDD-I/Os etc.?