Domino fragmentierung

Schon interessant: Dir stinkt Domino, weil du ein Problem mit dem Windows Dateisystem hast.

Nur mal zur Info: Auch SQL Datenbanken fragmentieren, wenn sie auf einem entsprechenden Dateisystem eingesetzt werden. Das ist völlig unabhängig davon was du dort speicherst, denn die Fragmentierung wird durch das darunterliegende Betriebssystem im Zusammenhang mit dem verwendeten Dateisystem verursacht.

IBM kann das gar nicht ändern, weil dazu Windows verändert werden müsste.

So wie es deiner Beschreibung nach klingt setzt ihr lokale Platten mit NTFS ein und NTFS ist nun mal ein Dateisystem, daß konzeptionell mit Fragmentierung zu kämpfen hat.

Wenn du die Fragmentierung verhindern willst, setz ein Dateisystem bzw eine Technik ein, die eben keine Fragmentierung verursacht.
Z.B. richtige SAN Systeme.

Also, wir müssen 2 Arten von Fragmentierung unterscheiden. Zum Einen die Fragmentierung des White Space in den DBs an sich, die lassen sich mit einem compact beheben. Wie ihr es ja auch macht. Das andere Ding ist die Fragmentierung im Filesystem. Das lässt sich nicht verhindern. Außer eventuell mit einem anderen Filesystem (und damit OS), wobei *alle* mehr oder weniger stark fragmentieren. Geht nicht anders. Ist so.

Dass Notes/Domino eben *nicht* alles in ein File klatschen und das dann intern organisieren, ist definitiv die bessere Wahl. Verreckt das eine File, sind alle darin organisierten User betroffen. Die Kollegen aus einer anderen Abteilung administrieren für einen (Gott sei Dank nur einen) Kunden Exchange. Die freuen sich immer tierisch, wenn so ein Container krepiert, ein Dutzend User Incident Tickets schrieben und die Rücksicherung dann den halben Tag dauert.

Die einzige Möglichkeit die ihr habt, ist eben wirklich Quotas einzuführenn. Nur so lässt sich der Platz für die Mail-DBs einigermaßen in Grenzen halten (wobei 1,4TB nicht soooo wahnsinnig viel sind). Was bei eurem Archiv schief gelaufen ist, kann so natürlich niemand beantworten. Eine einfache Möglichkeit ist aber, einen extra Server hinzustellen, auf den dann per bordeigenen Mitteln archiviert wird. Das tut zuverlässig und man setzt nicht viel Geld für nicht funktionierende Nachbauten eines Drittherstellers in den Sand, der meint, schlauer zu sein als IBM.

Du hast dann im Endeffekt 3 Möglichkeiten:
1) wechsel das FS
2) leb mit der Fragmentierung (vernünftige Hardware sollte auch so schnell genug sein)
3) lass den compact weg, leb mit dem Whitespace im NSF, führe einen FS-defrag durch. So wird zuerst immer der Whitespace verbraten, bevor das eigentliche File im FS vergrößert wird.

1) Unixe und deren Derivate mit den dort vorherrschenden FSsen (ich wiederhole: auch da gibt Fragmentierungen, wenn auch nicht so stark wie bei NTFS). Eine firmenpolitische Bindung ist ja gut und schön, technsiche Fakten sind aber nun einfach mal technische Fakten.

2) Wie gesagt: verzichte auf den compact und führe einmalig ein defrag durch. Dann bleiben die einzelnen Files über einen weiten Bereich unangetastet, weil DB-intern erst einmal versucht wird, den Whitespace zu nutzen. Was läuft da eigentlich sonst noch auf den Platten, bzw. von wievielen Files sprechen wir eigentlich? Eine 80%ige Fragmentierung ist garantiert nicht normal für ein Mailverzeichnis...
Eine Alternative wäre, die wenigen großen von den vielen kleinen Files zu trennen auf unterschiedliche Plattenstapel zu packen, um so in gewissen Grenzen die Fragmentierung einzuschränken.

1) ungefähr 680MB/File
2) ungefähr 260MB/File
3) ungefähr 500MB/File
4) ungefähr 1GB/File
5) ungefähr 1GB/File

Also werden 1) und 3) zusammengelegt, 4) und 5) werden ebenfalls zusammengelegt.

Ein compact -c ist natürlich auch die denkbar ungünstigste Variante, die du nur hättest wählen können. Ein "copy-style compaction" macht genau das, was der Name sagt: es kopiert die DB. Ergo: es wird temporär eine 2. Datei angelegt, der Inhalt der ersten reinkopiert, die erste gelöscht, die 2. auf den Namen der ersten umbenannt. Dass das fragt- insbesondere bei der absoluten Anzahl aller Dateien-, dürfte logisch sein, oder? Wesentlich sinniger wäre ein "compact -S x% -b" (wohlgemekrt: ein kleines "b"!). Das komprimiert nur die Files, bei denen x Prozent ungenutzter Platz existiert und reduziert die Filesize *nicht* (um das FS-fragging zu unterbinden).

Hallo zusammen,

wenn ich das hier so lese möchte ich manchmal in die Tischkante beissen - da treffen ja etliches an Halbwissen und "Tipps" aufeinander, da mag ich denn mal auch meine 50 Cents dazugeben.

<B>Domino und Compact:</B>

