Verbessern der Leistung von Volltextindizes

Gilt für:SQL ServerAzure SQL-Datenbank

In diesem Thema werden einige häufige Ursachen für eine geringe Leistung für Volltextindizes und -Abfragen beschrieben. Darüber hinaus werden einige Vorschläge für das Verringern dieser Probleme und das Verbessern der Leistung gemacht.

Häufige Ursachen von Leistungsproblemen

Probleme mit Hardware

Die Leistung für Volltextindizes und Volltextabfragen wird von den Hardwareressourcen wie Arbeitsspeicher, Datenträgergeschwindigkeit, CPU-Geschwindigkeit und Computerarchitektur beeinflusst.

Der Hauptgrund für eine eingeschränkte Leistung beim Erstellen von Volltextindizes sind Einschränkungen bei den Hardwareressourcen:

• CPU: Wenn die CPU-Auslastung durch den Filterdaemonhost-Hostprozess (fdhost.exe) oder der SQL Server-Prozess (sqlservr.exe) nahe 100 Prozent liegt, ist die CPU der Engpass.

• Arbeitsspeicher: Wenn ein Mangel an physischem Speicher besteht, kann ggf. der Arbeitsspeicher der Engpass sein.

• Datenträger. Wenn die durchschnittliche Warteschlangenlänge des Datenträgers zweimal so groß wie die Anzahl von Leseköpfen ist, dann besteht ein Engpass auf dem Datenträger. Die primäre Problemumgehung besteht darin, Volltextkataloge zu erstellen, die von den SQL Server-Datenbankdateien und -Protokollen getrennt 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.

  Hinweis

  Ab SQL Server 2008 (10.0.x) kann das Full-Text-Modul den AWE-Speicher verwenden, da das Full-Text-Modul Teil des sqlservr.exe-Prozesses ist. Weitere Informationen finden Sie unter Architektur der Volltextsuche.

Volltext-Batchverarbeitungs Probleme

Wenn auf dem System keine Hardwareengpässe vorhanden sind, hängt die Indizierungsleistung der Volltextsuche vor allem von folgenden Faktoren ab:

• Wie lange es dauert, bis SQL Server Volltextbatches erstellt.

• Wie schnell der Filterdaemon diese Batches verarbeiten kann.

Volltextindex-Auffüllungsprobleme

• Typ der Auffüllung. 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 Thema die Leistung für Volltextindizierung nicht verbessern, wenn sie inkrementelle, manuelle oder automatische Änderungsüberwachungsauffüllung verwenden.

• Mastermerge Nach dem Ende einer Auffüllung wird ein abschließender Mergeprozess ausgelöst, der die Indexfragmente zu einem Mastervolltextindex zusammenführt. Dies ermöglicht eine verbesserte Abfrageleistung, da statt mehrerer Indexfragmente nur der Masterindex abgefragt werden muss. Zudem können bessere Bewertungsstatistiken zum Erstellen der Relevanzrangfolge verwendet werden. Der Mastermergeprozess kann E/A-intensiv sein, da beim Zusammenführen der Indexfragmente umfangreiche Daten geschrieben und gelesen werden müssen. Eingehende Abfragen werden dadurch jedoch nicht blockiert.

  Die Masterzusammenführung einer großen Datenmenge kann eine Transaktion mit langer Ausführungszeit 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. Sie sollten sicherstellen, dass das Transaktionsprotokoll vor dem Reorganisieren eines großen Volltextindexes in einer Datenbank, die das vollständige Wiederherstellungsmodell verwendet, genügend Speicherplatz für eine Transaktion mit langer Laufzeit bietet. 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 Prozessoren oder Kerne maximal zu nutzen, setzen Sie sp_configure 'max full-text crawl ranges' auf die Anzahl der CPUs des Systems fest. Informationen zu dieser Konfigurationsoption finden Sie unter Max. Bereich für Volltextdurchforstung (Serverkonfigurationsoption).

