Ajuste de desempenho e otimização de índices de texto completo

Durante uma população de texto completo, é possível que o fdhost.exe ou o sqlservr.exe fique com pouca memória não tenha memória suficiente. Se o log de rastreamento de texto completo mostrar que fdhost.exe está sendo reiniciado com frequência ou que o código de erro 8007008 está sendo retornado, isso indica que um desses processos está sendo executado sem memória. Se fdhost.exe estiver gerando despejos, principalmente em computadores grandes com várias CPUs, talvez ele esteja ficando com memória insuficiente.

Observação
Para obter informações sobre buffers de memória usados por um rastreamento de texto completo, consulte sys.dm_fts_memory_buffers (Transact-SQL).

As causas possíveis são as seguintes:

• Se a quantidade de memória física disponível durante uma população completa for zero, o pool de buffers do SQL Server talvez esteja 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 de memória máxima do servidor for muito grande, condições de memória insuficiente e falha para alocar memória compartilhada poderão ocorrer para o processo do fdhost.exe.

  Observação
  Durante uma população de texto completo em um computador com várias CPUs, como um computador de IA64 de 64 bits, pode ocorrer contenção da memória do pool de buffers entre fdhost.exe ou sqlservr.exe. A memória compartilhada insuficiente resultante provoca tentativas em lote, sobrecarga de memória e despejos do processo do fdhost.exe.

  Para resolver esse problema, defina o valor max server memory do pool de buffers do SQL Server adequadamente. Para obter mais informações, consulte "Estimando os requisitos de memória do processo do host do daemon de filtro (fdhost.exe)", posteriormente neste tópico. A redução do tamanho do lote usado para indexação de texto completo pode ajudar.

• Um problema de paginação

  O tamanho insuficiente do arquivo de paginação, como em um sistema que tem um arquivo de paginação pequeno com crescimento restrito, também pode fazer com que o fdhost.exe ou o sqlservr.exe fique com memória insuficiente.

  Se os logs de rastreamento não indicarem nenhuma falha relacionada à memória, é provável que o desempenho esteja lento devido a excesso de paginação.

Estimando os requisitos de memória da memória compartilhada de saída do processo do host do daemon de filtro (fdhost.exe)

A quantidade de memória necessária para o processo do fdhost.exe para uma população depende principalmente do número de intervalos de rastreamento de texto completo que ele usa, do tamanho da ISM (memória compartilhada de entrada) e do número de máximo de instâncias da ISM.

A quantidade de memória consumida (em bytes) pelo host do daemon de filtro pode ser estimada aproximadamente usando a fórmula a seguir:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

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

Variável	Valor padrão
number_of_crawl_ranges	O número de CPUs
ism_size	1 MB para computadores x86 4 MB, 8 MB ou 16MB 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 sobre como estimar as necessidades de memória do fdhost.exe. As fórmulas desta tabela usam os seguintes valores:

• F, que é uma estimativa da memória necessária para 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 de max server memory.

Importante
Para obter informações essenciais sobre as fórmulas, consulte 1, 2e 3, abaixo.

Plataforma	Estimando as necessidades de memória do fdhost.exe em MB — F1	Fórmula para calcular a memória máxima do servidor — M2
x86 com AWE desabilitado	F=Number of crawl ranges* 50	M=minimum(T, 2000)–F– 500
x86 com AWE habilitado	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 Se houver várias populações completas em andamento, calcule os requisitos de memória de fdhost.exe de cada uma separadamente, como F1, F2 e assim por diante. Em seguida, calcule M como T**–** sigma**(Fi)**.

2 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.

3 .ism_size é presumido como 8 MB para plataformas x64.

Exemplo: Estimando as necessidades de memória do fdhost.exe

Este exemplo é para um computador AMD64 com 8 GB de RAM e 4 processadores de núcleo dual. O primeiro cálculo estima a memória necessária para fdhost.exe — F. O número de intervalos de rastreamento é 8.

F = 8*10*8=640

O próximo cálculo obtém o valor ideal para memória máxima do servidor — M. T O total de memória física disponível neste sistema, em MB — T — é 8192.

M = 8192-640-500=7052

Exemplo: Definindo a configuração max server memory

Este exemplo usa as instruções Transact-SQLsp_configure e RECONFIGURE para definir a memória máxima do servidor com o valor calculado para M no exemplo anterior, 7052:

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

Para definir a opção de configuração da memória máxima do servidor

• Opções de memória do servidor

• Como exibir ou alterar as propriedades do servidor (SQL Server Configuration Manager)

• Como definir uma quantidade fixa de memória (SQL Server Management Studio)

Esperamos que o desempenho das populações completas não seja o ideal quando a média de consumo da CPU for inferior a cerca de 30%. Esta seção discute alguns fatores que afetam o consumo da CPU.

• Alta espera por páginas

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

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

  A tabela a seguir descreve os tipos de espera de interesse aqui mencionados.

  Tipo de espera	Descrição	Solução possível
  PAGEIO_LATCH_SH (_EX ou _UP)	Isso pode indicar um gargalo de E/S, caso em que normalmente você também observa um comprimento médio da fila de disco alto.	Mover o índice de texto completo para outro grupo de arquivos em outro disco pode ajudar a reduzir o gargalo de E/S.
  PAGELATCH_EX (ou _UP)	Isso pode indicar muita contenção entre os threads que estão tentando para gravar no mesmo arquivo de banco de dados.	Adicionar arquivos ao grupo de arquivos em que reside o índice de texto completo pode ajudar a aliviar essa contenção.

  Para obter mais informações, consulte sys.dm_os_wait_stats (Transact-SQL).

• Ineficiências ao examinar a tabela base

  Uma população completa examina a tabela base para gerar lotes. Esse exame da tabela pode ser ineficiente nos seguintes cenários:

  • Se a tabela base tem uma porcentagem alta de colunas fora de linha que estão sendo indexadas com texto completo, examinar a tabela base para gerar lotes pode ser o gargalo. Nesse caso, pode ser útil mover os dados menores em linha usando varchar(max) ou nvarchar(max).

  • Se a tabela base estiver muito fragmentada, o exame poderá ser ineficiente. Para obter informações sobre como calcular dados fora de linha e fragmentação de índices, consulte sys.dm_db_partition_stats (Transact-SQL) e sys.dm_db_index_physical_stats (Transact-SQL).

    Para reduzir a fragmentação, você pode reorganizar ou recriar o índice clusterizado. Para obter mais informações, consulte Reorganizando e recriando índices.