Mejorar el rendimiento de los índices de texto completo

Se aplica a:SQL Server Azure SQL Database Azure SQL Managed Instance

Este artículo aborda las causas comunes del bajo rendimiento de índices y consultas en texto completo, y cómo mitigarlas.

Causas comunes de los problemas de rendimiento

Esta sección describe las causas de los problemas comunes de rendimiento cuando se utilizan índices de texto completo.

Problemas de los recursos de hardware

Recursos de hardware como la memoria, la velocidad del disco, la velocidad de la CPU y la arquitectura de la máquina afectan al rendimiento de la indexación de texto completo y las consultas de texto completo.

Los límites de recursos de hardware reducen el rendimiento de indexación de texto completo.

CPU. Si el uso de la CPU por parte del proceso anfitrión del daemon de filtro (fdhost.exe) o del proceso de SQL Server (sqlservr.exe) está cerca del 100 %, la CPU es el cuello de botella.
Memory. La escasez de memoria física puede causar un cuello de botella.
Disco. Si la longitud media de la cola de espera del disco es más del doble del número de cabezales de disco, existe un cuello de botella en el disco. La solución principal consiste en crear catálogos de texto completo independientes de los registros y los archivos de base de datos de SQL Server. Coloque los registros, los archivos de base de datos y los catálogos de texto completo en discos independientes. También puede ayudar a mejorar el rendimiento de la indización la instalación de discos más rápidos y el uso de RAID.

Problemas de procesamiento por lotes de texto completo

Si el sistema no presenta cuellos de botella hardware, el rendimiento de indexación de la búsqueda en texto completo depende principalmente de los siguientes factores:

Cuánto tarda el Motor de base de datos en crear lotes de texto completo.
Con qué rapidez consume esos lotes el daemon de filtrado.

Problemas de rellenado de índices de texto completo

Tipo de población. A diferencia de la población completa, la población incremental, manual y con seguimiento automático de cambios no están diseñadas para maximizar los recursos de hardware con el fin de lograr una mayor velocidad. Por lo tanto, es posible que las sugerencias de ajuste que se ofrecen en este artículo no mejoren el rendimiento de la indexación de texto completo cuando se utilicen las poblaciones incrementales, manuales o con seguimiento automático de cambios.
Combinación maestra. Cuando termina una población, un proceso final de fusión fusiona los fragmentos del índice en un único índice maestro de texto completo. Este proceso mejora el rendimiento de las consultas, ya que solo es necesario consultar el índice maestro en lugar de un número de fragmentos de índice. Se podrían usar mejores estadísticas de puntuación para la clasificación de relevancia. Sin embargo, la fusión principal puede requerir un uso intensivo de E/S, ya que deben escribirse y leerse grandes cantidades de datos al fusionar fragmentos del índice. Aunque no bloquea las consultas entrantes.

La fusión en el servidor maestro de una gran cantidad de datos puede generar una transacción de larga duración, lo que retrasa el truncamiento del registro de transacciones durante el punto de control. En este caso, bajo el modelo de recuperación completa, el registro de transacciones podría crecer significativamente. Como práctica recomendada, antes de reorganizar un índice de texto completo grande en una base de datos que use el modelo de recuperación completa, asegúrese de que el registro de transacciones contenga el espacio suficiente para una transacción de larga duración. Para obtener más información, consulte Administración del tamaño del archivo de registro de transacciones.

Optimizar el rendimiento de los índices de texto completo

Para obtener el máximo rendimiento de los índices de texto completo, implemente las prácticas recomendadas siguientes:

Para usar todos los núcleos de CPU al máximo, cambia max full-text crawl range el número de núcleos en el sistema. Para más información, consulta configuración del servidor: rango máximo de rastreo de texto completo.
Asegúrese de que la tabla base tiene un índice clúster. Use un tipo de datos entero para la primera columna del índice clúster. Evite usar GUID en la primera columna del índice agrupado. Un rellenado de varios intervalos en un índice agrupado puede producir la velocidad de población más alta. Utiliza un tipo de dato entero para la columna que sirve como clave de texto completo.
Actualice las estadísticas de la tabla base mediante la UPDATE STATISTICS instrucción . Más importante aún, actualice las estadísticas del índice agrupado o de la clave de texto completo para una población completa. Esta acción ayuda a que una población de rango múltiple genere buenas particiones en la tabla.
Antes de realizar una población completa en un ordenador grande con varios núcleos, limita temporalmente el tamaño del grupo de búferes estableciendo el valor max server memory para dejar memoria suficiente para el proceso fdhost.exe y para el uso del sistema operativo. Para obtener más información, consulta Calcular los requisitos de memoria del proceso del host del demonio de filtrado (fdhost.exe), más adelante en este artículo.
Si utiliza la población incremental basada en una columna de marca de tiempo, cree un índice secundario en la columna timestamp para mejorar el rendimiento de la población incremental.

Solucionar los problemas de rendimiento de las poblaciones completas

Consulte la siguiente sección para resolver problemas de rendimiento con poblaciones completas.

Revisar los registros de rastreo de texto completo

Para ayudar a diagnosticar problemas de rendimiento, revisa los registros de rastreo en texto completo.

Cuando se produce un error durante el rastreo, la función de registro del rastreo de Búsqueda de texto completo crea y mantiene un registro del rastreo, que es un archivo de texto sin formato. Cada registro de rastreo se corresponde con un determinado catálogo de texto completo. De forma predeterminada, los registros de rastreo de una instancia determinada (en este ejemplo, la instancia predeterminada) se encuentran en la carpeta %ProgramFiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\LOG.

El archivo de registro de rastreo sigue el siguiente esquema de nomenclatura:

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

Las partes variables del nombre de archivo de registro de rastreo son las siguientes.

<DatabaseID>: El ID de una base de datos, como un número de cinco dígitos con ceros al principio.
<FullTextCatalogID>: ID de catálogo en texto completo, como un número de cinco dígitos con ceros iniciales.
<n>: Un entero que indica que existen uno o más registros de rastreo del mismo catálogo de texto completo.

Por ejemplo, SQLFT0000500008.2 es el archivo de registro de rastreo de una base de datos con identificador de base de datos = 5 y con identificador de catálogo de texto completo = 8. El 2 al final del nombre de archivo indica que existen dos archivos de registro de rastreo para esta pareja de base de datos y catálogo.

Comprobar el uso de la memoria física

Durante una carga de texto completo, el proceso fdhost.exe o sqlservr.exe puede quedarse sin memoria o incluso agotarla.

Si el registro de rastreo en texto completo muestra que fdhost.exe se reinicia con frecuencia o devuelve código de error 8007008, significa que uno de estos procesos se está quedando sin memoria.
Si fdhost.exe genera volcados de memoria, especialmente en sistemas grandes y multinúcleo, es posible que se esté quedando sin memoria.
Para obtener información sobre los búferes de memoria utilizados por un rastreo de texto completo, vea sys.dm_fts_memory_buffers.

Las posibles causas de problemas de baja memoria o falta de memoria incluyen los siguientes elementos:

Memoria insuficiente. Si la cantidad de memoria física disponible durante una población completa es cero, el pool de búfer del Motor de base de datos podría estar consumiendo la mayor parte de la memoria física del sistema.

El proceso sqlservr.exe intenta obtener toda la memoria disponible para el grupo de búferes hasta el valor máximo de memoria del servidor configurado. Si la asignación de max server memory es demasiado grande, pueden producirse situaciones de falta de memoria y la imposibilidad de asignar memoria compartida para el proceso fdhost.exe.