• 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. Es ist ratsam, für die Spalte, die als Volltextschlüssel dient, einen ganzzahligen Datentyp zu verwenden.

• Aktualisieren Sie die Statistiken der Basistabelle mithilfe der UPDATE STATISTICS -Anweisung. Noch wichtiger ist das Aktualisieren der Statistik für den gruppierten Index bzw. des Volltextschlüssels für eine vollständige Auffüllung. Dies unterstützt eine Mehrbereichsauffüllung beim Erzeugen guter Partitionen in der Tabelle.

• Bevor Sie eine vollständige Auffüllung auf einem großen Computer mit mehreren CPUs ausführen, sollten Sie die Größe des Pufferpools vorübergehend einschränken, indem Sie den max server memory -Wert so festlegen, dass noch genug Speicher für den fdhost.exe-Prozess und die Betriebssystemprozesse verfügbar ist. Weitere Informationen finden Sie unter Schätzen der Arbeitsspeicheranforderungen des Filterdaemon-Hostprozesses (fdhost.exe) weiter unten in diesem Artikel.

• 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.

Problembehandlung bei der Leistung der vollständigen Populationen

Überprüfen Sie die Volltextdurchforstungsprotokolle

Leistungsprobleme diagnostizieren Sie, indem Sie die Volltextdurchforstungsprotokolle überprüfen.

Tritt während eines Durchforstungsvorgangs ein Fehler auf, wird von der Durchforstungsprotokollfunktion der Volltextsuche ein Durchforstungsprotokoll erstellt und gewartet. Dabei handelt es sich um eine Nur-Text-Datei. Jedes Durchforstungsprotokoll gehört zu 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.

Das Benennungsschema für Durchforstungsprotokolldateien lautet folgendermaßen:

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

Die variablen Teile des Durchforstungsprotokolldatei-Namens sind die folgenden.

• <DatabaseID> – Die ID einer Datenbank. <"dbid> " ist eine fünfstellige Zahl mit führenden Nullen.
• <FullTextCatalogID> – Volltextkatalog-ID. <catid> ist eine fünfstellige Zahl mit führenden Nullen.
• <n> – Ist eine ganze Zahl, die angibt, dass mindestens ein Durchforstungsprotokoll desselben Volltextkatalogs vorhanden ist.

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 ist es möglich, dass fdhost.exe oder sqlservr.exe viel Arbeitsspeicher beansprucht oder nicht genügend Arbeitsspeicher vorhanden ist.

• Wenn das Protokoll der Volltextdurchforstung zeigt, dass fdhost.exe häufig neu gestartet oder dass Fehlercode 8007008 zurückgegeben wird, bedeutet dies, dass für einen der Prozesse kein Speicher mehr verfügbar ist.
• Wenn fdhost.exe Dumps erzeugt, insbesondere auf großen Multi-CPU-Computern, steht möglicherweise nicht genügend Arbeitsspeicher zur Verfügung.
• Informationen zu Speicherpuffern, die von einer Volltextdurchforstung verwendet werden, finden Sie unter sys.dm_fts_memory_buffers (Transact-SQL).

Die möglichen Ursachen für geringen Speicherplatz oder Problemen mit nicht genügend Arbeitsspeicher sind folgende:

• Der Arbeitsspeicher reicht nicht aus. Wenn der physische Arbeitsspeicher, der während einer vollständigen Grundanzahl verfügbar ist, null ist, verbraucht der SQL Server-Pufferpool möglicherweise den größten Teil des physischen Arbeitsspeichers auf dem System.

  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.

  Sie können dieses Problem beheben, indem Sie den maximalen Serverspeicherwert des SQL Server-Pufferpools entsprechend festlegen. Weitere Informationen finden Sie unter Schätzen der Arbeitsspeicheranforderungen des Filterdaemon-Hostprozesses (fdhost.exe) weiter unten in diesem Artikel. Möglicherweise ist es auch hilfreich, die verwendete Batchgröße für die Volltextindizierung zu reduzieren.

