De prestaties van Full-Text-indexen verbeteren

van toepassing op:SQL ServerAzure SQL Database-

In dit onderwerp worden enkele veelvoorkomende oorzaken van slechte prestaties voor indexen en query's in volledige tekst beschreven. Het biedt ook enkele suggesties om deze problemen te verhelpen en de prestaties te verbeteren.

Veelvoorkomende oorzaken van prestatieproblemen

Problemen met hardwarebronnen

De prestaties van indexering in volledige tekst en query's met volledige tekst worden beïnvloed door hardwarebronnen, zoals geheugen, schijfsnelheid, CPU-snelheid en machinearchitectuur.

De belangrijkste oorzaak voor verminderde indexeringsprestaties in volledige tekst zijn hardwareresourcelimieten.

• CPU-. Als het CPU-gebruik door het hostproces van de filterdemon (fdhost.exe) of het SQL Server-proces (sqlservr.exe) bijna 100 procent is, is de CPU het knelpunt.

• geheugen. Als er een tekort aan fysiek geheugen is, kan het geheugen het knelpunt zijn.

• Schijf. Als de gemiddelde wachtrijlengte voor schijfwachtrijen meer dan twee keer het aantal schijfkoppen is, is er een knelpunt 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.

  Notitie

  Vanaf SQL Server 2008 (10.0.x) kan de Full-Text Engine AWE-geheugen gebruiken omdat de Full-Text Engine deel uitmaakt van het sqlservr.exe proces. Zie Full-Text zoekarchitectuurvoor meer informatie.

Problemen met volledige-tekst batchverwerking

Als het systeem geen hardwareknelpunten heeft, zijn de indexeringsprestaties van zoekopdrachten in volledige tekst meestal afhankelijk van het volgende:

• Hoe lang het duurt voordat SQL Server batches met volledige tekst maakt.

• Hoe snel de filterdemon deze batches kan gebruiken.

Problemen met populatie van volledige tekstindexen

• soort populatie. In tegenstelling tot een volledige populatie zijn incrementele, handmatige en automatische manieren om wijzigingen bij te houden niet ontworpen om hardwarebronnen te maximaliseren om een hogere snelheid te behalen. Daarom kunnen de afstemmingsuggesties in dit onderwerp de prestaties voor indexering in volledige tekst niet verbeteren wanneer er gebruik wordt gemaakt van incrementele, handmatige of automatisch bijhouden van populaties voor wijzigingen.

• hoofdsamenvoeging. Wanneer een populatie is voltooid, wordt een definitief samenvoegproces geactiveerd waarmee de indexfragmenten worden samengevoegd in één hoofdindex voor volledige tekst. Dit resulteert in verbeterde queryprestaties, omdat alleen de hoofdindex moet worden opgevraagd in plaats van een aantal indexfragmenten, en betere scorestatistieken kunnen worden gebruikt voor relevantieclassificatie. De hoofdsamenvoeging kan echter I/O-intensief zijn, omdat grote hoeveelheden gegevens moeten worden geschreven en gelezen wanneer indexfragmenten worden samengevoegd, hoewel binnenkomende query's niet worden geblokkeerd.

  Het efficiënt samenvoegen van een grote hoeveelheid gegevens kan een transactie die lang loopt creëren, waardoor het inkorten van het transactielogboek tijdens een controlepunt 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 beherenvoor 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:

• Als u alle CPU-processors of kernen wilt gebruiken tot het maximum, stelt u sp_configure 'maximale verkenningsbereik voor volledige tekst' in op het aantal CPU's op het systeem. Zie voor meer informatie over deze configuratieoptie de serverconfiguratieoptie maximale bereik voor volledige-tekst crawl.

• 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. Wij raden aan dat de kolom die als volledige tekstsleutel fungeert, van het gegevenstype geheel getal is.

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

• Voordat u een volledige populatie uitvoert op een grote computer met meerdere CPU's, raden we u aan de grootte van de buffergroep tijdelijk te beperken door de maximale servergeheugen in te stellen waarde om voldoende geheugen te behouden voor het fdhost.exe proces en het gebruik van het besturingssysteem. Zie voor meer informatie Geheugenvereisten van het filter-daemonhostproces (fdhost.exe)verderop in dit onderwerp schatten.

• 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

De verkenningslogboeken voor volledige tekst bekijken

Bekijk de verkenningslogboeken voor volledige tekst om prestatieproblemen vast te stellen.

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

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