Establece el max server memory valor del pool de buffers de Motor de base de datos adecuadamente para resolver este problema. Para obtener más información, consulta Calcular los requisitos de memoria del proceso del host del demonio de filtrado (fdhost.exe), más adelante en este artículo. Reducir el tamaño del lote utilizado para indexar texto completo también podría ayudar.
Contención de memoria. Durante una carga de texto completo en un sistema multinúcleo, fdhost.exe y sqlservr.exe pueden competir por la memoria del grupo de búferes. La consiguiente falta de memoria compartida provoca reintentos de lotes, sobrecarga de memoria y volcados de memoria por parte del proceso fdhost.exe.
Problemas de paginación. Un tamaño insuficiente del archivo de paginación, como en un sistema con un archivo de paginación pequeño y con crecimiento restringido, también puede hacer que el proceso fdhost.exe o sqlservr.exe se quede sin memoria. Si los registros de rastreo no indican fallos relacionados con la memoria, es probable que un paginado excesivo esté causando un rendimiento lento.

Calcule los requisitos de memoria del proceso host del demonio de filtrado (`fdhost.exe`)

La cantidad de memoria que el fdhost.exe proceso necesita para poblar depende principalmente del número de rangos de rastreo de texto completo que utiliza, el tamaño de la memoria compartida entrante (ISM) y el número máximo de instancias ISM.

Puedes estimar aproximadamente el consumo de memoria del equipo que aloja el demonio de filtrado mediante la siguiente fórmula:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

Los valores por defecto para las variables en la fórmula anterior son los siguientes:

Variable	Valor predeterminado
number_of_crawl_ranges	Número de núcleos de CPU
ism_size	1 MB para equipos x86 4 MB, 8 MB o 16 MB para ordenadores x64, dependiendo de la memoria física total
max_outstanding_isms	25 para equipos x86 5 para equipos x64

La siguiente tabla presenta directrices para estimar los requisitos de memoria de fdhost.exe. En las fórmulas de esta tabla se usan los valores siguientes:

F, que es una estimación de la memoria necesaria por fdhost.exe (en MB).
T, que es la memoria física total disponible en el sistema (en MB).
M, que es el ajuste óptimo max server memory .

Para información esencial sobre las fórmulas siguientes, vea las notas que siguen a la tabla.

Plataforma	Estimar `fdhost.exe` los requisitos de memoria en MB: F^1	Fórmula para calcular la memoria máxima del servidor: M^2
x86	F = Número de intervalos de rastreo * 50	M = mínimo(T, 2000) - F - 500
x64	F = Número de intervalos de rastreo * 10 * 8	M = T - F - 500

Si hay varias poblaciones completas en curso, calcula los fdhost.exe requisitos de memoria de cada uno por separado, como F1, F2, y así sucesivamente. A continuación, calcula M como T - Σ(Fi).
500 MB es un cálculo de la memoria requerida por otros procesos en el sistema. Si el sistema está realizando trabajo adicional, aumente este valor en consecuencia.
ism_size se supone que es de 8 MB para plataformas x64.

Ejemplo: Estimar los requisitos de memoria de `fdhost.exe`

Este ejemplo es para un ordenador de 64 bits que tiene 8 GB de RAM y 4 procesadores de doble núcleo. El primer cálculo estima la memoria necesaria para fdhost.exeF. El número de rangos de arrastre es 8.

F = 8 * 10 * 8 = 640

El siguiente cálculo obtiene el valor óptimo para max server memory (M). La memoria física total disponible en este sistema en MB, (T), es 8192.

M = 8192 - 640 - 500 = 7052

Ejemplo: Set `max server memory`

Este ejemplo utiliza las sentencias sp_configure y RECONFIGURE Transact-SQL para establecer max server memory el valor calculado para M en el ejemplo anterior, 7052:

USE master;
GO

EXECUTE sp_configure 'max server memory', 7052;
GO

RECONFIGURE;
GO

Para más información sobre las opciones de memoria del servidor, consulte opciones de configuración de memoria del servidor.

Comprobar el uso de CPU

El rendimiento de poblaciones completas no es óptimo cuando el consumo medio de CPU es inferior a alrededor del 30 por ciento. Aquí se discuten algunos factores que afectan al consumo de CPU.

