Förbättra prestanda för Full-Text index

gäller för:SQL ServerAzure SQL Database

Det här avsnittet beskriver några av de vanligaste orsakerna till dåliga prestanda för fulltextindex och frågor. Det innehåller också några förslag för att åtgärda dessa problem och förbättra prestanda.

Vanliga orsaker till prestandaproblem

Problem med maskinvaruresurser

Prestanda för fulltextindexering och fulltextfrågor påverkas av maskinvaruresurser, till exempel minne, diskhastighet, CPU-hastighet och maskinarkitektur.

Den främsta orsaken till minskad prestanda för fulltextindexering är maskinvaruresursgränser.

• CPU-. Om processoranvändningen för filter daemon-värdprocessen (fdhost.exe) eller SQL Server-processen (sqlservr.exe) är nära 100 procent, är processorn flaskhalsen.

• Minne. Om det finns brist på fysiskt minne kan minnet vara flaskhalsen.

• Disk. Om den genomsnittliga kölängden för diskväntetid är mer än dubbelt så lång som antalet diskhuvuden, finns det en flaskhals på disken. Den primära lösningen är att skapa fulltextkataloger som är separata från SQL Server-databasfilerna och loggarna. Placera loggar, databasfiler och fulltextkataloger på separata diskar. Om du installerar snabbare diskar och använder RAID kan du också förbättra indexeringsprestandan.

  Not

  Från och med SQL Server 2008 (10.0.x) kan Full-Text Engine använda AWE-minne eftersom Full-Text Engine är en del av sqlservr.exe processen. Mer information finns i Full-Text Sökarkitektur.

Problem med batchbearbetning i fulltext

Om systemet inte har några maskinvaruflaskhalsar beror indexeringsprestandan för fulltextsökning mest på följande:

• Hur lång tid det tar för SQL Server att skapa fulltextbatch.

• Hur snabbt filterdaemonen kan använda dessa batchar.

Problem med fulltextindexpopulation

• typ av population. Till skillnad från hela populationen är inkrementell, manuell och automatisk ändringsspårning inte utformad för att maximera maskinvaruresurser för att uppnå snabbare hastighet. Därför kanske justeringsförslagen i det här avsnittet inte förbättrar prestanda för fulltextindexering när inkrementell, manuell eller automatisk ändringsspårning används.

• Primärsammanslagning. När en population har slutförts utlöses en slutlig sammanslagningsprocess som sammanfogar indexfragmenten till ett huvudindex i fulltext. Detta resulterar i bättre frågeprestanda eftersom endast huvudindexet behöver frågas i stället för ett antal indexfragment, och bättre bedömningsstatistik kan användas för relevansrankning. Huvudsammanfogningen kan dock vara I/O-intensiv eftersom stora mängder data måste skrivas och läsas när indexfragment slås samman, men det blockerar inte inkommande frågor.

  Att sammanfoga en stor mängd data kan skapa en tidskrävande transaktion, vilket fördröjer trunkeringen av transaktionsloggen under en kontrollpunkt. I det här fallet kan transaktionsloggen växa avsevärt under den fullständiga återställningsmodellen. Vi rekommenderar att du, innan du omorganiserar ett stort fulltextindex i en databas som använder den fullständiga återställningsmodellen, ser till att transaktionsloggen innehåller tillräckligt med utrymme för en tidskrävande transaktion. Mer information finns i Hantera storleken på transaktionsloggfilen.

Justera prestanda för fulltextindex

Implementera följande metodtips för att maximera prestandan för dina fulltextindex:

• Om du vill använda alla processorer eller kärnor till det maximala värdet anger du sp_configuremaximalt fulltextkrypningsintervalltill antalet processorer i systemet. Information om det här konfigurationsalternativet finns i serverkonfigurationsalternativet för maximalt fulltext-crawlningsintervall .

