Améliorer les performances des index en texte intégral

S’applique à :SQL Server Base de données Azure SQL Azure SQL Managed Instance

Cet article traite des causes courantes de faibles performances pour les index et requêtes en texte intégral, ainsi que la manière de les atténuer.

Causes courantes des problèmes de performances

Cette section décrit les causes courantes des problèmes de performance lors de l’utilisation d’index en texte intégral.

Problèmes liés aux ressources matérielles

Des ressources matérielles telles que la mémoire, la vitesse du disque, la vitesse du processeur et l’architecture de la machine influencent les performances de l’indexation en texte intégral et des requêtes en texte intégral.

Les limites matérielles de ressources entraînent une réduction des performances d’indexation en texte intégral.

Processeur. Si l’utilisation du processeur par le démon hébergeur du filtre (fdhost.exe) ou le processus SQL Server (sqlservr.exe) est proche de 100 %, le CPU est le goulot d’étranglement.
Mémoire. Un manque de mémoire physique peut provoquer un goulot d’étranglement.
Disque. Si la longueur moyenne d’une file d’attente de disque est supérieure à deux fois le nombre de têtes de disque, il y a un goulot d’étranglement sur le disque. 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’installation de disques plus rapides et l’utilisation de RAID peuvent également contribuer à améliorer les performances d’indexation.

Problèmes liés au traitement par lots de texte intégral

Si le système ne présente pas de goulets d’étranglement matériels, la performance d’indexation de la recherche en texte intégral dépend principalement des facteurs suivants :

Combien de temps faut-il au moteur de base de données pour créer des lots en texte intégral ?
À quelle vitesse le démon filtre consomme ces lots.

Problèmes liés à l’alimentation d’un index de recherche en texte intégral

Type de population. Contrairement à la population complète, la population de suivi incrémental, manuel et automatique des changements n’est pas conçue pour maximiser les ressources matérielles afin d’atteindre une vitesse plus rapide. Par conséquent, les suggestions de réglage de cet article pourraient ne pas améliorer les performances de l’indexation en texte intégral lorsqu’il utilise une population de suivi des changements incrémentale, manuelle ou automatique.
Fusion principale. Lorsqu’une population se termine, un processus final de fusion fusionne les fragments d’index en un seul index maître en texte intégral. Ce processus améliore les performances des requêtes puisque seul l’index maître doit être interrogé et non un certain nombre de fragments d’index. De meilleures statistiques de score peuvent être utilisées pour le classement de pertinence. Cependant, la fusion maîtresse peut être intensive en E/S car de grandes quantités de données doivent être écrites et lues lors de la fusion des fragments d’index. Cependant, cela ne bloque pas les requêtes entrantes.

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 Gérer la taille du fichier journal des transactions.

Améliorer les performances des index de recherche en texte intégral

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

Pour utiliser tous les cœurs CPU au maximum, changez max full-text crawl range le nombre de cœurs sur le système. Pour plus d’informations, voir configuration du serveur : plage maximale d’exploration du texte complet.
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 peuplement sur plusieurs plages d’un index clusterisé peut offrir la vitesse de peuplement la plus élevée. Utilisez un type de données entier pour la colonne servant de clé en texte intégral.
Mettez à jour les statistiques de la table de base à l’aide de l’instruction UPDATE STATISTICS . Plus important encore, mettez à jour les statistiques sur l'index clusterisé ou la clé de texte intégral pour une population complète. De cette manière, un remplissage sur plusieurs plages peut générer les partitions adéquates sur la table.
Avant d’effectuer un remplissage complet sur un grand ordinateur multicœur, limitez temporairement la taille du pool de tampons en fixant la valeur max server memory pour laisser suffisamment de mémoire pour l’utilisation du processus fdhost.exe et du système d’exploitation. Pour plus d’informations, voir Estimer les besoins en mémoire du processus hôte du démon filtre (fdhost.exe), plus loin dans cet article.
Si vous utilisez une alimentation incrémentielle basée sur une colonne timestamp, créez un index secondaire sur la colonne timestamp afin d’améliorer les performances de l’alimentation incrémentielle.

Résoudre les problèmes de performance des populations complètes

Veuillez consulter la section suivante pour résoudre les problèmes de performance avec des populations complètes.

Passer en revue les journaux d’analyse de texte intégral

Pour aider à diagnostiquer les problèmes de performance, consultez les journaux d’exploration en texte intégral.

Lorsqu'une erreur se produit durant une analyse, la fonction d'analyse de la recherche en texte intégral crée et conserve un journal de l'analyse sous forme de fichier texte. Chaque journal d’exploration correspond à un catalogue en texte intégral spécifique. Par défaut, les journaux d’analyse pour une instance donnée (dans cet exemple, l’instance par défaut) figurent dans le dossier %ProgramFiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\LOG.

Le fichier journal d'exploration suit le schéma de dénomination suivant :

SQLFT<DatabaseID><FullTextCatalogID>.[<n>]

