Le sous-système de disque est le goulot d'étranglement le plus courant. Les E/S restent pendant une période relativement prolongée dans les longues files d'attente, ce qui entraîne une forte utilisation des disques et une inactivité des cycles de processeur. Utilisez l'outil iostat pendant les périodes de charge maximale prévue pour déterminer les indicateurs de temps de réponse moyen.
Les opérations de lecture, d'écriture et de mise à jour sur le disque peuvent être séquentielles ou aléatoires. Les lectures et les mises à jour aléatoires constituent le modèle d'accès le plus courant dans les déploiements eDirectory.
Voici quelques solutions pour les workloads aléatoires :
Augmentez la mémoire RAM. Cela permet de mettre en cache les données utilisées fréquemment ou faisant l'objet d'une lecture anticipée au niveau de la couche du système de fichiers. Le fichier DIB peut également être mis en cache dans le sous-système FLAIM.
Utilisez des volumes dédiés pour le fichier DIB. Les performances du système de fichiers sont améliorées pour les volumes créés près de l'axe. Utilisez des volumes dédiés pour les journaux RFL et d'autres journaux.
Les disques présentent des temps de latence toujours plus importants en raison de leur fragmentation. Ils doivent par conséquent être défragmentés.
Ajoutez d'autres lecteurs pour les journaux RFL FLAIM. Ce type de consignation peut être effectué sur des disques à grande vitesse.
Utilisez un environnement RAID 10(1+0) avec un plus grand nombre de disques durs.
Les fichiers créés par eDirectory peuvent atteindre 4 Go. Les systèmes de fichiers optimisés pour gérer des fichiers volumineux sont efficaces avec eDirectory.
Pour Solaris™, le système de fichiers VxFS Veritas* est un système de fichiers basé sur les extensions et dans lequel les métadonnées sont optimisées pour les fichiers volumineux. Le système de fichiers UFS est indirectement basé sur les blocs, car les métadonnées du système de fichiers sont stockées dans un grand nombre de blocs. Elles peuvent même être découpées dans le cas de fichiers volumineux, ce qui ralentit l'exécution d'UFS pour ces fichiers.
Pour Linux™, le système de fichiers Reiser est un système de fichiers de journalisation rapide, plus performant que le système de fichiers ext3 sur les ensembles DIB volumineux. Toutefois, le mode de journalisation d'écriture différée du système ext3 est réputé pour s'adapter aux performances du système de fichiers Reiser, même si le mode de classement par défaut fournit une meilleure cohérence des données. Le système de fichiers de journalisation XFS hautes performances peut gérer les fichiers volumineux et proposer des transferts de données plus fluides. eDirectory 8.8 SP8 est pris en charge sur les plates-formes SLES 11 32 bits et 64 bits avec système de fichiers XFS.
Le gestionnaire FLAIM prend en charge les blocs de 4 Ko et 8 Ko. La taille par défaut est de 4 Ko. C'est la taille par défaut des blocs sous Linux (tune2fs -l device). En revanche, sur Solaris, le système de fichiers UFS est créé avec une taille de blocs par défaut de 8 Ko (df -g mountpoint). Si la taille des blocs FLAIM est inférieure à celle des blocs du système de fichiers, des blocs peuvent être écrits partiellement. Si la taille des blocs de base de données est supérieure à celle des blocs du système de fichiers, chaque lecture et écriture de bloc est divisée en une série d'opérations d'E/S physiques distinctes. Par conséquent, vous devez faire en sorte que la taille des blocs FLAIM soit toujours identique à celle des blocs du système de fichiers.
La taille des blocs ne peut être contrôlée que lors de la création du fichier DIB. Ajoutez une ligne « blocksize = 8192 » au fichier _ndsdb.ini pour créer le fichier DIB avec une taille de blocs de 8 Ko.
Le choix de la taille des blocs dépend de la taille moyenne des enregistrements FLAIM dans les déploiements. Il est nécessaire d'effectuer des tests empiriques sur l'ensemble de données de test adéquat afin de déterminer la taille idéale des blocs dans votre déploiement.