Verbesserung der Leistung von Volltextindizes

Gilt für:SQL ServerAzure SQL-DatenbankVerwaltete Azure SQL-Instanz

Dieser Artikel behandelt häufige Ursachen für schlechte Performance von Volltextindizes und Abfragen und wie man diese mindern kann.

Häufige Ursachen für Leistungsprobleme

Dieser Abschnitt beschreibt die Ursachen für häufige Leistungsprobleme bei der Verwendung von Volltext-Indexen.

Probleme mit Hardwareressourcen

Hardwareressourcen wie Speicher, Festplattengeschwindigkeit, CPU-Geschwindigkeit und Maschinenarchitektur beeinflussen die Leistung der Volltextindexierung und Volltextabfragen.

Hardware-Ressourcenbeschränkungen führen zu einer verminderten Volltext-Indexierungsleistung.

• CPU. Wenn die CPU-Auslastung durch den Filter-Daemon-Host-Prozess (fdhost.exe) oder den SQL Server-Prozess (sqlservr.exe) nahe an 100 Prozent liegt, ist die CPU der Engpass.

• Arbeitsspeicher. Ein Mangel an physischem Gedächtnis kann zu einem Engpass führen.

• Datenträger. Wenn die durchschnittliche Länge der Warteschlange für Festplattenzugriffe mehr als doppelt so hoch ist wie die Anzahl der Festplattenköpfe, liegt bei der Festplatte ein Engpass vor. Die erste Problemumgehung ist das Erstellen von Volltextkatalogen, die getrennt von den SQL Server-Datenbankendateien und -protokollen sind. Platzieren Sie Protokolle, die Datenbankdateien und Volltextkataloge auf getrennten Datenträgern. Installieren Sie schnellere Datenträger, und verwenden Sie RAID, um die Indexleistung zu verbessern.

Probleme bei der Volltext-Stapelverarbeitung

Wenn das System keine Hardware-Engpässe aufweist, hängt die Indexierungsleistung der Volltextsuche hauptsächlich von folgenden Faktoren ab:

• Wie lange die Datenbank-Engine braucht, um Volltext-Batches zu erstellen.

• Wie schnell der Filter-Daemon diese Chargen verbraucht.

Volltextindex-Auffüllungsprobleme

• Typ der Population. Im Gegensatz zur vollständigen Auffüllung eignet sich die inkrementelle, manuelle und automatische Änderungsnachverfolgung der Auffüllung nicht zum Maximieren von Hardwareressourcen, um schnellere Geschwindigkeiten zu erzielen. Aus diesem Grund können die Optimierungsvorschläge in diesem Artikel die Leistung für Volltextindizierung eventuell nicht verbessern, wenn sie inkrementelle, manuelle oder automatische Änderungsüberwachungsauffüllung verwenden.

• Mastermerge Wenn eine Population abgeschlossen ist, führt ein letzter Zusammenführungsprozess die Indexfragmente zu einem Master-Volltextindex zusammen. Dieser Prozess führt zu einer verbesserten Abfrageleistung, da nur der Master-Index abgefragt werden muss und nicht mehrere Indexfragmente. Bessere Bewertungsstatistiken könnten für die Relevanzrangordnung verwendet werden. Der Master Merge kann jedoch I/O-intensiv sein, da große Datenmengen geschrieben und gelesen werden müssen, wenn Indexfragmente zusammengeführt werden. Allerdings blockiert es keine eingehenden Anfragen.

  Die Masterzusammenführung einer großen Datenmenge kann eine zeitintensive Transaktion erzeugen und das Abschneiden des Transaktionsprotokolls während des Prüfpunkts verzögern. In diesem Fall kann das Transaktionsprotokoll unter dem vollständigen Wiederherstellungsmodell erheblich anwachsen. Als bewährte Vorgehensweise sollten Sie vor dem Neuorganisieren eines großen Volltextindexes in einer Datenbank, die das vollständige Wiederherstellungsmodell verwendet, sicherstellen, dass Ihr Transaktionsprotokoll ausreichend Speicherplatz für eine Transaktion mit langer Laufzeit enthält. Weitere Informationen finden Sie unter Verwalten der Größe der Transaktionsprotokolldatei.

