• Article

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

Les performances de l'indexation de texte intégral et les requêtes de texte intégral sont influencées par les ressources matérielles telles que la mémoire, la vitesse du disque et de l'UC ainsi que l'architecture de l'ordinateur. La cause principale d'une baisse des performances de l'indexation de texte intégral est les limites liées aux ressources matérielles :

  • Si l'utilisation de l'UC par le processus hôte de démon de filtre (fdhost.exe) ou le processus (sqlservr.exe) SQL Server approche des 100 pour cent, le processeur est le goulet d'étranglement.

  • Si la longueur moyenne de la file d'attente du disque est plus de deux fois supérieure au nombre de têtes de disque, le disque est engorgé. La première solution consiste à créer des catalogues de texte intégral distincts des fichiers et des journaux de la base de données SQL Server. Placez les journaux, les fichiers de base de données et les catalogues de texte intégral sur des disques distincts. L'achat de disques plus rapides et l'utilisation de RAID peuvent également contribuer à l'amélioration des performances d'indexation.

  • En cas de manque de mémoire physique (limite de 3 Go), la mémoire est engorgée. Les limitations de mémoire physique sont possibles sur tous les systèmes, et sur les systèmes 32 bits, la pression de mémoire virtuelle peut ralentir l'indexation de texte intégral.

    Notes

    À partir de SQL Server 2008, le moteur d'indexation et de recherche en texte intégral peut utiliser la mémoire AWE parce que le moteur d'indexation et de recherche en texte intégral fait partie du sqlservr.exe.

Si le système ne rencontre aucun goulet d'étranglement matériel, les performances d'indexation de la recherche en texte intégral dépendent essentiellement des éléments suivants :

  • Durée de création des traitements de texte intégral par SQL Server.

  • Rapidité d'utilisation de ces traitements par le démon de filtre.

Notes

Contrairement à un remplissage complet, le remplissage du suivi des modifications automatique, incrémentiel ou manuel n'a pas pour objectif de maximiser les ressources matérielles en vue d'obtenir une vitesse supérieure. Par conséquent, ces suggestions de paramétrage peuvent ne pas améliorer les performances de l'indexation de texte intégral.

À la fin d'une alimentation, une fusion finale est déclenchée ; les fragments d'index sont fusionnés entre eux dans un index de recherche en texte intégral. Il en résulte une amélioration des performances des requêtes dans la mesure où seul l'index principal doit être interrogé au lieu des fragments d'index ; par ailleurs, les statistiques de score sont plus appropriées pour un classement en fonction de la pertinence. Notez que la fusion principale peut nécessiter de nombreuses entrées/sorties, car de grandes quantités de données doivent être écrites et lues lors de la fusion des fragments d'index. Toutefois, cela ne bloque pas les requêtes entrantes.

Important

La fusion principale d'une grande quantité de données peut créer une transaction dont l'exécution est longue, ce qui retarde la troncation du journal des transactions pendant le point de contrôle. Dans ce cas, en mode de récupération complète, la taille du journal des transactions peut s'accroître considérablement. Avant de réorganiser un index de recherche en texte intégral de grande taille dans une base de données qui utilise le mode de récupération complète, il est fortement recommandé de vous assurer que votre journal des transactions contient un espace suffisant pour une transaction dont l'exécution est longue. Pour plus d'informations, consultez Gestion de la taille du fichier journal des transactions.

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

Pour optimiser les performances de vos index de recherche en texte intégral, appliquez les meilleures pratiques suivantes :

  • Pour utiliser tous les processeurs ou les noyaux au maximum, attribuez à sp_configure ‘max full-text crawl ranges’ la valeur correspondant au nombre de processeurs présents sur le système. Pour plus d'informations sur cette option de configuration, consultez Option max full-text crawl range.

  • Vérifiez si la table de base a un index cluster. Utilisez un type de données entier pour la première colonne de l'index cluster. Évitez d'utiliser les GUID dans la première colonne de l'index cluster. Un remplissage multiplage sur un index cluster peut produire la vitesse de remplissage la plus élevée. Nous recommandons que la colonne servant de clé de texte intégral corresponde à un type de données Integer.

  • Mettez à jour les statistiques de la table de base à l'aide de l'instruction UPDATE STATISTICS. Le plus important est de mettre à jour les statistiques sur l'index cluster ou la clé de texte intégral pour un remplissage complet. De cette manière, un remplissage sur plusieurs plages peut générer les partitions adéquates sur la table.

  • Créez un index secondaire sur une colonne timestamp si vous souhaitez améliorer les performances de l'alimentation incrémentielle.

  • Avant d'effectuer une alimentation complète sur un ordinateur multiprocesseur de grande capacité, nous vous recommandons de limiter temporairement la taille du pool de mémoires tampons en définissant la valeur max server memory de manière à laisser suffisamment de mémoire au processus fdhost.exe et au système d'exploitation. 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.

