Verbeter de prestaties van full-text indexen

Van toepassing op:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Dit artikel behandelt veelvoorkomende oorzaken van slechte prestaties voor full-text indexen en zoekopdrachten, en hoe deze te beperken.

Veelvoorkomende oorzaken van prestatieproblemen

Deze sectie beschrijft oorzaken van veelvoorkomende prestatieproblemen bij het gebruik van full-text indexes.

Problemen met hardwarebronnen

Hardwarebronnen zoals geheugen, schijfsnelheid, CPU-snelheid en machinearchitectuur beïnvloeden de prestaties van full-text indexering en full-text queries.

Hardware-resourcebeperkingen zorgen voor verminderde prestaties bij full-text indexering.

• CPU-. Als het CPU-gebruik door het filter-daemonhostproces (fdhost.exe) of het SQL Server-proces (sqlservr.exe) dicht bij 100 procent ligt, is de CPU de bottleneck.

• geheugen. Een tekort aan fysiek geheugen kan een bottleneck veroorzaken.

• Schijf. Als de gemiddelde wachtrijlengte voor de schijf meer dan twee keer het aantal schijfkoppen is, is er een bottleneck op de schijf. De primaire tijdelijke oplossing is het maken van volledige-tekstcatalogussen die gescheiden zijn van de SQL Server-databasebestanden en -logboeken. Plaats de logboeken, databasebestanden en catalogussen met volledige tekst op afzonderlijke schijven. Het installeren van snellere schijven en het gebruik van RAID kan ook helpen bij het verbeteren van de indexeringsprestaties.

Problemen met volledige-tekst batchverwerking

Als het systeem geen hardwarebottlenecks heeft, hangt de indexeringsprestatie van full-text search vooral af van de volgende factoren:

• Hoe lang het duurt voordat de Database Engine full-text batches maakt.

• Hoe snel de filterdaemon die batches verbruikt.

Problemen met populatie van volledige tekstindexen

• soort populatie. In tegenstelling tot volledige populatie zijn incrementele populatie, handmatige populatie en automatische populatie op basis van het bijhouden van wijzigingen niet ontworpen om hardwarebronnen maximaal te benutten om een hogere snelheid te bereiken. Daarom leiden de afstemmingsaanbevelingen in dit artikel mogelijk niet tot betere prestaties van full-textindexering wanneer deze gebruikmaakt van incrementele, handmatige of automatische populatie op basis van wijzigingstracering.

• hoofdsamenvoeging. Wanneer een populatie is voltooid, voegt een laatste samenvoegingsproces de indexfragmenten samen tot één master full-text index. Dit proces resulteert in verbeterde queryprestaties, omdat alleen de masterindex hoeft te worden geraadpleegd in plaats van een aantal indexfragmenten. Betere scorestatistieken kunnen worden gebruikt voor relevantierangschikking. De master merge kan echter I/O-intensief zijn omdat grote hoeveelheden data moeten worden geschreven en gelezen wanneer indexfragmenten worden samengevoegd. Toch blokkeert het geen binnenkomende zoekopdrachten.

  Het samenvoegen van een grote hoeveelheid data kan een langlopende transactie creëren, waardoor het afkorten van het transactielogboek tijdens het checkpoint wordt vertraagd. In dit geval kan het transactielogboek onder het volledige herstelmodel aanzienlijk toenemen. Als best practice moet u ervoor zorgen dat uw transactielogboek voldoende ruimte bevat voor een langlopende transactie voordat u een grote volledige-tekstindex in een database reorganiseert die het volledige herstelmodel gebruikt. Zie De grootte van het transactielogboekbestand beheren voor meer informatie.

De prestaties van indexen in volledige tekst afstemmen

Implementeer de volgende aanbevolen procedures om de prestaties van uw indexen in volledige tekst te maximaliseren:

• Om alle CPU-kernen maximaal te benutten, wijzig je max full-text crawl range in het aantal kernen van het systeem. Voor meer informatie, zie Serverconfiguratie: maximale full-text crawl range.

