Melhorar o desempenho dos índices em texto completo

Aplica-se a:SQL Server Banco de Dados SQL do Azure Instância Gerenciada de SQL do Azure

Este artigo aborda as causas comuns de baixo desempenho em índices e consultas em texto completo, e como mitigá-las.

Causas comuns para problemas de desempenho

Esta seção descreve as causas de problemas comuns de desempenho ao usar índices em texto completo.

Problemas de recursos de hardware

Recursos de hardware como memória, velocidade do disco, velocidade da CPU e arquitetura da máquina afetam o desempenho da indexação e das consultas em texto completo.

Limites de recursos de hardware causam redução no desempenho da indexação de texto completo.

CPU. Se o uso da CPU pelo processo host do daemon do filtro (fdhost.exe) ou pelo processo do SQL Server (sqlservr.exe) estiver próximo de 100%, a CPU é o gargalo.
Memory. A falta de memória física pode causar um gargalo.
Disco. Se o comprimento médio da fila de espera do disco for mais do que duas vezes o número de cabeças de disco, há um gargalo no disco. A principal solução alternativa é criar catálogos de texto completo separados dos arquivos e logs de banco de dados do SQL Server. Coloque os logs, arquivos de banco de dados e catálogos de texto completo em discos separados. Instalar discos mais rápidos e usar RAID também pode ajudar a melhorar desempenho de indexação.

Problemas de processamento em lote de texto integral

Se o sistema não possui gargalos de hardware, o desempenho de indexação da busca em texto completo depende principalmente dos seguintes fatores:

Quanto tempo o Mecanismo de Banco de Dados leva para criar lotes em texto completo.
A rapidez com que o daemon de filtro consome esses lotes.

Problemas de preenchimento do índice de texto completo

Tipo de população. Ao contrário do preenchimento completo, o preenchimento de controle de alterações incremental, manual e automático não foi desenvolvido para maximizar os recursos de hardware a fim de obter maior velocidade. Portanto, as sugestões de ajustes neste artigo talvez não melhorem o desempenho de indexação de texto completo ao usar população de acompanhamento de alteração incremental, manual ou automática.
Mesclagem principal. Quando uma população termina, um processo final de fusão reúne os fragmentos do índice em um único índice mestre de texto completo. Esse processo resulta em melhor desempenho das consultas, já que apenas o índice mestre precisa ser consultado e não um número de fragmentos de índice. Estatísticas de pontuação melhores podem ser usadas para o ranking de relevância. No entanto, a mescagem mestre pode ser intensiva em I/O porque grandes quantidades de dados precisam ser escritas e lidas quando fragmentos de índice são mesclados. No entanto, ele não bloqueia consultas recebidas.

A mesclagem mestra de um grande volume de dados pode criar uma transação demorada, atrasando o truncamento do log de transações durante o ponto de verificação. Nesse caso, no modelo de recuperação completa, o log de transações pode crescer significativamente. Como prática recomendada, antes de reorganizar um índice de texto completo grande em um banco de dados que usa o modelo de recuperação completa, verifique se o log de transações contém espaço suficiente para uma transação demorada. Para obter mais informações, consulte Gerenciar o tamanho do arquivo de log de transações.

Ajustar o desempenho de índices de texto completo

Para maximizar o desempenho de seus índices de texto completo, implemente as seguintes práticas recomendadas:

Para usar todos os núcleos de CPU ao máximo, mude max full-text crawl range o número de núcleos no sistema. Para mais informações, veja configuração do servidor: alcance máximo de rastreamento de texto completo.
Verifique se a tabela base tem um índice clusterizado. Use um tipo de dados integer para a primeira coluna do índice clusterizado. Evite usar GUIDs na primeira coluna do índice clusterizado. Uma população de vários intervalos em um índice clusterizado pode gerar a maior velocidade de população. Use um tipo de dado inteiro para a coluna que serve como chave de texto completo.
Atualize as estatísticas da tabela base usando a instrução UPDATE STATISTICS . E, o mais importante, atualize as estatísticas no índice clusterizado ou na chave de texto completo para uma população completa. Essa ação ajuda um preenchimento de vários intervalos a gerar boas partições na tabela.
Antes de realizar uma população completa em um computador grande com vários núcleos, limite temporariamente o tamanho do pool de buffers definindo o valor de max server memory para reservar memória suficiente para o processo fdhost.exe e para o sistema operacional. Para mais informações, veja Estimar os requisitos de memória do processo host do daemon do filtro (fdhost.exe), mais adiante neste artigo.
Se você usar o preenchimento incremental com base em uma coluna de carimbo de data/hora, crie um índice secundário da coluna timestamp para aprimorar o desempenho do preenchimento incremental.

Solucionar problemas de desempenho das populações completas

Consulte a seção a seguir para resolver problemas de desempenho com populações completas.

Examine os logs de rastreamento de texto completo

Para ajudar a diagnosticar problemas de desempenho, revise os registros de rastreamento em texto completo.

Quando ocorre um erro durante um rastreamento, a funcionalidade de registro de rastreamento da Pesquisa de Texto Completo cria e mantém um log de rastreamento, que é um arquivo de texto sem formatação. Cada log de rastreamento corresponde a um catálogo de texto completo específico. Por padrão, os logs de rastreamento para uma determinada instância (no exemplo, a instância padrão) estão localizados na pasta %ProgramFiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\LOG.

O arquivo de log de rastreamento segue o seguinte padrão de nomenclatura:

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

As partes variáveis do nome do arquivo de log de rastreamento são as seguintes.

<DatabaseID>: O ID de um banco de dados, na forma de um número de cinco dígitos com zeros à esquerda.
<FullTextCatalogID>: ID do catálogo de texto completo, na forma de um número de cinco dígitos com zeros à esquerda.
<n>: um inteiro que indica um ou mais logs de rastreamento que existem do mesmo catálogo de texto completo.

Por exemplo, SQLFT0000500008.2 é o arquivo de log de rastreamento de um banco de dados com a ID de banco de dados = 5 e a ID de catálogo de texto completo = 8. O 2 no final do nome do arquivo indica que há dois arquivos de log de rastreamento para esse par de banco de dados/catálogo.

Verificar uso de memória física

Durante um preenchimento de texto completo, o processo fdhost.exe ou sqlservr.exe pode ficar com pouca memória, ou até mesmo esgotar a memória.

Se o registro de rastreamento em texto completo mostrar que fdhost.exe reinicia com frequência ou retorna código de erro 8007008, significa que um desses processos está ficando sem memória.
Se fdhost.exe gerar despejos, principalmente em sistemas de vários núcleos, talvez ele esteja ficando sem memória.
Para informações sobre buffers de memória usados em um crawl de texto completo, veja sys.dm_fts_memory_buffers.

As possíveis causas de baixa memória ou problemas de falta de memória incluem os seguintes itens:

Memória insuficiente. Se a quantidade de memória física disponível durante uma população completa for zero, o pool de buffer do Mecanismo de Banco de Dados pode estar consumindo a maior parte da memória física do sistema.

O processo do sqlservr.exe tenta obter toda a memória disponível para o pool de buffers, até a memória máxima configurada para o servidor. Se a alocação max server memory for muito grande, condições de memória insuficiente e falhas na alocação de memória compartilhada podem ocorrer no processo fdhost.exe.