• Kontrollera att bas-tabellen har ett klustrat index. Använd en heltalsdatatyp för den första kolumnen i det klustrade indexet. Undvik att använda GUID:er i den första kolumnen i det klustrade indexet. En population med flera intervall i ett grupperat index kan ge den högsta befolkningshastigheten. Vi rekommenderar att kolumnen som fungerar som fulltextnyckel är en heltalsdatatyp.

• Uppdatera bastabellens statistik med hjälp av UPDATE STATISTICS-instruktionen. Ännu viktigare är att uppdatera statistiken för det klustrade indexet eller fulltextnyckeln för en fullständig population. Detta hjälper en population med flera intervall att generera bra partitioner i tabellen.

• Innan du utför en fullständig population på en stor dator med flera processorer rekommenderar vi att du tillfälligt begränsar storleken på buffertpoolen genom att ange värdet maximalt serverminne för att lämna tillräckligt med minne för fdhost.exe process- och operativsystemanvändning. Mer information finns i Beräkna minneskraven för Filter Daemon Host Process (fdhost.exe), senare i det här avsnittet.

• Om du använder inkrementell population baserat på en tidsstämpelkolumn skapar du ett sekundärt index på tidsstämpel kolumn för att förbättra prestanda för inkrementell population.

Felsöka prestanda för fullständiga populationer

Granska crawlningsloggarna i fulltext

Om du vill diagnostisera prestandaproblem kan du titta på crawlningsloggarna i fulltext.

När ett fel inträffar under en sökrobotgenomsökning skapar och underhåller Full-Text:s sökgenomsökningsloggningsfunktion en loggfil, som är en oformaterad textfil. Varje crawlningslogg motsvarar en viss fulltextkatalog. Som standard finns crawlloggar för en viss instans (i det här exemplet standardinstansen) i %ProgramFiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\LOG mapp.

Crawlningsloggfilen följer följande namngivningsschema:

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

Variabeldelarna i crawlningsloggfilens namn är följande.

• < DatabaseID> – ID för en databas. < dbid> är ett femsiffrigt tal med inledande nollor.
• < FullTextCatalogID> – katalog-ID för fulltext. < catid> är ett femsiffrigt tal med inledande nollor.
• < n> – Är ett heltal som anger att det finns en eller flera crawlningsloggar i samma fulltextkatalog.

Till exempel är SQLFT0000500008.2 crawlningsloggfilen för en databas med databas-ID = 5 och fulltextkatalog-ID = 8. 2 i slutet av filnamnet anger att det finns två crawlningsloggfiler för det här databas-/katalogparet.

Kontrollera användningen av fysiskt minne

Under en fulltextpopulation är det möjligt för fdhost.exe eller sqlservr.exe att få ont om minne eller att minnet tar slut.

• Om fulltextkrypningsloggen visar att fdhost.exe startas om ofta eller om felkoden 8007008 returneras innebär det att en av dessa processer håller på att få slut på minne.
• Om fdhost.exe producerar dumpar, särskilt på stora datorer med flera processorer, kan minnet ta slut.
• Information om minnesbuffertar som används av en fulltextkrypning finns i sys.dm_fts_memory_buffers (Transact-SQL).

De möjliga orsakerna till problem med låg minneskapacitet eller minnesbrist är följande:

• Otillräckligt med minne. Om mängden fysiskt minne som är tillgängligt under en fullständig population är noll kan SQL Server-buffertpoolen förbruka det mesta av det fysiska minnet i systemet.

  Den sqlservr.exe processen försöker hämta allt tillgängligt minne för buffertpoolen, upp till det konfigurerade maximala serverminnet. Om maximalt serverminne allokering är för stort, kan minnesbristsituationer uppstå och det kan misslyckas med att allokera delat minne för fdhost.exe processen.

  Du kan lösa det här problemet genom att ange maximalt serverminne värdet för SQL Server-buffertpoolen på rätt sätt. Mer information finns i Beräkna minneskraven för Filter Daemon Host Process (fdhost.exe), senare i det här avsnittet. Att minska batchstorleken som används för fulltextindexering kan också vara till hjälp.