• Zorg ervoor dat de basistabel een geclusterde index heeft. Gebruik een gegevenstype geheel getal voor de eerste kolom van de geclusterde index. Vermijd het gebruik van GUID's in de eerste kolom van de geclusterde index. Een multi-range populatie op een geclusterde index kan de hoogste snelheid van populatie opleveren. Gebruik een geheel datatype voor de kolom die als volledige tekstsleutel dient.

• Werk de statistieken van de basistabel bij met behulp van de UPDATE STATISTICS instructie. Belangrijker, werk de statistieken voor de geclusterde index of de volledige-tekstsleutel voor een volledige populatie bij. Deze actie helpt een multibereikpopulatie om goede partities voor de tabel te genereren.

• Voordat je een volledige populatie uitvoert op een grote multi-core computer, beperk tijdelijk de grootte van de bufferpool door de max server memory waarde zo in te stellen dat er genoeg geheugen overblijft voor het fdhost.exe proces en het besturingssysteem. Raadpleeg voor meer informatie Een schatting maken van het geheugengebruik van het hostproces van de filterdaemon (fdhost.exe), verderop in dit artikel.

• Als u incrementele populatie gebruikt op basis van een tijdstempelkolom, bouwt u een secundaire index op de tijdstempel kolom om de prestaties van incrementele populatie te verbeteren.

Problemen met de prestaties van volledige populaties oplossen

Raadpleeg de volgende sectie om prestatieproblemen met volledige populaties op te lossen.

De verkenningslogboeken voor volledige tekst bekijken

Om prestatieproblemen te diagnosticeren, bekijk de volledige tekst crawllogs.

Wanneer er een fout optreedt tijdens een verkenning, maakt en onderhoudt de Full-Text zoekcrawl-logfaciliteit een verkenningslogboek, dat een tekstbestand zonder opmaak is. Elk verkenningslogboek komt overeen met een bepaalde volledige-tekstcatalogus. Crawllogs voor een bepaald exemplaar (in dit voorbeeld het standaardexemplaar) bevinden zich standaard in de %ProgramFiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\LOG map.

Het verkenningslogboekbestand volgt het volgende naamgevingsschema:

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

De variabele onderdelen van de naam van het verkenningslogboekbestand zijn het volgende.

• <DatabaseID>: De ID van een database, als een vijfcijferig nummer met vooraanstaande nullen.

• <FullTextCatalogID>: Volledige catalogus-ID, als een vijfcijferig nummer met leidende nullen.

• <n>: Een geheel getal dat aangeeft dat één of meer crawllogs van dezelfde full-text catalogus bestaan.

SQLFT0000500008.2 is bijvoorbeeld het verkenningslogboekbestand voor een database met database-id = 5 en catalogus-id voor volledige tekst = 8. De 2 aan het einde van de bestandsnaam geeft aan dat er twee verkenningslogboekbestanden voor dit database-/cataloguspaar zijn.

Fysiek geheugengebruik controleren

Tijdens een full-text-populatie kan het fdhost.exe- of sqlservr.exe-proces een tekort aan geheugen krijgen, of zelfs helemaal zonder geheugen komen te zitten.

• Als het full-text crawllog laat zien dat het fdhost.exe vaak opnieuw opstart of foutcode 8007008 teruggeeft, betekent dit dat een van deze processen zonder geheugen komt te zitten.

• Als fdhost.exe dumpbestanden genereert, vooral op grote systemen met meerdere cores, heeft het mogelijk onvoldoende geheugen.

• Voor informatie over geheugenbuffers die worden gebruikt door een full-text crawl, zie sys.dm_fts_memory_buffers.

De mogelijke oorzaken van weinig geheugen of problemen met geheugenverlies zijn onder andere de volgende zaken:

• Onvoldoende geheugen. Als de hoeveelheid fysiek geheugen die beschikbaar is tijdens een volledige populatie nul is, kan de bufferpool van de Database Engine het grootste deel van het fysieke geheugen op het systeem verbruiken.

  Het sqlservr.exe proces probeert alle beschikbare geheugen voor de buffergroep op te halen, tot het geconfigureerde maximale servergeheugen. Als de toewijzing van max server memory te groot is, kan er voor het proces fdhost.exe onvoldoende geheugen beschikbaar zijn en kan er geen gedeeld geheugen worden toegewezen.

  Stel de max server memory waarde van de bufferpool van de Database Engine correct in om dit probleem op te lossen. Raadpleeg voor meer informatie Een schatting maken van het geheugengebruik van het hostproces van de filterdaemon (fdhost.exe), verderop in dit artikel. Het verkleinen van de batchgrootte die wordt gebruikt voor full-text indexering kan ook helpen.

