Das Festplatten-Subsystem stellt den häufigsten Engpass dar. Der E/A nimmt bei längeren Warteschlangen eine recht lange Zeit in Anspruch, was zu einer höheren Festplattenauslastung und leerlaufenden Prozessurzyklen führt. Mit dem iostat-Werkzeug können Sie während erwarteter Spitzenlasten Angaben zur durchschnittlichen Antwortzeit ermitteln.
Lese-, Schreib- und Aktualisierungsvorgänge auf der Festplatte können sequenziell oder mit zufälligem Zugriffsmuster erfolgen. In eDirectory-Bereitstellungen wird für Lese- und Schreibvorgänge üblicherweise ein zufälliges Zugriffsmuster verwendet.
Einige Lösungen für Arbeitslasten mit zufälligem Muster:
Arbeitsspeicher erhöhen. Dadurch können häufig verwendete Daten bzw. im Voraus gelesene Daten auf der Dateisystemebene im Cache gespeichert werden. Außerdem ermöglicht es ein Caching der DIB im FLAIM-Subsystem.
Dedizierte Volumes für die DIB verwenden. Die Dateisystemleistung steigt bei Volumes, die näher am Spindel erstellt werden. Dedizierte Volumes für das RFL und andere Protokolle verwenden.
Wenn die Datenträger im Laufe der Zeit aufgrund der größeren Fragmentierung längere Latenzzeiten aufweisen, sollte eine Defragmentierung ausgeführt werden.
Getrennte Laufwerke für das FLAIM-RFL hinzufügen. Diese Art der Protokollierung kann auf Hochgeschwindigkeitsfestplatten ausgeführt werden.
RAID 10 (1+0)-Umgebung mit mehreren Laufwerken verwenden.
Die von eDirectory erstellten Dateien können eine Größe bis zu 4 GB erreichen. Dateisysteme, die zur Verarbeitung größerer Dateien optimiert sind, arbeiten mit eDirectory besonders effizient.
Für Solaris™ ist das Veritas* VxFS-Dateisystem ein erweiterungsbasiertes Dateisystem, bei dem die Metadaten des Dateisystems für die Verarbeitung großer Dateien optimiert sind. Das UFS-Dateisystem ist indirekt blockbasiert. Die Metadaten des Dateisystems werden in einer größeren Anzahl Blocks gespeichert. Die Metadaten können für größere Dateien sogar verteilt sein. UFS ist daher für größere Dateien langsamer.
Für Linux™ stellt das Reiser-Dateisystem ein schnelles Journaling-Dateisystem dar. Es bietet bei großen DIB-Sätzen eine bessere Leistung als das ext3-Dateisystem. Der Rückschreibe-Journaling-Modus von ext3 bietet jedoch in etwa die gleiche Leistung wie das Reiser-Dateisystem, obwohl der standardmäßig geordnete Modus eine bessere Datenkonsistenz bietet. XFS ist ein leistungsfähiges Journaling-Dateisystem, das große Dateien verarbeiten kann und reibungslöse Datenübertragungen bietet. eDirectory 9.1 wird auf Plattformen mit der 32- oder 64-Bit-Version von SLES 11 mit XFS-Dateisystem unterstützt.
FLAIM unterstützt eine Blockgröße von 4 KB und 8 KB. Standardmäßig sind 4 KB festgelegt. Dies entspricht der standardmäßigen Blockgröße unter Linux (tune2fs -l device). Unter Solaris wird das UFS-Dateisystem jedoch mit einer standardmäßigen Blockgröße von 8 KB erstellt (df -g mountpoint). Wenn die FLAIM-Blockgröße kleiner ist als die Blockgröße des Dateisystems, können partielle Blockschreibevorgänge auftreten. Wenn die Datenbankblockgröße größer als die Blockgröße des Dateisystems ist, werden einzelne Blockschreibe- und Blocklesevorgänge in mehrere einzelne physische E/A-Operationen aufgeteilt. Daher sollten Sie darauf achten, dass die FLAIM-Blockgröße und die Blockgröße des Dateisystems übereinstimmen.
Die Blockgrößen können nur beim Erstellen der DIB gesteuert werden. Fügen Sie die Zeile „blocksize=8192“ zur Datei _ndsdb.ini hinzu, um die DIB mit einer Blockgröße von 8 KB zu erstellen.
Die richtige Blockgröße hängt von der durchschnittlichen Größe des FLAIM-Datensatzes in Ihrer Bereitstellung ab. Zur Ermittlung der richtigen Blockgröße für Ihre Bereitstellung sind empirische Tests mit geeigneten Prüfdaten erforderlich.