Ajuste y optimización del rendimiento de los índices de texto completo
El rendimiento de la indización y las búsquedas de texto completo se ve afectado por los recursos de hardware; por ejemplo, la memoria, la velocidad de disco y de CPU, y la arquitectura del equipo. La causa principal de un rendimiento reducido de la indización de texto completo son los límites de los recursos de hardware:
Si el uso de la CPU que hace el proceso de host de demonio de filtro (fdhost.exe) o el proceso de SQL Server (sqlservr.exe) está cercano al 100 por ciento, la CPU es el cuello de botella.
Si la longitud promedio de la cola de espera del disco es superior al doble del número de cabezales de disco, el cuello de botella está 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 adquisición de discos más rápidos y el uso de RAID.
Si hay escasez de memoria física (límite de 3 GB), la memoria podría ser el cuello de botella. Las limitaciones de la memoria física son posibles en todos los sistemas y, en los sistemas de 32 bits, la presión de memoria virtual puede ralentizar la indización de texto completo.
Nota
A partir de SQL Server 2008, el motor de texto completo puede utilizar la memoria AWE porque forma parte de sqlservr.exe.
Si el sistema no tiene cuellos de botella de hardware, el rendimiento de la indización de la búsqueda de texto completo depende sobre todo de lo siguiente:
El tiempo que tarda SQL Server en crear lotes de texto completo.
La rapidez con la que el denomino de filtro puede consumir dichos lotes.
Nota
A diferencia del rellenado completo, el rellenado incremental, manual y de seguimiento automático de cambios no se han diseñado para obtener los máximos recursos de hardware y así aumentar la velocidad. Por ello, estas sugerencias para el ajuste podrían no mejorar el rendimiento de la indización de texto completo.
Cuando se completa un rellenado, se desencadena un proceso de combinación final que combina los fragmentos de índice en un solo índice de texto completo maestro. Esto permite mejorar el rendimiento de las consultas, ya que únicamente es necesario realizar consultas en el índice maestro, en lugar de hacerlo en varios fragmentos de índice, y se pueden utilizar mejores estadísticas de puntuación para obtener la clasificación por relevancia. Tenga en cuenta que la combinación maestra puede requerir un uso intensivo de E/S, ya que es necesario escribir y leer una gran cantidad de datos cuando se combinan los fragmentos de índice, aunque esto no bloquea las consultas entrantes.
.gif "Nota importante") Importante |
|---|
La combinación maestra de una cantidad grande de datos puede crear una transacción de larga duración, con lo que se retrasa el truncamiento del registro de transacciones durante el punto de comprobación. 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, vea Administrar el tamaño del archivo de registro de transacciones. |
Ajustar 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 utilizar todos los procesadores o núcleos al máximo, establezca sp_configure 'max full-text crawl ranges' en el número de CPU del sistema. Para obtener información sobre esta opción de configuración, vea max full-text crawl range (opción).
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. No use GUID en la primera columna del índice clúster. Un rellenado de varios intervalos en un índice clúster puede conseguir que el rellenado se realice a la mayor velocidad. Recomendamos que la columna que actúa como clave de texto completo sea de un tipo de datos entero.
Actualice las estadísticas de la tabla base mediante la instrucción UPDATE STATISTICS. Es muy importante que actualice las estadísticas del índice clúster o la clave de texto completo para un rellenado completo. De este modo se ayuda a que un rellenado de varios intervalos genere bien las particiones de la tabla.
Cree un índice secundario en una columna timestamp si desea mejorar el rendimiento del rellenado incremental.
Antes de realizar un rellenado completo en un equipo grande con varias CPU, es recomendable que limite temporalmente el tamaño del grupo de búferes estableciendo el valor max server memory a fin de dejar suficiente memoria para el uso del sistema operativo y el proceso fdhost.exe. Para obtener más información, vea "Estimar los requisitos de memoria del proceso de host de demonio de filtro (fdhost.exe)" más adelante en este tema.
Solucionar problemas de rendimiento de los rellenados completos
Para diagnosticar problemas de rendimiento, examine los registros de rastreo de texto completo. Para obtener información acerca de los registros de rastreo, vea Solucionar errores en un rellenado de texto completo (rastreo).
Es recomendable que se siga el orden que se indica a continuación a la hora de solucionar los problemas si el rendimiento de los rellenados completos no es satisfactorio.
Uso de la memoria física
Durante un rellenado de texto completo, es posible que fdhost.exe o sqlservr.exe no dispongan de suficiente memoria o se queden sin memoria. Si el registro de rastreo de texto completo muestra que fdhost.exe se reinicia con frecuencia o que se devuelve el código de error 8007008, significa que uno de estos procesos se está quedando sin memoria. Si fdhost.exe produce volcados, especialmente en equipos grandes con varias CPU, es posible que se esté quedando sin memoria.
Nota
Para obtener información acerca de los búferes de memoria utilizados por un rastreo de texto completo, vea sys.dm_fts_memory_buffers (Transact-SQL).
Las causas posibles son las siguientes:
Si la cantidad de memoria física que está disponible durante un rellenado completo es cero, el grupo de búferes de SQL Server 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 condiciones de memoria insuficiente y errores para asignar memoria compartida al proceso fdhost.exe.
Nota
Durante un rellenado de texto completo en un equipo con varias CPU, como un equipo IA64 de 64 bits, puede producirse una contención de la memoria del grupo de búferes entre fdhost.exe o sqlservr.exe. La falta de memoria compartida resultante produce reintentos de lotes, una paginación excesiva de la memoria y volcados por parte del proceso fdhost.exe.
Puede resolver este problema estableciendo apropiadamente el valor max server memory del grupo de búferes de SQL Server. Para obtener más información, vea "Estimar los requisitos de memoria del proceso de host de demonio de filtro (fdhost.exe)" más adelante en este tema. Reducir el tamaño de lote utilizado para la indización de texto completo también puede ayudar.
Un problema de paginación
Un tamaño insuficiente del archivo de paginación, como ocurre en un sistema que tiene un archivo de paginación pequeño con un crecimiento restringido, también puede hacer que fdhost.exe o sqlservr.exe se queden sin memoria.
Si los registros de rastreo no indican ningún error relacionado con la memoria, es probable que el rendimiento sea lento debido a una paginación excesiva.
Estimar los requisitos de memoria del proceso de host de demonio de filtro (fdhost.exe)
La cantidad de memoria requerida por el proceso fdhost.exe para un rellenado depende principalmente del número de intervalos de rastreo de texto completo que utiliza, del tamaño de la memoria compartida entrante (ISM) y del número máximo de instancias de ISM.
La cantidad de memoria (en bytes) consumida por el host de demonio de filtro puede calcularse de forma aproximada utilizando esta fórmula:
number_of_crawl_ranges * ism_size * max_outstanding_isms * 2
Los valores predeterminados de las variables de la fórmula anterior son los siguientes:
Variable |
Valor predeterminado |
|---|---|
number_of_crawl_ranges |
Número de CPU |
ism_size |
1 MB para equipos x86 4 MB, 8 MB o 16MB para equipos x64, en función de la memoria física total |
max_outstanding_isms |
25 para equipos x86 5 para equipos x64 |
En la tabla siguiente se muestran instrucciones sobre cómo evaluar los requisitos de memoria de fdhost.exe. En las fórmulas de esta tabla se usan los valores siguientes:
F, que es un cálculo de la memoria que fdhost.exe necesita (en MB).
T, que es la memoria física total disponible en el sistema (en MB).
M, que es el valor de max server memory óptimo.
| Importante |
|---|
Para obtener información básica sobre las fórmulas, vea 1, 2 y 3, a continuación. |
Plataforma |
Evaluar los requisitos de memoria de fdhost.exe en MB (F1) |
Fórmula para calcular max server memory (M2) |
|---|---|---|
x86 con AWE deshabilitado |
F=Number of crawl ranges* 50 |
M=minimum(T, 2000)–F– 500 |
x86 con AWE habilitado |
F=Number of crawl ranges* 50 |
M=T–F– 500 |
x64 o IA643 |
F=Number of crawl ranges* 10 * 8 |
M=T–F– 500 |
1 Si hay varios rellenados completos en curso, calcule los requisitos de memoria de fdhost.exe de cada uno por separado, como F1, F2, etc. A continuación, calcule M como T**–** sigma**(Fi)**.
2 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.
3 .ism_size se supone que es de 8 MB para plataformas x64.
Ejemplo: evaluar los requisitos de memoria de fdhost.exe
Este ejemplo corresponde a un equipo AMD64 que tiene 8 GB de RAM y 4 procesadores de doble núcleo. El primer cálculo evalúa la memoria que necesita fdhost.exe (F). El número de intervalos de rastreo es 8.
F = 8*10*8=640
El siguiente cálculo obtiene el valor óptimo de max server memory: M. El total de memoria física disponible en este sistema en MB (T) es 8192.
M = 8192-640-500=7052
Ejemplo: establecer max server memory
En este ejemplo se utilizan las instrucciones sp_configure y RECONFIGURE de Transact-SQL para establecer el valor de max server memory en el valor calculado para M en el ejemplo anterior, 7052:
USE master;
GO
EXEC sp_configure 'max server memory', 7052;
GO
RECONFIGURE;
GO
Para establecer la opción de configuración max server memory
Factores que pueden reducir el consumo de CPU
Es de esperar que el rendimiento de los rellenados completos no sea el óptimo cuando el consumo de CPU medio sea inferior a un 30 por ciento, aproximadamente. En esta sección se discuten algunos factores que afectan al consumo de CPU.
Una espera alta de las páginas
Para averiguar si el tiempo de espera de una página es elevado, ejecute la instrucción de Transact-SQL siguiente:
Execute SELECT TOP 10 * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC;En la tabla siguiente se describen los tipos de espera de interés aquí.
Tipo de espera
Descripción
Solución posible:
PAGEIO_LATCH_SH (_EX o _UP)
Esto podría indicar un cuello de botella de la E/S, en cuyo caso normalmente vería también una longitud promedio de la cola del disco alta.
Al mover el índice de texto completo a un grupo de archivos diferente de un disco diferente, podría ayudar a reducir el cuello de botella de la E/S.
PAGELATCH_EX (o _UP)
Podría indicar una gran contención entre los subprocesos que están intentando escribir en el mismo archivo de base de datos.
Al agregar los archivos al grupo de archivos en el que el índice de texto completo reside podría ayudar a aliviar tal contención.
Para obtener más información, vea sys.dm_os_wait_stats (Transact-SQL).
Deficiencias en el recorrido de la tabla base
Un rellenado completo examina la tabla base para generar lotes. Este recorrido de la tabla podría ser ineficaz en los escenarios siguientes:
Si la tabla base tiene un porcentaje alto de columnas sin filas que están siendo indizadas con índices de texto completo, el recorrido de la tabla base para generar los lotes podría constituir el cuello de botella. En este caso, podría ser de ayuda pasar los datos menores de la fila usando varchar(max) o nvarchar(max).
Si la tabla base está muy fragmentada, el recorrido podría ser ineficaz. Para obtener información sobre cómo calcular los datos sin filas y la fragmentación del índice, vea sys.dm_db_partition_stats (Transact-SQL) y sys.dm_db_index_physical_stats (Transact-SQL).
Para reducir la fragmentación, puede reorganizar o volver a generar el índice clúster. Para obtener más información, vea Reorganizar y volver a generar índices.
Vea también