• geheugencontentie. Tijdens een volledige-tekstpopulatie op een multicoresysteem kunnen fdhost.exe en sqlservr.exe concurreren om bufferpoolgeheugen. Het daaruit voortvloeiende gebrek aan gedeeld geheugen veroorzaakt opnieuw uitgevoerde batchpogingen, memory thrashing en dumps van het fdhost.exe-proces.

• pagingsproblemen. Onvoldoende paginabestandsgrootte, zoals bij een systeem met een klein paginabestand met beperkte groei, kan er ook voor zorgen dat het fdhost.exe proces sqlservr.exe zonder geheugen komt te zitten. Als de crawllogs geen geheugengerelateerde storingen aangeven, veroorzaakt overmatig paging waarschijnlijk trage prestaties.

Schat de geheugenbehoefte van het filter-daemon-hostproces (fdhost.exe)

De hoeveelheid geheugen die het fdhost.exe proces nodig heeft om te vullen, hangt voornamelijk af van het aantal full-text crawl-bereiken dat het gebruikt, de grootte van inbound shared memory (ISM) en het maximale aantal ISM-instanties.

Je kunt het geheugenverbruik van de filter-daemon host globaal schatten met behulp van de volgende formule:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

De standaardwaarden voor de variabelen in de voorgaande formule zijn als volgt:

De volgende tabel geeft richtlijnen voor het schatten van de geheugenvereisten van fdhost.exe. De formules in deze tabel gebruiken de volgende waarden:

• F, wat een schatting is van het geheugen dat nodig is door fdhost.exe (in MB).

• T-, het totale fysieke geheugen dat beschikbaar is op het systeem (in MB).

• M, wat de optimale max server memory instelling is.

Zie de notities die volgen op de tabel voor essentiële informatie over de volgende formules.

1. Als er meerdere volledige populaties in ontwikkeling zijn, bereken dan de fdhost.exe geheugenvereisten van elk apart, als F1, F2, enzovoort. Bereken dan M als T - Σ(Fi).

2. 500 MB is een schatting van het geheugen dat is vereist voor andere processen in het systeem. Als het systeem extra werk doet, verhoogt u deze waarde dienovereenkomstig.

3. ism_size wordt verondersteld 8 MB te zijn voor x64-platforms.

Voorbeeld: Schat de geheugenbehoefte van fdhost.exe

Dit voorbeeld is voor een 64-bit computer met 8 GB RAM en 4 dual-core processors. De eerste berekening schat het geheugen dat fdhost.exe nodig heeft. Het aantal kruipbereiken is 8.

F = 8 * 10 * 8 = 640

De volgende berekening verkrijgt de optimale waarde voor max server memory (M). Het totale fysieke geheugen dat op dit systeem beschikbaar is in MB, (T), is 8192.

M = 8192 - 640 - 500 = 7052

Voorbeeld: Set max server memory

Dit voorbeeld gebruikt de sp_configure en RECONFIGURE Transact-SQL statements om de waarde te zetten max server memory die voor M in het voorgaande voorbeeld is berekend, 7052:

USE master;
GO

EXECUTE sp_configure 'max server memory', 7052;
GO

RECONFIGURE;
GO

Voor meer informatie over de servergeheugenopties, zie Servergeheugenconfiguratieopties.

CPU-gebruik controleren

De prestaties van volledige populaties zijn niet optimaal wanneer het gemiddelde CPU-verbruik lager is dan ongeveer 30 procent. Hier volgen enkele factoren die van invloed zijn op het CPU-verbruik.