Les parties variables du nom de fichier du journal d’analyse sont les suivantes.

<DatabaseID>: L’ID d’une base de données, sous forme de numéro à cinq chiffres avec des zéros à l’avant.
<FullTextCatalogID>: ID de catalogue en texte intégral, sous forme de numéro à cinq chiffres avec des zéros en tête.
<n> : entier qui indique qu'il existe un ou plusieurs journaux d'analyse du même catalogue de texte intégral.

Par exemple, SQLFT0000500008.2 est le fichier journal d’analyse pour une base de données ayant un ID de base de données = 5 et un ID de catalogue de texte intégral = 8. Le 2 à la fin du nom de fichier indique qu'il existe deux fichiers journaux d'analyse pour cette combinaison base de données/catalogue.

Vérifier l’utilisation de la mémoire physique

Lors d’un remplissage en texte intégral, le processus fdhost.exe ou sqlservr.exe peut manquer de mémoire, voire être à court de mémoire.

Si le journal d’exploration en texte intégral montre qu’il fdhost.exe redémarre souvent ou renvoie un code d’erreur 8007008, cela signifie que l’un de ces processus est en manque de mémoire.
Si fdhost.exe produit des images mémoire, en particulier sur des systèmes multiprocesseurs de grande capacité, cela peut signifier qu’il manque de mémoire.
Pour des informations sur les tampons mémoire utilisés par une exploration de texte intégral, voir sys.dm_fts_memory_buffers.

Les causes possibles d’une faible mémoire ou de problèmes de non-mémoire incluent les éléments suivants :

Mémoire insuffisante. Si la quantité de mémoire physique disponible lors d’une population complète est nulle, le pool de tampons du Moteur de base de données pourrait consommer la majeure partie 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, jusqu’à la limite maximale de mémoire configurée pour le serveur. Si l’allocation max server memory est trop importante, des conditions de manque de mémoire et un défaut d’allocation de mémoire partagée peuvent survenir pour le fdhost.exe processus.

Réglez la max server memory valeur du pool de tampons Moteur de base de données de manière appropriée pour résoudre ce problème. Pour plus d’informations, voir Estimer les besoins en mémoire du processus hôte du démon filtre (fdhost.exe), plus loin dans cet article. Réduire la taille du lot utilisée pour l’indexation du texte intégral pourrait également aider.
Contention de mémoire. Lors d’un remplissage en texte complet sur un système multi-cœurs, fdhost.exe et sqlservr.exe peuvent se battre pour la mémoire du pool tampon. Le manque de mémoire partagée qui en résulte provoque des nouvelles tentatives d'exécution de lots, des surexploitations de la mémoire et des vidages par le processus fdhost.exe.
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 aucune défaillance liée à la mémoire, un paginage excessif cause probablement des ralentissements.

Estimer les besoins en mémoire du processus hôte du démon filtre (`fdhost.exe`)

La quantité de mémoire dont le fdhost.exe processus a besoin pour se remplir dépend principalement du nombre de plages d’exploration en texte complet qu’il utilise, de la taille de la mémoire partagée entrante (ISM) et du nombre maximal d’instances ISM.

Vous pouvez estimer approximativement la consommation mémoire de l’hôte du démon filtre en utilisant la formule suivante :

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

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

Variable	Valeur par défaut
number_of_crawl_ranges	Nombre de cœurs de processeur
ism_size	1 Mo pour les ordinateurs x86 4 Mo, 8 Mo ou 16 Mo pour les ordinateurs x64, selon la mémoire physique totale
max_outstanding_isms	25 pour les ordinateurs x86 5 pour les ordinateurs x64

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

F, qui est une estimation de la mémoire nécessaire par fdhost.exe (en Mo).
T, qui est la mémoire physique totale disponible sur le système (en Mo).
M, qui est le réglage optimal max server memory .

Pour obtenir des informations essentielles sur les formules suivantes, consultez les remarques qui suivent le tableau.

Plateforme	Estimation `fdhost.exe` des besoins en mémoire dans MB : F^1	Formule pour calculer la mémoire maximale du serveur : M^2
x86	F = Nombre de plages d’analyse * 50	M = minimum (T, 2000) - F - 500
x64	F = Nombre de plages d’analyse * 10 * 8	M = T - F - 500

Si plusieurs populations complètes sont en cours, calculez les fdhost.exe besoins en mémoire de chacun séparément, comme F1, F2, etc. Puis calculez M comme T - Σ(Fi).
500 Mo est une estimation de la mémoire requise par les autres processus dans le système. Si le système effectue un travail supplémentaire, augmentez cette valeur en conséquence.
ism_size est supposé être 8 Mo pour les plateformes x64.

Exemple : Estimer les besoins en mémoire de `fdhost.exe`

Cet exemple concerne un ordinateur 64 bits disposant de 8 Go de RAM et de 4 processeurs double-cœur. Le premier calcul estime la mémoire nécessaire à fdhost.exeF. Le nombre de plages de rampement est 8.

