Förbättra prestandan hos fulltextindex

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Denna artikel behandlar vanliga orsaker till dålig prestanda för fulltextindex och frågor, samt hur man kan mildra dem.

Vanliga orsaker till prestandaproblem

Detta avsnitt beskriver orsaker till vanliga prestandaproblem när du använder fulltextindex.

Problem med maskinvaruresurser

Hårdvaruresurser såsom minne, diskhastighet, CPU-hastighet och maskinarkitektur påverkar prestandan för fulltextindexering och fulltextfrågor.

Hårdvaruresursbegränsningar orsakar minskad fulltextindexeringsprestanda.

• CPU-. Om CPU-användningen av filterdaemonvärdprocessen (fdhost.exe) eller SQL Server-processen (sqlservr.exe) är nära 100 procent, är CPU:n flaskhalsen.

• Minne. Brist på fysiskt minne kan orsaka en flaskhals.

• Disk. Om den genomsnittliga väntetiden för disken ä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.

Problem med batchbearbetning i fulltext

Om systemet inte har några hårdvaruflaskhalsar beror indexeringsprestandan för fulltextsökning mestadels på följande faktorer:

• Hur lång tid det tar för Database Engine att skapa fulltextbatchar.

• Hur snabbt filterdaimonen konsumerar dessa satser.

Problem med fulltextindexpopulation

• typ av population. Till skillnad från fullständig population är inkrementell, manuell och automatisk population med ändringsspårning inte utformade för att maximera användningen av hårdvaruresurser för att uppnå högre prestanda. Därför kanske justeringsförslagen i denna artikel inte förbättrar prestandan för fulltextindexering när den använder inkrementell, manuell eller automatisk ändringsspårningspopulation.

• Primärsammanslagning. När en population är klar slås indexfragmenten samman till ett huvudindex fulltextindex i en slutlig sammanslagningsprocess. Denna process resulterar i förbättrad frågeprestanda eftersom endast huvudindexet behöver frågas istället för ett antal indexfragment. Bättre poängstatistik kan användas för relevansrankning. Dock kan master merge vara I/O-intensiv eftersom stora mängder data måste skrivas och läsas när indexfragment slås samman. Men den blockerar inte inkommande frågor.

  Att sammanfoga en stor mängd data i master kan skapa en långvarig transaktion, vilket fördröjer trunkeringen av transaktionsloggen vid 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:

• För att använda alla CPU-kärnor maximalt, ändra max full-text crawl range antalet kärnor på systemet. För mer information, se Serverkonfiguration: maximalt intervall för fulltextsökgenomsökning.

• 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. Använd en heltalsdatatyp för kolumnen som fungerar som fulltextnyckel.

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

• Innan du gör en fullständig population på en stor flerkärnig dator, begränsa tillfälligt buffertpoolens storlek genom att ställa in max server memory värdet så att det finns tillräckligt med minne för fdhost.exe processen och operativsystemets användning. För mer information, se Uppskatta minneskraven för värdprocessen för filterdemonen (fdhost.exe) senare i den här artikeln.

• 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

Se följande avsnitt för att lösa prestandaproblem med hela populationer.

Granska crawlningsloggarna i fulltext

För att hjälpa till att diagnostisera prestandaproblem, granska fulltext-crawlloggarna.

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>.[<n>]

Variabeldelarna i crawlningsloggfilens namn är följande.

• <DatabaseID>: Databasens ID, som ett femsiffrigt nummer med inledande nollor.

• <FullTextCatalogID>: Fulltextkatalog-ID, som ett femsiffrigt nummer med inledande nollor.

• <n>: Ett heltal som indikerar att en eller flera crawl-loggar från samma fulltextkatalog existerar.

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 fulltextifyllning kan processen fdhost.exe eller sqlservr.exe få ont om minne, eller till och med få slut på minne.

• Om fulltextgenomsökningsloggen visar att fdhost.exe ofta startar om eller returnerar felkod 8007008 innebär det att en av dessa processer börjar få minnesbrist.

• Om fdhost.exe skapar minnesdumpar, särskilt på stora system med flera kärnor, kan det bero på minnesbrist.

• För information om minnesbuffertar som används av en fulltextcrawl, se sys.dm_fts_memory_buffers.

Möjliga orsaker till problem med lite minne eller att minnet tar slut omfattar följande:

• Otillräckligt med minne. Om mängden fysiskt minne som finns tillgänglig under en full population är noll, kan Database Engine-buffertpoolen förbruka det mesta av det fysiska minnet på systemet.

  Den sqlservr.exe processen försöker hämta allt tillgängligt minne för buffertpoolen, upp till det konfigurerade maximala serverminnet. Om allokeringen max server memory är för stor kan det uppstå minnesutgång och misslyckande med att allokera delat minne för fdhost.exe processen.

  Ställ max server memory in värdet på Database Engine-buffertpoolen på rätt sätt för att lösa detta problem. För mer information, se Uppskatta minneskraven för värdprocessen för filterdemonen (fdhost.exe) senare i den här artikeln. Att minska batchstorleken som används för fulltextindexering kan också hjälpa.

• Minneskonkurration. Under en fulltextifyllning på ett flerkärnigt system kan fdhost.exe och sqlservr.exe konkurrera om minne i buffertpoolen. Den resulterande bristen på delat minne orsakar batchförsök, minneshantering och dumpningar av fdhost.exe processen.