• < DatabaseID-> : de id van een database. < dbid> is een vijfcijferig getal met voorloopnullen.
• < FullTextCatalogID> - Catalogus-id voor volledige tekst. < catid> is een getal van vijf cijfers met voorloopnullen.
• < n> - Is een geheel getal dat aangeeft dat een of meer verkenningslogboeken van dezelfde catalogus voor volledige tekst 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 volledige tekstpopulatie is het mogelijk dat fdhost.exe of sqlservr.exe te weinig geheugen hebben of zonder geheugen komen te zitten.

• Als in het verkenningslogboek voor volledige tekst wordt aangegeven dat fdhost.exe vaak opnieuw wordt opgestart of dat foutcode 8007008 wordt geretourneerd, betekent dit dat een van deze processen onvoldoende geheugen heeft.
• Als fdhost.exe dumps produceert, met name op grote computers met meerdere CPU's, is er mogelijk onvoldoende geheugen beschikbaar.
• Zie sys.dm_fts_memory_buffers (Transact-SQL)voor informatie over geheugenbuffers die worden gebruikt tijdens een volledige-tekstdoorzoeking.

De mogelijke oorzaken van onvoldoende geheugen of problemen met onvoldoende geheugen zijn als volgt:

• Onvoldoende geheugen. Als de hoeveelheid fysiek geheugen die beschikbaar is tijdens een volledige populatie nul is, verbruikt de SQL Server-buffergroep mogelijk het grootste deel van het fysieke geheugen op het systeem.

  Het sqlservr.exe proces probeert alle beschikbare geheugen voor de buffergroep op te halen, tot het geconfigureerde maximale servergeheugen. Als de maximale servergeheugentoewijzing te groot is, kunnen er situaties optreden van onvoldoende geheugen en falen bij het toewijzen van gedeeld geheugen voor het fdhost.exe proces.

  U kunt dit probleem oplossen door het maximale servergeheugen in te stellen waarde van de SQL Server-buffergroep. Zie voor meer informatie het schatten van de geheugenvereisten van het filter-daemonhostproces (fdhost.exe)verderop in dit onderwerp. Het verminderen van de batchgrootte die wordt gebruikt voor indexering in volledige tekst kan ook helpen.

• geheugencontentie. Tijdens een volledige tekstpopulatie op een computer met meerdere CPU's kan er conflicten voor het geheugen van de buffer optreden tussen fdhost.exe en sqlservr.exe. Het resulterende gebrek aan gedeeld geheugen zorgt ervoor dat batch-pogingen, geheugen-thrashing en dumps worden uitgevoerd door het fdhost.exe proces.

• pagingsproblemen. Onvoldoende paginabestandsgrootte, zoals op een systeem met een kleine paginabestand met beperkte groei, kan er ook toe leiden dat de fdhost.exe of sqlservr.exe onvoldoende geheugen heeft. Als in de verkenningslogboeken geen geheugengerelateerde fouten worden aangegeven, is het waarschijnlijk dat de prestaties traag zijn vanwege overmatige paging.

Schatting maken van de geheugenvereisten van het hostproces voor filter daemon (fdhost.exe)

De hoeveelheid geheugen die nodig is voor het fdhost.exe proces voor een populatie, is voornamelijk afhankelijk van het aantal verkenningsbereiken voor volledige tekst, de grootte van inkomend gedeeld geheugen (ISM) en het maximum aantal ISM-exemplaren.

De hoeveelheid geheugen (in bytes) die door de filterdaemonhost wordt gebruikt, kan ruwweg worden geschat met behulp van de volgende formule:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

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

variabele	standaardwaarde
number_of_crawl_ranges	Het aantal CPU's
ism_size	1 MB voor x86-computers 4 MB, 8 MB of 16 MB voor x64-computers, afhankelijk van het totale fysieke geheugen
max_outstanding_isms	25 voor x86-computers 5 voor x64-computers

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

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

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

• M, wat de optimale maximale servergeheugeninstelling is.

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

Perron	Schatting van fdhost.exe geheugenvereisten in MB:F^1	Formule voor het berekenen van het maximale servergeheugen-M^2
x86	F = Aantal crawlbereiken * 50	M =minimum(T, 2000) - F - 500
x64	F = Aantal crawlranges * 10 * 8	M = T - F - 500

Notities bij de formules

1. Als er meerdere volledige populaties bezig zijn, berekent u de fdhost.exe geheugenvereisten van elk afzonderlijk, zoals F1, F2enzovoort. Bereken vervolgens M- als T- sigma**(_F_i)**.
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: De geheugenvereisten van fdhost.exe schatten