Auf den Compact zu verzichten ist keine gute Idee, nicht mal ansatzweise. Der tut schließlich einiges mehr als nur die Dateien kleiner zu machen - und sogar das läßt sich per Switch steuern. Aber dazu später.

<B>Windows und Fragmentierung:</B>

Alle Filesysteme unterliegen diesem "Problem", nur sind die Auswirkungen unterschiedlich stark zu merken.

Wo liegt das Performance-Problem hierbei? Nun, eigentlich ganz simpel in der Tatsache, daß der Schreib/Lesekopf der Platte immer erst neu positioniert werden muß, bevor der nächste Block gelesen werden kann. Stehen die Blöcke "hintereinander" fällt diese Verzögerung weg. Womit wir aber schon die nächste Frage hätten - stehen nach dem Defragmentieren die Blöcke wirklich hintereinander?

<B>Anatomie der Datenspeicherung:</B>

Der Schreib/Lesekopf der Platte (ich nenne ihn jetzt mal kurz nur "Kopf") liest einen Block von der Platte und schreibt ihn in einen Puffer. Da die Daten auf der Platte schneller kommen als der Puffer verarbeiten kann muß die Platte jetzt warten, bis der Puffer wieder zur Verfügung steht. Im Idealfall dauert das z.B. genau eine Plattenumdrehung und der Kopf wäre, bei sequentieller Speicherung, genau an der richtigen Stelle für den nächsten Block. Und der Vorgang wiederholt sich.

Dieser "Idealfall" existiert allerdings heutzutage aus folgenden Gründen nicht mehr wirklich:

- Die Blockgröße der Festplatte und des Betriebssystems müssen dafür identisch sein.
- Die Festplatte liegt heutzutage bei Servern in einem RAID, meist 5 oder 6. Ein RAID hat ebenfalls eine Block-Größe (meist als Stripe bezeichnet).
- das RAID beherbergt oft Daten verschiedener Systeme oder Programme. Die Vorstellung, zum Zeitpunkt X fragt nur genau eines dieser Programme die Daten sequentiell ab ist weltfremd.
- Ein SAN beherbergt u.U. mehrere redundante RAID-Systeme und wird von vielen Servern und Applikationen zeitgleich genutzt. Der Hauptvorteil einer Defragmentierung wird dadurch zunichte gemacht, daß die Köpfe sowieso aufgrund der verschiedenen parallelen Anfragen ständig in Bewegung sind.
- Alle RAID-Versionen (außer 0) schreiben die Daten doppelt, von wo sie später gelesen werden kann man nicht direkt beeinflussen, selbst wenn sie an einer Stelle sequentiell stehen würden werden die Kopien auf andere Platten redundant verteilt.

<B>Erkenntnisse aus obigen Bemerkungen:</B>

In einem modernen Serversystem mit RAID und/oder sogar SAN kann man den physikalischen Speicherort nicht beeinflussen. Vielmehr hat man bereits in Planungsphase auf bestimmte Dinge zu achten, die die Performance später maßgeblich beeinflussen:

- Nicht alle Daten gehören ins SAN (Stichwort OS und Translogs)
- RAID 5 und 6 sind nicht für alle Daten sinnvoll (Stichwort Translogs)
- Trenne OS und Daten
- beachte die verwendeten Blockgrößen und stimme sie ab
- kenne deine Applikation und die benötigten Blockgrößen
- kenne dein OS und dessen Vor- und Nachteile
- Nutze Cache-Mechanismen sinnvoll
- vermeide unnötige Vorgänge durch rechtzeitige DB-Wartung (Stichwort Compact und Updall)

usw ...

Um zum Thema Compact zurückzukommen, das ja vom Verfasser des Ur-Postings gemeinsam mit dem Datenbankspeicher sinngemäß als "Quelle allen Übels" bezeichnet wurde:

Wenn du wirklich davon überzeugt, daß die Fragmentierung dein Problem verursacht, wieso läßt du die Datenbanken dann überhaupt verkleinern? Dann lasse sie doch in der Größe unangetastet und benutze statt dessen den Compact-Schalter -b (kleines(!) b) dieser läßt die Größe unangetastet aber führt trotzdem die Wartung durch, indem z.B. der White-Space zusammengefaßt wird und doppelte Unread- und Ordner-Aktionen reduziert werden. In keinem Fall sollte man das komplett abschalten. Wenn man es täglich (nachts) laufen läßt geht das auch ohne große Performance-Verluste durch.

Wenn du vom "schlechten Windows" sprich NTFS überzeugt bist - nimm DB2 als Backend, ich verspreche dir keine Performance-Verbesserung - aber dein Argument der Fragmentierung würde dann nicht mehr ziehen (wenn die Datenbank auf einem anderen System liegt) Aber ich behaupte, es wird keine signifikante Änderung erkennbar werden.

<B>Tipp:</B>

Um euer Performance-Problem auszuloten sollte man sich auf den beteiligten Systemen mal mit ein paar Hilfsmitteln die I/O etwas genauer anschauen. Ein Windows-Defrag mag ja auf einem Laptop oder PC was bringen, ich vermute euer Problem allerdings eher woanders, selbst wenn ein Defrag nach dem Streichholz-Zieh-Prinzip bei euch temporär Besserung bringt so denke ich nicht, daß es die eigentliche Ursache darstellt.

<i>Früher ... da gab es mal Computersysteme mit einer einzigen rotierenden Magnetscheibe.</i>