Paramétrage et optimisation des performances des index de recherche en texte intégral

Durant une alimentation de texte intégral, fdhost.exe ou sqlservr.exe peuvent manquer partiellement ou complètement de mémoire. Si le journal d'analyse de texte intégral indique que fdhost.exe est souvent redémarré ou que le code d'erreur 8007008 est retourné, cela signifie que l'un de ces processus manque de mémoire. Si fdhost.exe produit des vidages, en particulier sur des ordinateurs multiprocesseurs de grande capacité, cela peut signifier qu'il manque de mémoire.

Les causes possibles sont les suivantes :

• Si la quantité de mémoire physique disponible pendant une alimentation complète est égale à zéro, le pool de mémoires tampons SQL Server consomme peut-être la plupart de la mémoire physique du système.

  Le processus sqlservr.exe essaie de récupérer toute la mémoire disponible pour le pool de mémoires tampons, en fonction de la limite maximale de mémoire configurée pour le serveur. Si l'allocation de max server memory est trop importante, des insuffisances de mémoire et des échecs d'allocation de la mémoire partagée peuvent se produire pour le processus fdhost.exe.

  Notes

  Durant une alimentation de texte intégral sur un ordinateur multiprocesseur, par exemple un ordinateur IA64 64 bits, il peut se produire un conflit de mémoire au niveau du pool de mémoires tampons pour fdhost.exe ou sqlservr.exe. Le manque de mémoire partagée qui en résulte provoque des tentatives d'exécution de lots, des surexploitations de la mémoire et des vidages par le processus fdhost.exe.

  Vous pouvez résoudre ce problème en définissant de façon appropriée la valeur max server memory du pool de mémoires tampons SQL Server. Pour plus d'informations, consultez « Estimation des besoins en mémoire du processus hôte de démon de filtre (fdhost.exe) », plus loin dans cette rubrique. La réduction de la taille de lot utilisée pour l'indexation de texte intégral peut également s'avérer utile.

• Problème de pagination

  Si la taille du fichier d'échange est insuffisante, comme cela peut se produire sur un système qui dispose d'un petit fichier d'échange avec une croissance limitée, fdhost.exe ou sqlservr.exe risquent de manquer de mémoire.

  Si les journaux d'analyse n'indiquent pas de défaillances relatives à la mémoire, il est probable que les performances sont dégradées par une pagination excessive.

Estimation des besoins en mémoire du processus hôte de démon de filtre (fdhost.exe)

USE master;
GO
EXEC sp_configure 'max server memory', 7052;
GO
RECONFIGURE;
GO

Il faut s'attendre à ce que les performances des alimentations complètes ne soient pas optimales lorsque la consommation processeur moyenne est inférieure à environ 30 pour cent. Cette section traite de quelques facteurs qui affectent la consommation processeur.

• Temps d'attente élevé pour les pages

  Pour savoir si un temps d'attente de page est élevé, exécutez l'instruction Transact-SQL suivante :

  Execute SELECT TOP 10 * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC;
  

  Le tableau suivant décrit les types de temps d'attente présentant un intérêt ici.

  Type d’attente	Description	Résolution possible
  PAGEIO_LATCH_SH (_EX ou _UP)	Cela pourrait indiquer un goulet d'étranglement ES, auquel cas vous devriez généralement constater également une durée de file d'attente de disque moyenne élevée.	Le déplacement de l'index de recherche en texte intégral vers un groupe de fichiers différent sur un disque différent peut aider à réduire le goulet d'étranglement ES.
  PAGELATCH_EX (ou _UP)	Cela pourrait indiquer beaucoup de concurrence entre les threads qui essaient d'écrire dans le même fichier de base de données.	L'ajout des fichiers au groupe de fichiers sur lequel l'index de texte intégral réside pourrait aider à alléger cette concurrence.

  Pour plus d'informations, consultez sys.dm_os_wait_stats (Transact-SQL).

• Inefficacités dans l'analyse de la table de base

  Un remplissage complet analyse la table de base pour produire des lots. Cette analyse de table peut être inefficace dans les scénarios suivantes :

  • Si la table de base a un pourcentage élevé de colonnes hors ligne qui sont indexées de texte intégral, l'analyse de la table de base pour produire des lots peut être le goulet d'étranglement. Dans ce cas, le déplacement des petites données dans la ligne à l'aide de varchar(max) ou nvarchar(max) peut améliorer la situation.

  • Si la table de base est très fragmentée, l'analyse peut être inefficace. Pour plus d'informations sur le calcul des données hors ligne et de la fragmentation des index, consultez sys.dm_db_partition_stats (Transact-SQL) et sys.dm_db_index_physical_stats (Transact-SQL).

    Pour réduire la fragmentation, vous pouvez réorganiser ou reconstruire l'index cluster. Pour plus d'informations, consultez Réorganisation et reconstruction d'index.