• Speicherkonflikte. Während einer Volltextauffüllung können auf Multi-CPU-Computern Konflikte zwischen fdhost.exe oder sqlservr.exe um den Pufferpoolarbeitsspeicher auftreten. Der daraus resultierende Mangel an gemeinsam genutztem Speicherbereich verursacht Batchwiederholungen, Arbeitsspeicherüberlastung und Dumps durch den Prozess "fdhost.exe".

• Auslagerungsprobleme 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 fdhost.exe oder sqlservr.exe nicht mehr auf genügend Arbeitsspeicher zugreifen können. Wenn die Crawlprotokolle keine speicherbezogenen Fehler anzeigen, ist die Leistung wahrscheinlich aufgrund zu vieler Auslagerungen beeinträchtigt.

Schätzen der Arbeitsspeicheranforderungen des Filterdaemon-Hostprozesses (fdhost.exe)

Der vom fdhost.exe-Prozess für eine Auffüllung benötigte Arbeitsspeicher hängt hauptsächlich von den verwendeten Volltext-Crawlbereichen, der Größe des Inbound Shared Memory (ISM) und der maximalen Anzahl von ISM-Instanzen ab.

Der vom Filterdaemonhost verwendete Arbeitsspeicher (in Bytes) kann mit der folgenden Formel ungefähr geschätzt werden:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

Die Standardwerte der Variablen in der vorangehenden Formel lauten wie folgt:

Die folgende Tabelle enthält Richtlinien zum Schätzen der Arbeitsspeicheranforderungen von fdhost.exe. Die Formeln in dieser Tabelle verwenden die folgenden Werte:

• F, eine Schätzung des Arbeitsspeichers, den „fdhost.exe“ (in MB) benötigt.

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

• M, die optimale max server memory -Einstellung.

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

Hinweise zu den Formeln

1. Wenn mehrere vollständige Auffüllungen ausgeführt werden, berechnen Sie die Arbeitsspeicheranforderungen für „fdhost.exe“ separat, also F1, F2, usw. Berechnen Sie dann M als T- sigma**(_F_i)**.
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 8 MB für x64-Plattformen angenommen.

Beispiel: Schätzen der Arbeitsspeicheranforderungen von „fdhost.exe“

Dieses Beispiel gilt für einen 64-Bit-Computer mit 8 GB RAM und 4 Dual-Core-Prozessoren. Die erste Berechnung schätzt den Speicher, der von „fdhost.exe“ benötigt wird: F. Die Anzahl der Durchforstungsbereiche beträgt 8.

F = 8*10*8 = 640

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

M = 8192-640-500 = 7052

Beispiel: Festlegen von "max server memory"

In diesem Beispiel werden die sp_configure- und RECONFIGURE Transact-SQL-Anweisungen verwendet, um den maximalen Serverspeicher auf den wert festzulegen, der für M im vorherigen Beispiel berechnet wird: 7052

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

Weitere Informationen zur Serverarbeitsspeicher-Option finden Sie unter Serverkonfigurationsoptionen für den Serverarbeitsspeicher.

Überprüfen der CPU-Verwendung

Es ist wahrscheinlich, dass die Leistung der vollständigen Auffüllungen nicht optimal ist, wenn der mittlere CPU-Verbrauch weniger als 30 Prozent beträgt. In diesem Abschnitt werden einige Faktoren behandelt, die sich auf den CPU-Verbrauch auswirken.