F = 8 * 10 * 8 = 640

Le calcul suivant obtient la valeur optimale pour max server memory (M). La mémoire physique totale disponible sur ce système, en Mo, (T), est 8192.

M = 8192 - 640 - 500 = 7052

Exemple : Set `max server memory`

Cet exemple utilise les instructions sp_configure et RECONFIGURE Transact-SQL pour définir max server memory à la valeur calculée pour M dans l’exemple précédent, 7052:

USE master;
GO

EXECUTE sp_configure 'max server memory', 7052;
GO

RECONFIGURE;
GO

Pour plus d’informations sur les options de mémoire serveur, voir options de configuration mémoire serveur.

Vérifier l’utilisation du processeur

Les performances des populations complètes ne sont pas optimales lorsque la consommation moyenne de CPU est inférieure à environ 30 %. Voici quelques facteurs qui affectent la consommation processeur.

Temps d’attente élevé pour les pages

Pour déterminer si le temps d’attente d’une page est élevé, exécutez l’instruction Transact-SQL suivante :

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

Le tableau suivant décrit les types d’attente pertinents.

Type d’attente	Description	Résolution possible
`PAGEIO_LATCH_SH` (`_EX` ou `_UP`)	Ce type d'attente pourrait indiquer un goulet d'étranglement E/S, auquel cas vous devriez généralement constater également une durée de file d'attente de disque moyenne élevée.	Déplacer l’index du texte intégral vers un autre groupe de fichiers sur un autre disque pourrait aider à réduire le goulot d’étranglement d’E/S.
`PAGELATCH_EX` (ou `_UP`)	Ce type d’attente pourrait indiquer beaucoup de conflits entre les threads qui essaient d’écrire sur le même fichier de base de données.	Ajouter des fichiers au groupe de fichiers où se trouve l’index en texte intégral pourrait aider à atténuer ce type de controverse.

Pour plus d’informations, consultez sys.dm_os_wait_stats.

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

Un remplissage complet analyse la table de base pour produire des lots. Ce balayage de table pourrait être inefficace dans les scénarios suivants :
- 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 fait de déplacer les données de petite taille dans la ligne à l’aide de varchar(max) ou de nvarchar(max) peut aider.
- Si la table de base est très fragmentée, l'analyse peut être inefficace. Pour des informations sur le calcul des données hors ligne et de la fragmentation des indices, voir sys.dm_db_partition_stats et sys.dm_db_index_physical_stats.
  
  Pour réduire la fragmentation, vous pouvez réorganiser ou reconstruire l'index cluster. Pour plus d’informations, consultez Optimiser la maintenance des index pour améliorer les performances des requêtes et réduire la consommation des ressources.

Résoudre les problèmes de ralentissement de l’indexation des documents

Remarque

Cette section décrit un problème qui affecte uniquement les clients qui indexent des documents (tels que les documents Microsoft Word) qui incorporent d’autres types de documents.

Le moteur d’indexation et de recherche en texte intégral utilise deux types de filtres lorsqu’il remplit un index de recherche en texte intégral : des filtres multithreads et des filtres monothreads.

Certains documents, comme les documents Word, utilisent des filtres multithreadés.
D’autres documents, tels que les documents Adobe Acrobat Portable Document Format (PDF), utilisent des filtres à un seul fil.

Pour des raisons de sécurité, les filtres sont chargés par les processus hôtes de démon de filtre. Une instance de serveur utilise un processus multithread pour tous les filtres multithreads et un processus monothread pour tous les filtres monothreads. Lorsqu’un document qui utilise un filtre multithreadé contient un document incorporé qui utilise un filtre monothreadé, le moteur de texte intégral lance un processus monothreadé pour le document incorporé. Par exemple, quand il rencontre un document Word qui contient un document PDF, le Moteur d’indexation et de recherche en texte intégral utilise le processus multithread pour le contenu Word et lance un processus monothread pour le contenu PDF. Cependant, un filtre à fil simple peut ne pas bien fonctionner dans cet environnement et déstabiliser le processus de filtrage.

Dans certaines circonstances, lorsque ce type d’incorporation est courant, cette déstabilisation peut provoquer des blocages du processus. Lorsque cette condition se produit, le Full-Text Engine redirige tout document défaillant (par exemple, un document Word contenant du contenu PDF intégré) vers le processus de filtrage à thread unique. Si le réacheminement a lieu fréquemment, il en résulte une détérioration des performances du processus d'indexation de texte intégral.

Pour contourner ce problème, marquez le filtre du document conteneur (le document Word, dans cet exemple) comme un filtre à thread unique. Pour marquer un filtre comme un filtre à thread unique, fixez la ThreadingModel valeur du registre du filtre à Apartment Threaded. Pour plus d’informations sur les threads uniques cloisonnés (STA), consultez Présentation et utilisation des modèles de threads COM.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-07-21