• Minneskonkurration. Under en fulltextpopulation på en dator med flera processorer kan det uppstå konkurrens om buffertpoolminnet mellan fdhost.exe eller sqlservr.exe. Den resulterande bristen på delat minne orsakar batchåterförsök, minnesstörningar och dumpar från processen fdhost.exe.

• Problem med paginering. Otillräcklig sidfilstorlek, till exempel i ett system som har en liten sidfil med begränsad tillväxt, kan också leda till att fdhost.exe eller sqlservr.exe får slut på minne. Om crawlningsloggarna inte anger några minnesrelaterade fel är det troligt att prestandan är långsam på grund av överdriven sidväxling.

Beräkna minneskraven för Filter Daemon Host-processen (fdhost.exe)

Mängden minne som krävs av fdhost.exe för en population beror främst på antalet crawlningsintervall i fulltext som används, storleken på inkommande delat minne (ISM) och det maximala antalet ISM-instanser.

Mängden minne (i byte) som förbrukas av filterdaemonvärden kan beräknas ungefär med hjälp av följande formel:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

Standardvärdena för variablerna i föregående formel är följande:

variabel	standardvärde
antal_krypningsområden	Antalet processorer
ism_size	1 MB för x86-datorer 4 MB, 8 MB eller 16 MB för x64-datorer, beroende på det totala fysiska minnet
max_outstanding_isms	25 för x86-datorer 5 för x64-datorer

I följande tabell visas riktlinjer för hur du beräknar minneskraven för fdhost.exe. Formlerna i den här tabellen använder följande värden:

• F, vilket är en uppskattning av minne som behövs av fdhost.exe (i MB).

• T, vilket är det totala fysiska minne som är tillgängligt i systemet (i MB).

• M, vilket är den optimala inställningen maximalt serverminne.

Viktig information om följande formler finns i anteckningarna som följer tabellen.

Plattform	Beräkna fdhost.exe minneskrav i MB –F^1	Formel för beräkning av maximalt serverminne –M^2
x86	F = Antal crawlningsintervall * 50	M =minimum(T, 2000) - F - 500
x64	F = Antal krypintervall * 10 * 8	M = T - F - 500

Anteckningar om formler

1. Om flera fullständiga populationer pågår beräknar du fdhost.exe minneskraven för varje för sig, som F1, F2, och så vidare. Beräkna sedan M som T- sigma**(_F_i)**.
2. 500 MB är en uppskattning av det minne som krävs av andra processer i systemet. Om systemet utför ytterligare arbete ökar du det här värdet i enlighet med detta.
3. .ism_size antas vara 8 MB för x64-plattformar.

Exempel: Beräkna minneskraven för fdhost.exe

Det här exemplet är för en 64-bitars dator som har 8 GB RAM-minne och 4 processorer med dubbla kärnor. Den första beräkningen beräknar minne som behövs av fdhost.exe –F. Antalet crawlningsintervall är 8.

F = 8*10*8 = 640

Nästa beräkning hämtar det optimala värdet för maximalt serverminne -M. Det totala tillgängliga fysiska minnet i det här systemet i MBTär 8192.

M = 8192-640-500 = 7052

Exempel: Ange maximalt serverminne

I det här exemplet används sp_configure- och RECONFIGURE- Transact-SQL-instruktioner för att ange maximalt serverminne till det värde som beräknas för M i föregående exempel, 7052:

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

Mer information om alternativen för serverminne finns i Server Memory Server Configuration Options.

Kontrollera CPU-användning

Prestandan för fullständiga populationer är inte optimal när den genomsnittliga CPU-förbrukningen är lägre än cirka 30 procent. Här följer några faktorer som påverkar CPU-förbrukningen.