Defina o max server memory valor do pool de buffers do Mecanismo de Banco de Dados adequadamente para resolver esse problema. Para mais informações, veja Estimar os requisitos de memória do processo host do daemon do filtro (fdhost.exe), mais adiante neste artigo. Reduzir o tamanho do lote usado para indexação de texto completo também pode ajudar.
Contenção de memória. Durante um preenchimento de texto completo em um sistema com vários núcleos, fdhost.exe e sqlservr.exe podem disputar a memória do pool de buffers. A memória compartilhada insuficiente resultante provoca tentativas em lote, sobrecarga de memória e despejos do processo do fdhost.exe.
Problemas de paginação. Um tamanho insuficiente do arquivo de paginação, como em um sistema que possui um arquivo de paginação pequeno com crescimento restrito, também pode fazer com que o processo fdhost.exe ou sqlservr.exe fique sem memória. Se os registros de rastreamento não indicarem falhas relacionadas à memória, o excesso de paginação provavelmente estará causando desempenho lento.

Estimar os requisitos de memória do processo hospedeiro do daemon de filtro (`fdhost.exe`)

A quantidade de memória que o fdhost.exe processo precisa para preencher depende principalmente do número de intervalos de rastreamento de texto completo que utiliza, do tamanho da memória compartilhada de entrada (ISM) e do número máximo de instâncias de ISM.

Você pode estimar aproximadamente o consumo de memória do host do demônio filtro usando a seguinte fórmula:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

Os valores padrão para as variáveis na fórmula anterior são os seguintes:

Variável	Valor padrão
número de intervalos de rastreamento	O número de núcleos de CPU
ism_size	1 MB para computadores x86 4 MB, 8 MB ou 16 MB para computadores x64, dependendo da memória física total
max_outstanding_isms	25 MB para computadores x86 5 MB para computadores x64

A tabela a seguir apresenta diretrizes para estimar os requisitos de memória de fdhost.exe. As fórmulas desta tabela usam os seguintes valores:

F, que é uma estimativa da memória necessária por fdhost.exe (em MB).
T, que é o total de memória física disponível no sistema (em MB).
M, que é a configuração ideal max server memory .

Para obter informações essenciais sobre as fórmulas a seguir, consulte as notas que seguem a tabela.

Plataforma	Estimar `fdhost.exe` os requisitos de memória em MB: F^1	Fórmula para calcular a memória máxima do servidor: M^2
x86	F = Número de intervalos de rastreamento * 50	M = mínimo (T, 2000) - F - 500
x64	F = Número de intervalos de rastreamento * 10 * 8	M = T - F – 500

Se várias populações completas estiverem em andamento, calcule os fdhost.exe requisitos de memória de cada um separadamente, como F1, F2, e assim por diante. Depois, calcule M como T - Σ(Fi).
500 MB é uma estimativa da memória exigida por outros processos no sistema. Se o sistema estiver executando trabalho adicional, aumente esse valor de maneira correspondente.
ism_size supõe-se que seja de 8 MB para plataformas x64.

Exemplo: Estimar os requisitos de memória de `fdhost.exe`

Este exemplo é para um computador de 64 bits que possui 8 GB de RAM e 4 processadores dual-core. O primeiro cálculo estima a memória necessária para fdhost.exeF. O número de intervalos de rastreamento é 8.

F = 8 * 10 * 8 = 640

O próximo cálculo obtém o valor ótimo para max server memory (M). A memória física total disponível neste sistema em MB, (T), é 8192.

M = 8192 - 640 - 500 = 7052

Exemplo: Set `max server memory`

Este exemplo usa as instruções sp_configure e RECONFIGURE Transact-SQL para definir max server memory para o valor calculado para M no exemplo anterior, 7052:

USE master;
GO

EXECUTE sp_configure 'max server memory', 7052;
GO

RECONFIGURE;
GO

Para mais informações sobre as opções de memória do servidor, veja Opções de configuração da memória do servidor.

Verificar uso de CPU

O desempenho de populações completas não é ideal quando o consumo médio de CPU é menor que cerca de 30%. Esta seção discute alguns fatores que afetam o consumo da CPU.

Tempo de espera alto para páginas

Para saber se o tempo de espera de uma página é alto, execute a seguinte instrução Transact-SQL:

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

