SharePoint 2007 : Quelques optimisations possibles au niveau de SQL Server pour MOSS Search 2007
Dans le cadre de la conception et de la gestion d’une ferme Intranet SharePoint, on peut être tenté de tout mettre dans la même ferme ce qui simplifiera l’usage des utilisateurs avec les services suivant :
- Portail Intranet corporate
- Team Sites (sites de projet par exemple)
- MySites et profiling
- Recherche globale
Ceci ne posera aucun problème dans le cas de petites fermes, mais si celle-ci commence à être conséquente avec plusieurs milliers de comptes utilisateurs ou des millions de documents indexés, on peut observer des lenteurs pénalisant le rendu des utilisateurs.
C’est donc dans ce contexte, que j’ai du faire appel au support de Microsoft, particulièrement pour la problématique des temps infinis d’indexation par le Crawler. Ainsi, après un gros travail de recherche effectué en compagnie de Yvan Duhamel, nous avons pu trouver des pistes d’amélioration que je peux donc expliquer ici.
La première chose est de réaliser que la (ou les) machine(s) SQL Server de la ferme MOSS que vous montez sera partagée pour tous les services précités. Ainsi le moteur SQL Server va travailler aussi bien pour la gestion et le stockage des données des MySites et Team Sites, que de la gestion du contenu du site corporate (souvent basé sur un site de publishing) et surtout pour le moteur de recherche.
Le fait est que sur des environnements conséquent, le moteur de recherche devient un très gros consommateur de ressources SQL Server :
- Indexation du contenu (donc lecture et surtout écriture dans la base)
- Interrogation (donc surtout lecture et un peu d’écriture pour les stats)
- Propagation si vous avez plusieurs Query (donc surtout lecture et un peu d’écriture pour la gestion des synch)
Ainsi toutes ces activités, mais surtout l’indexation vont faire travailler SQL Server en écriture dans la base de données de recherche. Cela veut donc dire que ces taches vont aussi impacter les lectures-écritures sur les disques de votre serveur SQL Server.
On peut voir cela par les compteurs de performances suivant (Objet PhysicalDisk) à placer sur chaque partition :
- Avg Disk Queue Lenght (doit rester en dessous de 1)
- Avg Disk sec/Read (le plus bas possible, attention c’est en seconde et non milli-seconde)
- Avg Disk sec/Write (le plus bas possible, attention c’est en seconde et non milli-seconde)
C’est donc la que les optimisations sont possibles, car ces lectures-écritures vont aussi ralentir le fonctionnement des autres services de votre ferme MOSS, puisque le serveur SQL va devoir utiliser la file d’attente d’écriture sur disque.
Il faut donc repenser la base de données du moteur de recherche comme une base de données temporaire. En effet, si le moindre soucis survient sur votre ferme MOSS et que la base de données est désynchronisée des fichiers d’index (CI files), il faudra recréer tout le système de zéro.
De ce fait, on peut optimiser cette base comme on le ferait pour la base de données temporaire système de SQL Server (TempDB), dont voici la liste :
- Création d’une ligne SCSI dédiée en RAID1
- Déplacement de la base de données du moteur de recherche sur cette ligne (LOG et DATA)
- Création de fichiers de données (MDF) et de log (LDF) avec le même nombre que le nombre de coeurs vu par SQL Server
- Passage de la journalisation en mode simple
- Fixation de la taille des fichiers avec un gros volume afin d’éviter les étapes de réallocation d’espace par SQL Server
- Ajout des fichiers MDF, NDF et LDF dans les exceptions de votre antivirus pour ne pas que celui-ci cherche à accéder sur les fichiers SQL Server
- Défragmentation des partitions une fois ce déplacement de fichiers effectué
Cela a donc été fait dans ma ferme et la configuration des fichiers SQL est la suivante (8 Coeurs visibles sur mon serveur SQL) :
Ceci a permis de stabiliser l’environnement SQL Server qui est revenu dans un état plus normal.
Il nous reste encore du travail sur l’environnement MOSS, mais je vous conseille de faire ce contrôle rapide des compteurs de performance listés plus haut, car cela ne se voit nulle part ailleurs (le processeur était toujours à moins de 5 % d’activité sur cette machine).
Romelard Fabrice [MVP]
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