Optimieren der Leistung von Volltextindizes

Sie können die Leistung Ihrer Volltextindizes mit den folgenden bewährten Methoden maximieren:

• Um alle CPU-Kerne maximal zu nutzen, ändere max full-text crawl range die Anzahl der Kerne im System. Weitere Informationen finden Sie unter Server-Konfiguration: maximaler Volltext-Crawl-Bereich.

• Stellen Sie sicher, dass die Basistabelle einen gruppierten Index besitzt. Verwenden Sie einen ganzzahligen Datentyp für die erste Spalte des gruppierten Index. Vermeiden Sie das Verwenden von GUIDs in der ersten Spalte des gruppierten Index. Eine Mehrbereichsauffüllung für einen gruppierten Index kann die höchste Auffüllungsgeschwindigkeit erzielen. Verwenden Sie einen ganzzahligen Datentyp für die Spalte, die als Volltextschlüssel dient.

• Aktualisieren Sie die Statistiken der Basistabelle mithilfe der UPDATE STATISTICS Anweisung. Noch wichtiger ist die Aktualisierung der Statistiken für den Clustered Index oder den Volltextschlüssel für eine vollständige Population. Diese Aktion unterstützt eine Mehrbereichsauffüllung beim Erzeugen guter Partitionen in der Tabelle.

• Bevor du eine vollständige Population auf einem großen Multi-Core-Computer durchführst, begrenze vorübergehend die Größe des Pufferpools, indem du den max server memory Wert so einstellst, dass genug Speicher für den Prozess und das fdhost.exe Betriebssystem übrig bleibt. Weitere Informationen finden Sie später in diesem Artikel unter Schätzung des Speicherbedarfs des Filter-Daemon-Hostprozesses (fdhost.exe).

• Wenn Sie eine inkrementelle Auffüllung basierend auf einer timestamp-Spalte verwenden, erstellen Sie einen zweiten Index in einer timestamp-Spalte, wenn Sie die Leistung der inkrementellen Auffüllung verbessern möchten.

Beheben von Leistungsproblemen bei vollständiger Auffüllung

Siehe den folgenden Abschnitt, um Leistungsprobleme mit vollständigen Populationen zu lösen.

Überprüfen Sie die Protokolle des Volltext-Crawls

Um Leistungsprobleme zu diagnostizieren, sehen Sie sich die Volltext-Crawl-Logs an.

Tritt während eines Crawlvorgangs ein Fehler auf, erstellt und verwaltet die Protokollierungsfunktion für Crawls der Volltextsuche ein Crawlprotokoll, bei dem es sich um eine reine Textdatei handelt. Jedes Crawlprotokoll entspricht einem bestimmten Volltextkatalog. Standardmäßig befinden sich Durchforstungsprotokolle für eine bestimmte Instanz (in diesem Beispiel die Standardinstanz) im Ordner %ProgramFiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\LOG.

Die Crawl-Logdatei folgt folgendem Benennungsschema:

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

Die variablen Teile des Dateinamens der Crawling-Protokolldatei sind folgende.

• <DatabaseID>: Die ID einer Datenbank, als fünfstellige Zahl mit führenden Nullen.

• <FullTextCatalogID>: Volltext-Katalog-ID, als fünfstellige Zahl mit führenden Nullen.

• <n>: Eine ganze Zahl, die anzeigt, dass ein oder mehrere Crawl-Logs desselben Volltextkatalogs existieren.