A tabela a seguir descreve os tipos de espera relevantes.

Tipo de espera	Descrição	Solução possível
`PAGEIO_LATCH_SH` (`_EX` ou `_UP`)	Esse tipo de espera pode indicar um gargalo de E/S; nesse caso, normalmente também se observa um comprimento médio da fila de disco elevado.	Mover o índice de texto completo para outro grupo de arquivos em um disco diferente pode ajudar a reduzir o gargalo de I/O.
`PAGELATCH_EX` (ou `_UP`)	Esse tipo de espera pode indicar muita contenda entre threads que estão tentando escrever no mesmo arquivo de banco de dados.	Adicionar arquivos ao grupo onde o índice de texto completo reside pode ajudar a aliviar essa contenção.

Para obter mais informações, confira sys.dm_os_wait_stats.

Ineficiências ao examinar a tabela base

Uma população completa examina a tabela base para gerar lotes. Essa varredura de tabela pode ser ineficiente nos seguintes cenários:
- Se a tabela base tem um percentual alto de colunas fora de linha que estão sendo indexadas com texto completo, a varredura da tabela base para gerar lotes pode ser o gargalo. Nesse caso, mover os dados menores para dentro da linha usando varchar(max) ou nvarchar(max) pode ajudar.
- Se a tabela base estiver muito fragmentada, a varredura poderá ser ineficiente. Para obter informações sobre o cálculo dos dados armazenados fora da linha e a fragmentação de índices, consulte sys.dm_db_partition_stats e sys.dm_db_index_physical_stats.
  
  Para reduzir a fragmentação, você pode reorganizar ou recriar o índice clusterizado. Para obter mais informações, consulte Otimizar a manutenção do índice para melhorar o desempenho da consulta e reduzir o consumo de recursos.

Solucionar problemas de indexação lenta de documentos

Observação

Esta seção descreve um problema que afeta somente os clientes que indexam documentos (como documentos do Microsoft Word) no quais outros tipos de documentos são inseridos.

O mecanismo de texto completo usa dois tipos de filtros ao preencher um índice de texto completo: filtros multithread e thread único.

Alguns documentos, como documentos do Word, usam filtros com várias threads.
Outros documentos, como documentos em PDF (Adobe Acrobat Portable Document Format), use filtros com thread única.

Por razões de segurança, os filtros são carregados por processos de host do daemon de filtro. Uma instância de servidor usa um processo multi-threaded para todos os filtros multi-threaded e um processo single-threaded para todos os filtros single-threaded. Quando um documento que usa um filtro multithread contém um documento incorporado que usa um filtro de thread único, o mecanismo de texto completo inicia um processo de thread único para o documento incorporado. Por exemplo, ao encontrar um documento do Word que contém um documento em PDF, o mecanismo de texto completo usa o processo multithread para o conteúdo do Word e inicia um processo de thread único para o conteúdo do PDF. No entanto, um filtro de rosca única pode não funcionar bem nesse ambiente e pode desestabilizar o processo de filtragem.

Em determinadas circunstâncias em que o processo de incorporação é comum, a desestabilização pode causar o travamento do processo. Quando essa condição ocorrer, o mecanismo de texto completo refaz a rota do documento que falhou (por exemplo, um documento do Word que contém um conteúdo em PDF incorporado) para o processo de filtragem em thread única. Se o redirecionamento ocorrer com frequência, haverá degradação no desempenho do processo de indexação de texto completo.

Para solucionar esse problema, marque o filtro para o documento de contêiner (neste caso, o Word) como filtro de thread única. Para marcar um filtro como filtro de thread único, defina o valor de Registro ThreadingModel para o filtro como Apartment Threaded. Para obter informações sobre single-threaded apartments, consulte Noções básicas e uso dos modelos de threading COM.

Comentários

Esta página foi útil?

Last updated on 2026-07-21