• Hoge wachttijd voor pagina's

  Als u wilt weten of een paginawachttijd hoog is, voert u de volgende Transact-SQL-instructie uit:

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

  De volgende tabel beschrijft de wachttypen van interesse.

  Wachttype	Beschrijving	Mogelijke oplossing
  PAGEIO_LATCH_SH (_EX of _UP)	Dit wachttype kan wijzen op een I/O-bottleneck, waarbij je doorgaans ook een hoge gemiddelde schijfwachtrijlengte ziet.	Het verplaatsen van de full-text index naar een andere bestandsgroep op een andere schijf kan helpen om de I/O-bottleneck te verminderen.
  PAGELATCH_EX (of _UP)	Dit wachttype kan wijst op veel discussie tussen threads die proberen naar hetzelfde databasebestand te schrijven.	Het toevoegen van bestanden aan de bestandsgroep waarop de full-text index zich bevindt, kan helpen om dergelijke discussie te verminderen.

  Zie sys.dm_os_wait_stats voor meer informatie.

• Inefficiëntie bij het scannen van de basistabel

  Een volledige populatie scant de basistabel om batches te produceren. Deze tabelscanning kan inefficiënt zijn in de volgende scenario's:

  • Als de basistabel een hoog percentage kolommen buiten de hoofdrijen bevat die worden volledige-tekst geïndexeerd, kan het scannen van de basistabel voor batchproductie het knelpunt zijn. In dit geval kan het helpen om de kleinere data in-row te verplaatsen met varchar(max) of nvarchar(max).

  • Als de basistabel erg gefragmenteerd is, kan scannen inefficiënt zijn. Voor informatie over het berekenen van out-of-row data en indexfragmentatie, zie sys.dm_db_partition_stats en sys.dm_db_index_physical_stats.

    Als u fragmentatie wilt verminderen, kunt u de geclusterde index opnieuw organiseren of herbouwen. Zie Indexonderhoud optimaliseren om de queryprestaties te verbeteren en het resourceverbruik te verminderen voor meer informatie.

Problemen met trage indexering van documenten oplossen

De Full-Text Engine maakt gebruik van twee typen filters bij het vullen van een volledige-tekstindex: filters met meerdere threads en filters met één thread.

• Sommige documenten, zoals Word-documenten, gebruiken multithreaded filters.
• Andere documenten, zoals Adobe Acrobat Portable Document Format (PDF)-documenten, gebruiken enkelvoudige filters.

Om veiligheidsredenen worden filters geladen door de processen van de filterdaemon host. Een serverexemplaar gebruikt een meerdraadig proces voor alle meerdraadige filters en een eendraadig proces voor alle eendraadige filters. Wanneer een document dat gebruikmaakt van een filter met meerdere threads een ingesloten document bevat dat gebruikmaakt van een filter met één thread, start de Full-Text Engine een proces met één thread voor het ingesloten document. Als u bijvoorbeeld een Word-document tegenkomt dat een PDF-document bevat, gebruikt de Full-Text Engine het multithreaded-proces voor de Word-inhoud en start u een proces met één thread voor de PDF-inhoud. Een single-threaded filter werkt echter mogelijk niet goed in deze omgeving en kan het filterproces destabiliseren.

In bepaalde gevallen waarin dergelijke insluiting gebruikelijk is, kan destabilisatie leiden tot crashes van het proces. Wanneer deze situatie zich voordoet, stuurt de Full-Text Engine elk mislukt document (bijvoorbeeld een Word document met ingesloten PDF-inhoud) om naar het single-threaded filterproces. Als herroutering vaak plaatsvindt, leidt dit tot prestatievermindering van het indexeringsproces in volledige tekst.

Om dit probleem te omzeilen, markeert u het filter voor het containerdocument (het Word-document, in dit voorbeeld) als een filter met één thread. Om een filter als een enkelvoudig filter te markeren, stel je de ThreadingModel registerwaarde van het filter in op Apartment Threaded. Voor informatie over single-threaded apartments raadpleegt u Inzicht in en gebruik van COM-threadingmodellen.

Verwante onderwerpen

• Server geheugen configuratie opties
• Serverconfiguratie: maximale volledige tekstcrawlbereik
• indexen Full-Text vullen
• Volledige-tekstindexen maken en beheren
• sys.dm_fts_memory_buffers (Transact-SQL)
• sys.dm_fts_memory_pools (Transact-SQL)
• Probleemoplossing voor full-text indexering
• Full-Text zoekarchitectuur