SQLFT0000500008.2 ist z.B. die Durchforstungsprotokolldatei für eine Datenbank mit der Datenbank-ID = 5 und der Volltextkatalog-ID = 8. Die 2 am Ende des Dateinamens gibt an, dass zwei Durchforstungsprotokolldateien für dieses Datenbank-Katalog-Paar vorhanden sind.

Überprüfen Sie die Verwendung des physischen Speichers

Während einer Volltextauffüllung kann der Prozess fdhost.exe oder sqlservr.exe nur noch wenig Arbeitsspeicher zur Verfügung haben oder sogar keinen Arbeitsspeicher mehr haben.

• Wenn das Volltext-Crawl-Log zeigt, dass fdhost.exe er häufig neu startet oder einen Fehlercode 8007008 zurückgibt, bedeutet das, dass einem dieser Prozesse der Speicher ausgeht.

• Wenn fdhost.exe Dumps erzeugt, insbesondere auf großen Mehrkernsystemen, könnte ihm der Speicher ausgehen.

• Informationen zu Speicherpuffern, die von einem Volltext-Crawl verwendet werden, finden Sie unter sys.dm_fts_memory_buffers.

Mögliche Ursachen für Speichermangel oder Fehlfunktionen umfassen folgende Punkte:

• Der Arbeitsspeicher reicht nicht aus. Wenn die Menge des physischen Speichers, die während einer vollständigen Besetzung verfügbar ist, null ist, könnte der Datenbank-Engine-Pufferpool den Großteil des physischen Speichers des Systems verbrauchen.

  Der Prozess sqlservr.exe versucht, den gesamten verfügbaren Speicher für den Pufferpool bis zum konfigurierten maximalen Serverarbeitsspeicher für sich zu beanspruchen. Wenn die max server memory-Zuordnung zu groß ist, können Probleme aufgrund ungenügenden Arbeitsspeichers und Fehler bei der Zuordnung von gemeinsam genutzten Speicherbereich für den Prozess fdhost.exe auftreten.

  Stellen Sie den max server memory Wert des Datenbank-Engine-Bufferpools entsprechend ein, um dieses Problem zu lösen. Weitere Informationen finden Sie später in diesem Artikel unter Schätzung des Speicherbedarfs des Filter-Daemon-Hostprozesses (fdhost.exe). Eine Verringerung der Batchgröße für die Volltextindexierung könnte ebenfalls helfen.

• Speicherkonkurrenz. Während einer Volltextpopulation auf einem Multi-Core-System können fdhost.exe und sqlservr.exe um Pufferpool-Speicher konkurrieren. Der daraus resultierende Mangel an gemeinsam genutztem Speicherbereich verursacht Batchwiederholungen, Arbeitsspeicherüberlastung und Dumps durch den Prozess fdhost.exe.

• Paginierungsprobleme. Eine zu kleine Auslagerungsdatei, z. B. wenn ein System über eine kleine Auslagerungsdatei mit eingeschränkter Vergrößerung verfügt, kann ebenfalls dazu führen, dass der Prozess fdhost.exe oder sqlservr.exe nicht mehr auf genügend Arbeitsspeicher zugreifen kann. Wenn die Crawl-Logs keine speicherbedingten Fehler anzeigen, verursacht übermäßiges Pagingen wahrscheinlich eine langsame Leistung.

Schätzung des Speicherbedarfs des Filter-Daemon-Hostprozesses (fdhost.exe)

Die Speichermenge, die der fdhost.exe-Prozess zum Auffüllen benötigt, hängt hauptsächlich von der Anzahl der von ihm verwendeten Volltext-Crawlbereiche, der Größe des eingehenden gemeinsamen Speichers (ISM) und der maximalen Anzahl von ISM-Instanzen ab.

Man kann den Speicherverbrauch des Filter-Daemon-Hosts grob mit folgender Formel abschätzen:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

Die Standardwerte für die Variablen in der vorherigen Formel sind wie folgt:

Die folgende Tabelle bietet Richtlinien zur Schätzung des Speicherbedarfs von fdhost.exe. Die Formeln in dieser Tabelle verwenden die folgenden Werte:

• F, was eine Schätzung des benötigten Speichers von fdhost.exe (in MB) ist.

• T, der gesamte physische Speicher, der für das System (in MB) verfügbar ist.

• M, was die optimale max server memory Einstellung ist.

Wichtige Informationen zu den folgenden Formeln finden Sie in den Notizen unter der Tabelle.

1. Wenn mehrere vollständige Populationen im Gange sind, berechnen Sie den fdhost.exe Speicherbedarf jeder einzeln als F1, F2 und so weiter. Berechnen Sie dann M als T - Σ (Fi).

2. 500 MB ist eine Schätzung des erforderlichen Speichers, der von den anderen Prozessen im System benötigt wird. Wenn das System noch weitere Aufgaben durchführt, sollten Sie diesen Wert entsprechend erhöhen.

3. ism_size wird mit 8 MB für x64-Plattformen angenommen.

Beispiel: Schätzen Sie den Speicherbedarf von fdhost.exe

Dieses Beispiel bezieht sich auf einen 64-Bit-Computer mit 8 GB RAM und 4 Dual-Core-Prozessoren. Die erste Berechnung schätzt den von fdhost.exe benötigten Speicher. Die Anzahl der Kriechbereiche ist 8.

F = 8 * 10 * 8 = 640

Die nächste Berechnung erhält den optimalen Wert für max server memory (M). Der gesamte physische Speicher, der auf diesem System in MB (T) verfügbar ist, beträgt 8192.

M = 8192 - 640 - 500 = 7052

Beispiel: Set max server memory

Dieses Beispiel verwendet die Transact-SQL-Anweisungen sp_configure und RECONFIGURE, um max server memory auf den im vorhergehenden Beispiel für M berechneten Wert festzulegen, 7052:

USE master;
GO

EXECUTE sp_configure 'max server memory', 7052;
GO

RECONFIGURE;
GO

Für weitere Informationen zu den Serverspeicheroptionen siehe Serverspeicherkonfigurationsoptionen.

Überprüfen der CPU-Verwendung

Die Leistung voller Populationen ist nicht optimal, wenn der durchschnittliche CPU-Verbrauch unter etwa 30 Prozent liegt. In diesem Abschnitt werden einige Faktoren behandelt, die sich auf den CPU-Verbrauch auswirken.

• Lange Wartezeiten für Seiten

  Um herauszufinden, ob die Wartezeit für Seiten hoch ist, führen Sie die folgende Transact-SQL-Anweisung aus:

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

  Die folgende Tabelle beschreibt die Wartearten von Interesse.

  Wartetyp	Beschreibung	Mögliche Lösung
  PAGEIO_LATCH_SH (_EX oder _UP)	Dieser Wartetyp könnte auf einen I/O-Engpass hinweisen; in diesem Fall ist typischerweise auch eine hohe durchschnittliche Länge der Datenträgerwarteschlange zu beobachten.	Das Verschieben des Volltextindex in eine andere Dateigruppe auf einer anderen Festplatte könnte helfen, den I/O-Engpass zu verringern.
  PAGELATCH_EX (oder _UP)	Dieser Wartetyp könnte auf viel Streit zwischen Threads hinweisen, die versuchen, in dieselbe Datenbankdatei zu schreiben.	Das Hinzufügen von Dateien zur Dateigruppe, auf der sich der Volltextindex befindet, könnte helfen, solche Streitigkeiten zu mildern.

  Weitere Informationen finden Sie unter sys.dm_os_wait_stats.