Résolution des problèmes de performances de l'alimentation complète

Pour diagnostiquer les problèmes de performances, consultez les journaux d'analyse de texte intégral. Pour plus d'informations sur les journaux d'analyse, consultez Dépannage d'erreurs dans une alimentation de texte intégral (Analyse)).

Il est recommandé de suivre l'ordre de dépannage suivant si les performances des alimentations complètes ne sont pas satisfaisantes.

Utilisation de la mémoire physique

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.

Notes

Pour plus d'informations sur les mémoires tampons utilisées par une analyse de texte intégral, consultez sys.dm_fts_memory_buffers (Transact-SQL).

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)

La quantité de mémoire requise par le processus fdhost.exe pour une alimentation dépend principalement du nombre de plages d'analyses de texte intégral utilisées, de la taille de la mémoire partagée entrante et du nombre maximal d'instances relatives à la mémoire partagée entrante.

La quantité de mémoire consommée (en octets) par l'hôte de démon de filtre peut être estimée approximativement à l'aide de la formule suivante :

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

Les valeurs par défaut des variables contenues dans la formule précédente sont les suivantes :

Variable

Valeur par défaut

number_of_crawl_ranges

Nombre de processeurs

ism_size

1 Mo pour les ordinateurs x86

4 Mo, 8 Mo ou 16 Mo pour les ordinateurs x64, en fonction de la mémoire physique totale

max_outstanding_isms

25 pour les ordinateurs x86

5 pour les ordinateurs x64

Le tableau suivant présente des indications expliquant comment estimer les besoins en mémoire de fdhost.exe. Les formules figurant dans ce tableau utilisent les valeurs suivantes :

  • F, qui est une évaluation de la mémoire requise par fdhost.exe (en Mo).

  • T, qui est la mémoire physique totale disponible sur le système (en Mo).

  • M, qui est le paramètre Mémoire maximum du serveur optimal.

Important

Pour des informations essentielles sur les formules, consultez 1, 2et 3, ci-dessous.

Plateforme

Estimation des besoins en mémoire de fdhost.exe en Mo : F1

Formule pour calculer max server memory : M2

x86 avec AWE désactivé

F=Number of crawl ranges* 50

M=minimum(T, 2000)–F– 500

x86 avec AWE activé

F=Number of crawl ranges* 50

M=T–F– 500

x64 ou IA643

F=Number of crawl ranges* 10 * 8

M=T–F– 500

1 Si plusieurs remplissages complets sont en cours, calculez séparément les besoins en mémoire de chaque fdhost.exe, comme F1, F2, etc. Puis calculez M comme T**.** sigma**(Fi)**.

2 500 Mo est une estimation de la mémoire requise par d'autres processus dans le système. Si le système effectue un travail supplémentaire, augmentez cette valeur en conséquence.

3 .ism_size est censé être de 8 Mo pour les plateformes x64.

Exemple : estimation des besoins en mémoire de fdhost.exe

Cet exemple se rapporte à un ordinateur AMD64 avec 8 Go de mémoire vive (RAM) et 4 processeurs double cœur. Les premières estimations de calcul de la mémoire requise par fdhost.exe : F. Le nombre de plages d'analyse est 8.

F = 8*10*8=640

Le calcul suivant permet d'obtenir la valeur optimale pour max server memory — M. Total de la mémoire physique disponible sur ce système en Mo — T— : 8192.

M = 8192-640-500=7052

Exemple : configuration de la mémoire maximum du serveur

Cet exemple utilise les instructions sp_configure et RECONFIGURETransact-SQL pour affecter à max server memory la valeur calculée pour M dans l'exemple précédent, 7052 :

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

Pour définir l'option de configuration max server memory

Facteurs pouvant réduire la consommation processeur

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.