• Problem med paginering. En otillräcklig storlek på sidfilen, till exempel på ett system med en liten sidfil som bara kan växa i begränsad omfattning, kan också göra att processen fdhost.exe eller sqlservr.exe får slut på minne. Om crawl-loggarna inte visar några minnesrelaterade fel orsakar överdriven sidning sannolikt långsam prestanda.

Uppskatta minnesbehovet för filterdaemonens värdprocess (fdhost.exe)

Mängden minne som fdhost.exe processen behöver för att fylla på beror främst på antalet fulltext-crawlintervall den använder, storleken på inkommande delat minne (ISM) och det maximala antalet ISM-instanser.

Du kan göra en ungefärlig uppskattning av minnesförbrukningen för värddatorn för filterdemonen genom att använda 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:

Följande tabell presenterar riktlinjer för att uppskatta minneskraven för fdhost.exe. Formlerna i den här tabellen använder följande värden:

• F, vilket är en uppskattning av minnesbehovet ( fdhost.exe i MB).

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

• M, vilket är den optimala max server memory inställningen.

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

1. Om flera fullständiga populationer pågår, beräkna minneskraven fdhost.exe för varje separat, som F1, F2 och så vidare. Beräkna sedan M som T - Σ(Fi).

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: Uppskatta minnesbehovet för fdhost.exe

Detta exempel gäller en 64-bitars dator som har 8 GB RAM och 4 dual-core-processorer. Den första beräkningen uppskattar minnesbehovet för fdhost.exeF. Antalet genomsökningsintervall är 8.

F = 8 * 10 * 8 = 640

Nästa beräkning ger det optimala värdet för max server memory (M). Det totala fysiska minnet som finns tillgängligt på detta system i MB, (T), är 8192.

M = 8192 - 640 - 500 = 7052

Exempel: Set max server memory

Detta exempel använder sp_configure och RECONFIGURE Transact-SQL-satserna för att sätta max server memory värdet som beräknats för M i föregående exempel, 7052:

USE master;
GO

EXECUTE sp_configure 'max server memory', 7052;
GO

RECONFIGURE;
GO

För mer information om serverminnesalternativen, se Serverminneskonfigurationsalternativ.

Kontrollera CPU-användning

Prestandan hos fulla 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;
  

  Följande tabell beskriver väntetyperna av intresse.

  Väntetyp	Beskrivning	Möjlig lösning
  PAGEIO_LATCH_SH (_EX eller _UP)	Denna väntetyp kan indikera en I/O-begränsning, och i så fall ser man vanligtvis också en hög genomsnittlig diskkölängd.	Att flytta fulltextindexet till en annan filgrupp på en annan disk kan hjälpa till att minska I/O-flaskhalsen.
  PAGELATCH_EX (eller _UP)	Denna väntetyp kan indikera mycket konflikt mellan trådar som försöker skriva till samma databasfil.	Att lägga till filer i filgruppen där fulltextindexet finns kan hjälpa till att minska sådan konflikt.

  Mer information finns i sys.dm_os_wait_stats.

• Ineffektivitet vid genomsökning av bastabellen

  En fullständig population söker igenom bastabellen för att skapa batchar. Denna tabellskanning 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 hjälpa att flytta den mindre datan i raden genom att använda varchar(max) eller nvarchar(max).

  • Om bastabellen är mycket fragmenterad kan genomsökningen vara ineffektiv. För information om beräkning av out-of-row-data och indexfragmentering, se sys.dm_db_partition_stats och sys.dm_db_index_physical_stats.

    För att minska fragmenteringen kan du omorganisera eller återskapa ett klustrat index. Mer information finns i Optimera indexunderhåll för att förbättra frågeprestanda och minska resursförbrukningen.

Felsöka långsam indexering av dokument

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, såsom Word-dokument, använder multitrådade filter.
• Andra dokument, såsom Adobe Acrobat Portable Document Format (PDF)-dokument, använder enkeltrådade 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 flertrådade filter 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. Dock kan ett enkeltrådat filter inte fungera bra i denna miljö 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 tillstånd uppstår omdirigerar Full-Text Engine alla misslyckade dokument (till exempel ett Word dokument som innehåller inbäddat PDF-innehåll) till den enkeltrådade filtreringsprocessen. Om omdirigering sker ofta resulterar det i prestandaförsämring av fulltextindexeringsprocessen.

För att komma runt det här problemet markerar du filtret för behållardokumentet (Word-dokument, i det här exemplet) som ett enkeltrådat filter. För att markera ett filter som ett enkeltrådat filter, sätt ThreadingModel registreringsvärdet för filtret till Apartment Threaded. För information om enkeltrådade lägenheter, se Förståelse och användning av COM-trådningsmodeller.

Relaterat innehåll

• Alternativ för serverminneskonfiguration
• Serverkonfiguration: max fulltext-crawl-intervall
• Fyll i Full-Text index
• Skapa och hantera fulltextindex
• sys.dm_fts_memory_buffers (Transact-SQL)
• sys.dm_fts_memory_pools (Transact-SQL)
• Felsök fulltextindexering
• Full-Text Sök arkitektur