• Lange Wartezeiten für Seiten

  Um herauszufinden, ob eine Seitenwartzeit 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;  
  

  In der folgenden Tabelle sind die relevanten Wartetypen aufgeführt.

  Wartetyp	Beschreibung	Mögliche Lösung
  PAGEIO_LATCH_SH (_EX oder _UP)	Dies kann auf einen E/A-Engpass hinweisen. In diesem Fall ist normalerweise auch eine hohe durchschnittliche Warteschlangenlänge des Datenträgers zu erkennen.	Sie können den E/A-Engpass ggf. reduzieren, indem Sie den Volltextindex in eine andere Dateigruppe auf einem anderen Datenträger verschieben.
  PAGELATCH_EX (oder _UP)	Dies kann auf eine hohe Zahl von Konflikten zwischen Threads hinweisen, die versuchen, in dieselbe Datenbankdatei zu schreiben.	Diese Konflikte können ggf. verringert werden, indem Sie Dateien der Dateigruppe hinzufügen, auf der sich der Volltextindex befindet.

  Weitere Informationen finden Sie unter sys.dm_os_wait_stats (Transact-SQL).

• Ineffizienzen beim Durchsuchen der Basistabelle

  Eine vollständige Auffüllung durchsucht die Basistabelle, um Batches zu erzeugen. Dieses Durchsuchen der Tabelle kann in den folgenden Szenarios 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 kann es helfen, die kleineren Daten mithilfe von varchar(max) oder nvarchar(max) in die Zeilen zu verschieben.

  • Wenn die Basistabelle stark fragmentiert ist, kann das Durchsuchen ggf. ineffizient sein. Informationen zum Berechnen von Out-of-Row-Daten und Indexfragmentierung finden Sie unter sys.dm_db_partition_stats (Transact-SQL) und sys.dm_db_index_physical_stats (Transact-SQL).

    Um die Fragmentierung zu reduzieren, können Sie den gruppierten Index neu organisieren oder neu erstellen. Weitere Informationen finden Sie unter Neuorganisieren und Neuerstellen von Indizes.

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, z. B. Microsoft Word-Dokumente, werden mithilfe eines Multithreadfilters gefiltert.
• Andere Dokumente, wie z. B. Adobe Acrobat PDF-Dokumente (Portable Document Format), werden hingegen mit einem Filter mit einem einzigen Thread gefiltert.

Aus Sicherheitsgründen werden Filter mit Filterdaemon-Hostprozessen geladen. Eine Serverinstanz verwendet einen Multithreadprozess für alle Multithreadfilter und einen Singlethreadprozess für alle Filter mit einem einzigen Thread. 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. Beispiel: Bei einem Word-Dokument, das ein PDF-Dokument enthält, verwendet die Volltext-Engine einen Multithreadprozess für den Inhalt des Word-Dokuments und einen Singlethreadprozess für den Inhalt des PDF-Dokuments. Ein Filter mit einem einzigen Thread funktioniert in dieser Umgebung jedoch möglicherweise nicht ordnungsgemäß und kann die Stabilität des Filterprozesses gefährden. Unter bestimmten Umständen mit vielen eingebetteten Dokumenten, kann Destabilisierung zum Absturz des Prozesses führen. In diesem Fall verbindet die Volltext-Engine alle Dokumente, bei denen Fehler auftraten (z.B. ein Word-Dokument mit eingebettetem PDF-Inhalt), erneut mit dem Singlethread-Filterprozess. Kommt dies häufig vor, hat das eine Leistungsminderung des Volltextindizierungsprozesses zur Folge.

Sie müssen den Filter für das Containerdokument (hier das Word-Dokument) als Filter mit einem einzigen Thread kennzeichnen, um dieses Problem zu umgehen. Hierzu müssen Sie den Registrierungswert ThreadingModel für den Filter auf Apartment Threaded festlegen. Informationen zu Singlethreadapartments finden Sie im Whitepaper Understanding and Using COM Threading Models(Grundlegendes zur Verwendung von COM-Threadingmodellen).

Weitere Informationen

Serverkonfigurationsoptionen für den Serverarbeitsspeicher
Max. Bereich für Volltextdurchforstung (Serverkonfigurationsoption)
Auffüllen von Volltextindizes
Erstellen und Verwalten von Volltextindizes
sys.dm_fts_memory_buffers (Transact-SQL)
sys.dm_fts_memory_pools (Transact-SQL)
Behandeln von Problemen mit der Volltextindizierung
Architektur der Volltextsuche