Dit voorbeeld is voor een 64-bits computer met 8 GB RAM-geheugen en 4 dual core-processors. De eerste berekeningschattingen van het geheugen dat nodig is voor fdhost.exe -F. Het aantal verkenningsbereiken is 8.

F = 8*10*8 = 640

De volgende berekening haalt de optimale waarde op voor maximum servergeheugen -M. Het totale fysieke geheugen dat beschikbaar is op dit systeem in MB-T-is 8192.

M = 8192-640-500 = 7052

Voorbeeld: Maximaal servergeheugen instellen

In dit voorbeeld worden de instructies sp_configure en OPNIEUW CONFIGUREREN Transact-SQL gebruikt om maximale servergeheugen in te stellen op de waarde die is berekend voor M- in het vorige voorbeeld, 7052:

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

Zie Server Memory Server Configuration Optionsvoor meer informatie over de servergeheugenopties.

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;  
  

  In de volgende tabel worden de wachttypen van belang hier beschreven.

  Wachttype	Beschrijving	Mogelijke oplossing
  PAGEIO_LATCH_SH (_EX of _UP)	Dit kan duiden op een IO-knelpunt. In dat geval ziet u doorgaans ook een hoge gemiddelde lengte van de schijfwachtrij.	Het verplaatsen van de volledige tekstindex naar een andere bestandsgroep op een andere schijf kan helpen het IO-knelpunt te verminderen.
  PAGELATCH_EX (of _UP)	Dit kan duiden op veel conflicten tussen threads die naar hetzelfde databasebestand willen schrijven.	Als u bestanden toevoegt aan de bestandsgroep waarop de fulltext-index zich bevindt, kan dit helpen om dergelijke conflicten te verlichten.

  Zie sys.dm_os_wait_stats (Transact-SQL)voor meer informatie.

• Inefficiëntie bij het scannen van de basistabel

  Een volledige populatie scant de basistabel om batches te produceren. Deze tabelscan 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 gegevens in rij te verplaatsen met behulp van varchar(max) of nvarchar(max).

  • Als de basistabel erg gefragmenteerd is, kan scannen inefficiënt zijn. Zie sys.dm_db_partition_stats (Transact-SQL) en sys.dm_db_index_physical_stats (Transact-SQL)voor informatie over het berekenen van out-of-row-gegevens en indexfragmentatie.

    Als u fragmentatie wilt verminderen, kunt u de geclusterde index opnieuw organiseren of herbouwen. Zie Indexen opnieuw ordenen en herbouwenvoor meer informatie.

Problemen met trage indexering van documenten oplossen

Notitie

In deze sectie wordt een probleem beschreven dat alleen van invloed is op klanten die documenten indexeren (zoals Microsoft Word-documenten) waarin andere documenttypen zijn ingesloten.

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 Microsoft Word-documenten, worden gefilterd met een filter dat meerdere threads gebruikt.
• Andere documenten, zoals Pdf-documenten (Adobe Acrobat Portable Document Format), worden gefilterd met behulp van een filter met één thread.

Om veiligheidsredenen worden filters geladen door de processen van de filterdaemon host. Een serverexemplaar gebruikt een multithreaded proces voor alle filters met meerdere threads en een enkelvoudig proces voor alle filters met één thread. 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 filter met één thread werkt mogelijk niet goed in deze omgeving en kan het filterproces destabilisereer. In bepaalde gevallen waarin dergelijke insluiting gebruikelijk is, kan destabilisatie leiden tot crashes van het proces. Wanneer dit gebeurt, stuurt de Full-Text Engine een mislukt document opnieuw, bijvoorbeeld een Word-document dat ingesloten PDF-inhoud bevat, opnieuw naar het filterproces met één thread. Als herroutering vaak plaatsvindt, leidt dit tot prestatievermindering van het indexeringsproces in volledige tekst.

Als u dit probleem wilt omzeilen, markeert u het filter voor het containerdocument (het Word-document, in dit voorbeeld) als een filter met één thread. Als u een filter wilt markeren als een enkelvoudige thread-filter, stelt u de registerwaarde ThreadingModel voor het filter in op Apartment Threaded. Zie het witboek COM Threading Modelsvoor meer informatie over appartementen met één thread.

Zie ook

Servergeheugen serverconfiguratieopties
maximale crawl-bereik serverconfiguratieoptie voor volledige tekst
indexen Full-Text vullen
Full-Text indexen maken en beheren
sys.dm_fts_memory_buffers (Transact-SQL)
sys.dm_fts_memory_pools (Transact-SQL)
Problemen met indexering Full-Text oplossen
Full-Text zoekarchitectuur