Leistungssteigerung und Optimierung von Volltextindizes

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 laut Protokoll des Volltextcrawls fdhost.exe häufig gestartet wird oder 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.

Hinweis
Informationen zu von einem Volltextcrawl verwendeten Arbeitsspeicherpuffer finden Sie unter sys.dm_fts_memory_buffers (Transact-SQL).

Die folgenden Ursachen sind möglich:

• Wenn der physische Speicher, der während einer vollständigen Auffüllung verfügbar ist, null ist, beansprucht der SQL Server-Pufferpool möglicherweise den größten Teil des physischen Systemspeichers.

  Der sqlservr.exe-Prozess 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 fdhost.exe-Prozess auftreten.

  Hinweis
  Während einer Volltextauffüllung können auf Multi-CPU-Computern, z. B. 64-Wege IA64-Computer, 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 fdhost.exe-Prozess.

  Sie können dieses Problem beheben, indem Sie den max server memory-Wert des SQL Server-Pufferpools entsprechend anpassen. Weitere Informationen finden Sie im Abschnitt "Schätzen der Arbeitsspeicheranforderungen des Filterdaemon-Hostprozesses (fdhost.exe)" weiter unten in diesem Thema. Möglicherweise ist es auch hilfreich, die verwendete Batchgröße für die Volltextindizierung zu reduzieren.

• Ein Auslagerungsproblem

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

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:

Variable	Standardwert
number_of_crawl_ranges	Die Anzahl der CPUs
ism_size	1 MB für x86-Computer 4 MB, 8 MB oder 16 MB für x64-Computer, abhängig vom gesamten physischen Arbeitsspeicher
max_outstanding_isms	25 für x86-Computer 5 für x64-Computer

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, der von fdhost.exe (in MB) benötigt wird.

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

• M, die optimale Einstellung von max server memory.

Wichtig
Grundlegende Informationen zu den Formeln finden Sie unten unter 1, 2 und 3.

Plattform	Schätzung des benötigten Arbeitsspeichers von "fdhost.exe" in MB: F1	Formel zum Berechnen des "max server memory"-Werts: M2
x86 mit deaktivierten AWE	F=Number of crawl ranges* 50	M=minimum(T, 2000)–F– 500
x86 mit aktivierten AWE	F=Number of crawl ranges* 50	M=T–F– 500
x64 oder IA643	F=Number of crawl ranges* 10 * 8	M=T–F– 500

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**(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 Prozesse ausführt, sollten Sie diesen Wert entsprechend erhöhen.

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

Beispiel: Schätzen der Arbeitsspeicheranforderungen von "fdhost.exe"

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

F = 8*10*8=640

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

M = 8192-640-500=7052

Beispiel: Festlegen von max server memory

In diesem Beispiel werden die Transact-SQL-Anweisungen sp_configure und RECONFIGURE verwendet, um max server memory auf den Wert festzulegen, der im vorherigen Beispiel für M berechnet wurde, also 7052:

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

So legen Sie die Konfigurationsoption "max server memory" fest

• Serverarbeitsspeicher-Optionen

• Vorgehensweise: Anzeigen oder Ändern von Servereigenschaften (SQL Server-Konfigurations-Manager)

• Vorgehensweise: Festlegen einer festen Arbeitsspeichergröße (SQL Server Management Studio)

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

• Langes Warten auf Seiten

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

  Execute 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 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 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 zur Berechnung von Daten, die außerhalb von Zeilen vorliegen, und zur 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.