• Ineffizienzen beim Scannen der Basistabelle

  Eine vollständige Auffüllung durchsucht die Basistabelle, um Batches zu erzeugen. Dieses Tabellen-Scannen könnte in den folgenden Szenarien ineffizient sein:

  • Wenn die Basistabelle über einen hohen Prozentsatz an Außerhalb-Spalten (out-of-row) verfügt, für die eine Volltextindizierung durchgeführt wird, kann das Durchsuchen der Basistabelle zum Erzeugen von Batches den Engpass bewirken. In diesem Fall könnte es helfen, die kleineren Daten in der Reihe mit varchar(max) oder nvarchar(max) zu verschieben.

  • Wenn die Basistabelle stark fragmentiert ist, kann das Durchsuchen ggf. ineffizient sein. Informationen zur Berechnung von Out-of-Row-Daten und Indexfragmentierung finden Sie unter sys.dm_db_partition_stats und sys.dm_db_index_physical_stats.

    Um die Fragmentierung zu reduzieren, können Sie den gruppierten Index neu organisieren oder neu erstellen. Weitere Informationen finden Sie unter Optimieren der Indexwartung, um die Abfrageleistung zu verbessern und den Ressourcenverbrauch zu verringern.

Problembehandlung bei langsamer Indizierung von Dokumenten

Beim Auffüllen eines Volltextindexes werden von der Volltext-Engine zwei Arten von Filtern verwendet, Multithread-Filter und Filter mit einem einzigen Thread.

• Einige Dokumente, wie zum Beispiel Word-Dokumente, verwenden Multithread-Filter.
• Andere Dokumente, beispielsweise Adobe Acrobat Portable Document Format (PDF)-Dokumente, verwenden Single-Thread-Filter.

Aus Sicherheitsgründen werden Filter von den Hostprozessen des Filter-Daemons geladen. Eine Serverinstanz verwendet für alle mehrthreadigen Filter einen mehrthreadigen Prozess und für alle einzelthreadigen Filter einen einzelthreadigen Prozess. Wenn in einem Dokument, für das ein Multithreadfilter verwendet wird, ein Dokument eingebettet ist, für das ein Filter mit einem einzigen Thread verwendet wird, startet die Volltext-Engine einen Singlethreadprozess für das eingebettete Dokument. Zum Beispiel verwendet die Volltext-Engine, wenn sie auf ein Word-Dokument stößt, das ein PDF-Dokument enthält, einen Multithread-Prozess für den Inhalt des Word-Dokuments und startet einen Singlethread-Prozess für den Inhalt des PDF-Dokuments. Ein Ein-Thread-Filter funktioniert in dieser Umgebung jedoch möglicherweise nicht gut und könnte den Filterprozess destabilisieren.

Unter bestimmten Umständen, in denen eine solche Einbettung üblich ist, kann eine Destabilisierung zum Absturz des Prozesses führen. Wenn dieser Zustand auftritt, leitet die Full-Text Engine jedes fehlgeschlagene Dokument (zum Beispiel ein Word Dokument, das eingebettete PDF-Inhalte enthält) an den Einzelthread-Filterprozess um. Wenn es häufig zu Umleitungen kommt, führt dies zu einem Leistungsabfall bei der Volltextindizierung.

Um dieses Problem zu umgehen, markieren Sie den Filter für das Container-Dokument (das Word-Dokument in diesem Beispiel) als einen Single-Thread-Filter. Um einen Filter als Einzelthread-Filter zu markieren, setzen Sie den ThreadingModel Registry-Wert des Filters auf Apartment Threaded. Informationen zu Singlethreadapartments finden Sie unter Grundlegendes zur Verwendung von COM-Threadingmodellen.

Verwandte Inhalte

• Konfigurationsoptionen für den Serverarbeitsspeicher
• Serverkonfiguration: maximale Volltext-Crawl-Reichweite
• Auffüllen von Volltextindizes
• Erstellen und Verwalten von Volltextindizes
• sys.dm_fts_memory_buffers (Transact-SQL)
• sys.dm_fts_memory_pools (Transact-SQL)
• Fehlerbehebung der Volltext-Indexierung
• Architektur der Volltextsuche