Tiempo de espera alto para las páginas

Para averiguar si un tiempo de espera de página es alto, ejecute la siguiente instrucción de Transact-SQL:

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

La siguiente tabla describe los tipos de espera relevantes.

Tipo de espera	Descripción	Solución posible:
`PAGEIO_LATCH_SH` (`_EX` o `_UP`)	Este tipo de espera podría indicar un cuello de botella de E/S; en tal caso, normalmente también se observa una longitud media elevada de la cola de disco.	Mover el índice de texto completo a otro grupo de archivos en otro disco podría ayudar a reducir el cuello de botella de E/S.
`PAGELATCH_EX` (o `_UP`)	Este tipo de espera podría indicar una gran contienda entre subprocesos que intentan escribir en el mismo archivo de base de datos.	Añadir archivos al grupo de archivos donde reside el índice de texto completo podría ayudar a aliviar esa controversia.

Para obtener más información, consulte sys.dm_os_wait_stats.

Ineficiencias en la exploración de la tabla base

Un rellenado completo examina la tabla base para generar lotes. Este escaneo de tablas podría ser ineficiente en los siguientes escenarios:
- Si la tabla base tiene un alto porcentaje de columnas fuera de fila que se están indexando de texto completo, examinar la tabla base para generar lotes podría ser el cuello de botella. En este caso, mover los datos más pequeños en línea usando varchar(max) o nvarchar(max) podría ayudar.
- Si la tabla base está muy fragmentada, la exploración podría resultar ineficiente. Para información sobre el cálculo de datos fuera de fila y fragmentación de índices, véase sys.dm_db_partition_stats y sys.dm_db_index_physical_stats.
  
  Para reducir la fragmentación, puede reorganizar o recrear el índice agrupado. Para más información, consulte Optimización del mantenimiento de índices para mejorar el rendimiento de las consultas y reducir el consumo de recursos.

Solucionar problemas de indización lenta de documentos

Nota:

En esta sección se describe un problema que solo afecta a los clientes que indizan documentos (como documentos de Microsoft Word) en los que están insertados otros tipos de documento.

El motor de texto completo usa dos tipos de filtros cuando rellena un índice de texto completo: filtros multiproceso y filtros de un solo subproceso.

Algunos documentos, como los de Word, utilizan filtros multihilo.
Otros documentos, como Adobe Acrobat Portable Document Format (PDF), utilizan filtros de hilo único.

Por motivos de seguridad, los procesos del host del demonio de filtro cargan los filtros. Una instancia del servidor utiliza un proceso multiproceso para todos los filtros multiproceso y un proceso de un solo subproceso para todos los filtros de un solo subproceso. Cuando un documento que utiliza un filtro multiproceso contiene un documento incrustado que utiliza un filtro de un solo subproceso, el motor de texto completo inicia un proceso de un solo subproceso para el documento incrustado. Por ejemplo, al encontrar un documento de Word que contiene un documento PDF, el motor de texto completo usa el proceso multiproceso para el contenido de Word e inicia un proceso de un solo subproceso para el contenido PDF. Sin embargo, un filtro de hilo único podría no funcionar bien en este entorno y desestabilizar el proceso de filtrado.

En ciertas circunstancias en las que dicha incrustación es habitual, la inestabilidad resultante podría provocar fallos del proceso. Cuando ocurre esta condición, el Full-Text Engine redirige cualquier documento fallido (por ejemplo, un documento Word que contiene contenido PDF incrustado) al proceso de filtrado de hilo único. Si esto sucede con frecuencia, se produce una disminución del rendimiento del proceso de indización de texto completo.

Para solucionar este problema, marca el filtro del documento contenedor (el documento de Word, en este ejemplo) como un filtro de hilo único. Para marcar un filtro como filtro de un solo hilo, se establece el ThreadingModel valor del registro del filtro en Apartment Threaded. Para obtener información sobre los apartamentos de un solo subproceso, consulte Comprensión y uso de los modelos de subprocesos COM.

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-07-21