• Hög väntetid för sidor

  Kör följande Transact-SQL-instruktion för att ta reda på om en sidväntetid är hög:

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

  I följande tabell beskrivs de väntetyper som intresserar dig här.

  Väntetyp	Beskrivning	Möjlig lösning
  PAGEIO_LATCH_SH (_EX eller _UP)	Detta kan tyda på en I/O-prestandabegränsning, i vilket fall du vanligtvis också ser en hög medeldiskkö längd.	Om du flyttar fulltextindexet till en annan filgrupp på en annan disk kan du minska I/O-flaskhalsen.
  PAGELATCH_EX (eller _UP)	Detta kan tyda på mycket konkurrens mellan trådar som försöker skriva till samma databasfil.	Att lägga till filer i den filgrupp där fulltextindexet finns kan hjälpa till att lindra sådan konkurrens.

  Mer information finns i sys.dm_os_wait_stats (Transact-SQL).

• Ineffektivitet vid genomsökning av bastabellen

  En fullständig population söker igenom bastabellen för att skapa batchar. Den här tabellgenomsökningen kan vara ineffektiv i följande scenarier:

  • Om bastabellen har en hög procentandel kolumner utan rad som indexeras i fulltext kan det vara flaskhalsen att skanna bastabellen för att skapa batchar. I det här fallet kan det vara bra att flytta mindre data på rad med varchar(max) eller nvarchar(max).

  • Om bastabellen är mycket fragmenterad kan genomsökningen vara ineffektiv. Information om hur du beräknar out-of-row-data och indexfragmentering finns i sys.dm_db_partition_stats (Transact-SQL) och sys.dm_db_index_physical_stats (Transact-SQL).

    För att minska fragmenteringen kan du omorganisera eller återskapa ett klustrat index. Mer information finns i Omorganisera och återskapa index.

Felsöka långsam indexering av dokument

Notera

Det här avsnittet beskriver ett problem som bara påverkar kunder som indexerar dokument (till exempel Microsoft Word-dokument) där andra dokumenttyper är inbäddade.

Full-Text Engine använder två typer av filter när det fyller i ett fulltextindex: flertrådade filter och entrådade filter.

• Vissa dokument, till exempel Microsoft Word-dokument, filtreras med hjälp av ett flertrådat filter.
• Andra dokument, till exempel PDF-dokument (Adobe Acrobat Portable Document Format), filtreras med ett enkeltrådat filter.

Av säkerhetsskäl läses filter in av filter daemon-värdprocesserna. En serverinstans använder en flertrådad process för alla filter med flera trådar och en enkeltrådad process för alla entrådade filter. När ett dokument som använder ett flertrådat filter innehåller ett inbäddat dokument som använder ett entrådat filter startar Full-Text Engine en enkeltrådad process för det inbäddade dokumentet. När du till exempel stöter på ett Word-dokument som innehåller ett PDF-dokument använder Full-Text Engine den flertrådade processen för Word-innehållet och startar en enkeltrådad process för PDF-innehållet. Ett entrådat filter kanske dock inte fungerar bra i den här miljön och kan destabilisera filtreringsprocessen. I vissa fall där sådan inbäddning är vanlig kan destabilisering leda till krascher i processen. När detta inträffar dirigerar Full-Text Engine om alla misslyckade dokument – till exempel ett Word-dokument som innehåller inbäddat PDF-innehåll – till den enkeltrådiga filtreringsprocessen. Om omdirigering sker ofta resulterar det i prestandaförsämring av fulltextindexeringsprocessen.

Om du vill undvika det här problemet markerar du filtret för containerdokumentet (Word-dokumentet i det här exemplet) som ett enkeltrådat filter. Om du vill markera ett filter som ett enkelttrådat filter, anger du registerposten ThreadingModel för filtret till Apartment Threaded. Information om entrådade lägenheter finns i vitboken Understanding and Using COM Threading Models.

Se även

konfigurationsalternativ för serverminnesserver
maximalt serverkonfigurationsalternativ för fulltextkrypteringsintervall
Fyll i Full-Text index
Skapa och hantera Full-Text index
sys.dm_fts_memory_buffers (Transact-SQL)
sys.dm_fts_memory_pools (Transact-SQL)
Felsökning Full-Text Indexering
Full-Text Sök arkitektur