Udostępnij za pośrednictwem

Zwiększanie wydajności indeksów Full-Text

  • Artykuł

Dotyczy:programu SQL ServerAzure SQL Database

W tym temacie opisano niektóre typowe przyczyny niskiej wydajności indeksów i zapytań pełnotekstowych. Zawiera również kilka sugestii, aby rozwiązać te problemy i poprawić wydajność.

Typowe przyczyny problemów z wydajnością

Problemy z zasobami sprzętowymi

Wydajność indeksowania pełnotekstowego i zapytań pełnotekstowych ma wpływ na zasoby sprzętowe, takie jak pamięć, szybkość dysku, szybkość procesora CPU i architektura maszyny.

Główną przyczyną zmniejszenia wydajności indeksowania pełnotekstowego jest limity zasobów sprzętowych.

  • procesora CPU. Jeśli użycie procesora przez proces hosta demona filtru (fdhost.exe) lub proces SQL Server (sqlservr.exe) jest zbliżone do 100 procent, procesor jest wąskim gardłem.

  • Pamięć. Jeśli brakuje pamięci fizycznej, pamięć może być wąskim gardłem.

  • Disk. Jeśli średnia długość kolejki oczekiwania na dysku jest większa dwukrotnie od liczby głowic dysków, na dysku występuje wąskie gardło. Podstawowym obejściem jest utworzenie katalogów pełnotekstowych, które są oddzielone od plików i dzienników bazy danych programu SQL Server. Umieść dzienniki, pliki bazy danych i wykazy pełnotekstowe na oddzielnych dyskach. Instalowanie szybszych dysków i używanie macierzy RAID może również pomóc zwiększyć wydajność indeksowania.

    Nota

    Od wersji SQL Server 2008 (10.0.x) aparat Full-Text może używać pamięci AWE, ponieważ aparat Full-Text jest częścią procesu sqlservr.exe. Aby uzyskać więcej informacji, zobacz Full-Text Architektura wyszukiwania.

Problemy z grupowaniem pełnego tekstu

Jeśli system nie ma wąskich gardeł sprzętowych, wydajność indeksowania wyszukiwania pełnotekstowego zależy głównie od następujących elementów:

  • Jak długo trwa tworzenie partii pełnotekstowych w programie SQL Server.

  • Jak szybko demon filtra może przetwarzać te pakiety.

Problemy z populacją indeksu pełnotekstowego

  • typ populacji. W przeciwieństwie do pełnej populacji przyrostowe, ręczne i automatyczne śledzenie zmian populacji nie są zaprojektowane tak, aby zmaksymalizować zasoby sprzętowe w celu osiągnięcia szybszej szybkości. W związku z tym sugestie dotyczące dostrajania w tym temacie mogą nie zwiększyć wydajności indeksowania pełnotekstowego w przypadku użycia przyrostowego, ręcznego lub automatycznego śledzenia zmian populacji.

  • master merge. Po ukończeniu populacji zostaje wyzwolony proces scalania końcowego, który scala fragmenty indeksu w jeden główny indeks pełnotekstowy. Skutkuje to lepszą wydajnością zapytań, ponieważ tylko indeks główny musi być odpytywane, a nie wiele fragmentów indeksu, a lepsze statystyki oceniania mogą być używane do klasyfikowania istotności. Jednak scalanie główne może być intensywnie obciążające I/O, ponieważ duże ilości danych muszą być zapisywane i odczytywane podczas scalania fragmentów indeksu, choć nie blokuje zapytań przychodzących.

    Opanowanie scalania dużych ilości danych może spowodować długotrwałe działanie transakcji, opóźniając obcinanie dziennika transakcji podczas punktu kontrolnego. W takim przypadku w ramach pełnego modelu odzyskiwania dziennik transakcji może znacznie wzrosnąć. Zgodnie z najlepszymi praktykami, zanim przystąpisz do reorganizacji dużego indeksu pełnotekstowego w bazie danych, która korzysta z pełnego modelu odzyskiwania, upewnij się, że dziennik transakcji ma wystarczającą ilość miejsca na długotrwałą transakcję. Aby uzyskać więcej informacji, zobacz Zarządzanie rozmiarem pliku dziennika transakcji.

Dostrajanie wydajności indeksów pełnotekstowych

Aby zmaksymalizować wydajność indeksów pełnotekstowych, zaimplementuj następujące najlepsze rozwiązania:

  • Aby użyć wszystkich procesorów CPU lub rdzeni do maksimum, ustaw sp_configure "maksymalny zakres przeszukiwania pełnotekstowego" do liczby procesorów CPU w systemie. Aby uzyskać informacje na temat tej opcji konfiguracji, zobacz maksymalny zakres pełnotekstowego indeksowania.

  • Upewnij się, że tabela podstawowa ma indeks klastrowany. Użyj typu danych całkowitych dla pierwszej kolumny indeksu klastrowanego. Unikaj używania identyfikatorów GUID w pierwszej kolumnie indeksu klastrowanego. Populacja obejmująca wiele zakresów w indeksie klastrowanym może generować najwyższą szybkość populacji. Zalecamy, aby kolumna służąca jako klucz pełnotekstowy był typem danych całkowitych.

  • Zaktualizuj statystyki tabeli podstawowej przy użyciu instrukcji UPDATE STATISTICS. Co ważniejsze, zaktualizuj statystyki dotyczące indeksu klastrowanego lub klucza pełnotekstowego dla pełnej populacji. Ułatwia to populacji o wielu zakresach generowanie dobrych partycji w tabeli.

  • Przed wykonaniem pełnej populacji na dużym komputerze z wieloma procesorami CPU zalecamy tymczasowe ograniczenie rozmiaru puli buforów, ustawiając wartość dla maksymalnej pamięci serwera, aby pozostawić wystarczającą ilość pamięci na proces fdhost.exe oraz na potrzeby systemu operacyjnego. Aby uzyskać więcej informacji, zobacz Szacowanie Wymagań Pamięci Procesu Hosta Demona Filtru (fdhost.exe)w dalszej części tego tematu.

  • Jeśli używasz populacji przyrostowej opartej na kolumnie ze znacznikiem czasu, utwórz indeks wtórny na kolumnie znacznika czasu, aby zwiększyć wydajność populacji przyrostowej.

Rozwiązywanie problemów z wydajnością całych populacji

Przejrzyj dzienniki pełnotekstowych przeszukiwań

Aby ułatwić diagnozowanie problemów z wydajnością, zapoznaj się z dziennikami przeszukiwania pełnotekstowego.

Gdy wystąpi błąd podczas przeszukiwania, funkcja rejestrowania przeszukiwań Full-Text tworzy i utrzymuje dziennik przeszukiwań, który jest plikiem zwykłego tekstu. Każdy dziennik przeszukiwania odpowiada określonemu wykazowi pełnotekstowemu. Domyślnie dzienniki przeszukiwania dla danego wystąpienia (w tym przykładzie wystąpienie domyślne) znajdują się w folderze %ProgramFiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\LOG.

Plik dziennika przeszukiwania jest zgodny z następującym schematem nazewnictwa:

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

Poniżej przedstawiono zmienne części nazwy pliku dziennika przeszukiwania.

  • < DatabaseID> — identyfikator bazy danych. < dbid> jest liczbą pięciocyfrową z zerami wiodącymi.
  • < FullTextCatalogID> — identyfikator wykazu pełnotekstowego. < catid> jest liczbą pięciocyfrową z zerami wiodącymi.
  • < n> — jest liczbą całkowitą wskazującą, że istnieje co najmniej jeden dziennik przeszukiwania tego samego wykazu pełnotekstowego.

Na przykład SQLFT0000500008.2 jest plikiem dziennika przeszukiwania bazy danych o identyfikatorze bazy danych = 5, a identyfikatorem wykazu pełnotekstowego = 8. Wartość 2 na końcu nazwy pliku wskazuje, że istnieją dwa pliki dziennika przeszukiwania dla tej pary bazy danych/katalogu.

Sprawdzanie użycia pamięci fizycznej

Podczas populacji pełnotekstowej może się zdarzyć, że fdhost.exe lub sqlservr.exe mają mało pamięci lub może zabraknąć pamięci.

  • Jeśli dziennik przeszukiwania pełnotekstowego pokazuje, że fdhost.exe jest często uruchamiany ponownie lub zwracany jest kod błędu 8007008, oznacza to, że jednemu z tych procesów brakuje pamięci.
  • Jeśli fdhost.exe generuje zrzuty, szczególnie na dużych, wieloprocesorowych komputerach, może kończyć się pamięć.
  • Aby uzyskać informacje o buforach pamięci używanych przez pełnotekstowe przeszukiwanie, zobacz sys.dm_fts_memory_buffers (Transact-SQL).

Możliwe przyczyny problemów z małą ilością pamięci lub brakiem pamięci są następujące:

  • niewystarczająca ilość pamięci. Jeśli ilość dostępnej pamięci fizycznej podczas pełnego wypełnienia pamięci wynosi zero, buforowa pula SQL Server może zużywać większość pamięci fizycznej w systemie.

    Proces sqlservr.exe próbuje zarezerwować całą dostępną pamięć dla puli buforów, aż do dostępnej skonfigurowanej maksymalnej pamięci serwera. Jeśli alokacja maksymalnej pamięci serwera jest zbyt duża, może dojść do warunków braku pamięci oraz braku przydzielenia pamięci udostępnionej dla procesu fdhost.exe.

    Ten problem można rozwiązać, ustawiając odpowiednio maksymalną pamięć serwera wartości puli programu SQL Server. Aby uzyskać więcej informacji, zobacz oszacowanie wymagań pamięci dla procesu hosta demona filtru (fdhost.exe), w dalszej części tego tematu. Zmniejszenie rozmiaru partii używanego do indeksowania pełnotekstowego może również pomóc.

  • Zawężenie pamięci. Podczas populacji pełnotekstowej na komputerze z wieloma procesorami CPU rywalizacja o pamięć puli może wystąpić między fdhost.exe lub sqlservr.exe. Brak dostępnej pamięci wspólnej powoduje ponawianie prób wsadowych, silne obciążenie pamięci i zrzuty przez proces fdhost.exe.

  • problemy ze stronicowaniem. Niewystarczający rozmiar pliku stronicowania, na przykład w systemie z małym plikiem stronicowania z ograniczonym wzrostem, może również spowodować, że fdhost.exe lub sqlservr.exe zabraknie pamięci. Jeśli dzienniki przeszukiwania nie wskazują żadnych błędów związanych z pamięcią, prawdopodobnie wydajność jest niska z powodu nadmiernego stronicowania.

Oszacuj wymagania dotyczące pamięci procesu hosta demona filtru (fdhost.exe)

Ilość pamięci wymaganej przez proces fdhost.exe dla populacji zależy głównie od liczby używanych zakresów przeszukiwania pełnotekstowego, rozmiaru pamięci udostępnionej dla ruchu przychodzącego i maksymalnej liczby wystąpień ISM.

Ilość pamięci (w bajtach) zużywana przez hosta demona filtru może być w przybliżeniu szacowana przy użyciu następującej formuły:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

Wartości domyślne zmiennych w poprzedniej formule są następujące:

zmienna wartość domyślna
number_of_crawl_ranges Liczba CPU
ism_size 1 MB dla komputerów x86

4 MB, 8 MB lub 16 MB dla komputerów x64, w zależności od całkowitej pamięci fizycznej
max_outstanding_isms 25 dla komputerów x86

5 dla komputerów x64

W poniższej tabeli przedstawiono wskazówki dotyczące szacowania wymagań dotyczących pamięci fdhost.exe. Formuły w tej tabeli używają następujących wartości:

  • F, czyli oszacowanie pamięci wymaganej przez fdhost.exe (w MB).

  • T, czyli całkowitej pamięci fizycznej dostępnej w systemie (w MB).

  • M, która jest optymalnym ustawieniem maksymalnej pamięci serwera.

Aby uzyskać podstawowe informacje o poniższych formułach, zobacz uwagi znajdujące się za tabelą.

Platforma Szacowanie wymagań dotyczących pamięci fdhost.exe w MB —F^1 Formuła obliczania maksymalnej pamięci serwera —M^2
x86 F = liczba zakresów przeszukiwania * 50 M =minimum(T, 2000) - F - 500
x64 F = Liczba zakresów przeszukiwania * 10 * 8 M = T - F - 500

uwagi dotyczące formuł

  1. Jeśli w toku jest wiele pełnych populacji, oblicz wymagania pamięci fdhost.exe dla każdej z osobna, tak jak F1, F2i tak dalej. Następnie oblicz M jako T- sigma**(_F_i)**.
  2. 500 MB to oszacowanie pamięci wymaganej przez inne procesy w systemie. Jeśli system wykonuje dodatkową pracę, zwiększ tę wartość odpowiednio.
  3. . zakłada się, żeism_size wynosi 8 MB dla platform x64.

Przykład: szacowanie wymagań dotyczących pamięci fdhost.exe

Ten przykład dotyczy 64-bitowego komputera, który ma 8 GB pamięci RAM i 4 procesory dwurdzeniowe. Pierwsze oszacowanie ilości potrzebnej pamięci przez fdhost.exe —F. Liczba zakresów przeszukiwania jest 8.

F = 8*10*8 = 640

Następne obliczenie uzyskuje optymalną wartość maksymalnej pamięci serwera -M. Całkowita ilość pamięci fizycznej dostępnej w tym systemie w MB -T- to 8192.

M = 8192-640-500 = 7052

Przykład: ustawianie maksymalnej pamięci serwera

W tym przykładzie użyto instrukcji sp_configure i RECONFIGURE Transact-SQL, aby ustawić maksymalną pamięć serwera na wartość obliczoną dla M w poprzednim przykładzie, 7052:

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

Aby uzyskać więcej informacji na temat opcji pamięci serwera, zobacz Opcje konfiguracji pamięci serwera .

Sprawdź użycie procesora

Wydajność pełnych populacji nie jest optymalna, gdy średnie użycie procesora jest niższe niż około 30 procent. Poniżej przedstawiono niektóre czynniki wpływające na użycie procesora CPU.

  • Długi czas oczekiwania dla stron

    Aby dowiedzieć się, czy czas oczekiwania strony jest wysoki, uruchom następującą instrukcję Transact-SQL:

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

    W poniższej tabeli opisano tutaj typy oczekiwania.

    Typ oczekiwania Opis Możliwe rozwiązanie
    PAGEIO_LATCH_SH (_EX lub _UP) Może to wskazywać na wąskie gardło operacji wejścia/wyjścia, w takim przypadku zazwyczaj widać również wysoką średnią długość kolejki dysku. Przeniesienie indeksu pełnotekstowego do innej grupy plików na innym dysku może pomóc w zmniejszeniu ograniczeń przepustowości wejścia/wyjścia.
    PAGELATCH_EX (lub _UP) Może to wskazywać na wiele konfliktów między wątkami, które próbują pisać do tego samego pliku bazy danych. Dodanie plików do grupy plików, w której znajduje się indeks pełnotekstowy, może pomóc złagodzić taką rywalizację.

    Aby uzyskać więcej informacji, zobacz sys.dm_os_wait_stats (Transact-SQL).

  • Nieefektywność podczas skanowania tabeli bazowej

    Pełna populacja skanuje tabelę podstawową w celu utworzenia partii. Skanowanie tej tabeli może być nieefektywne w następujących scenariuszach:

    • Jeśli tabela podstawowa ma wysoki procent kolumn przechowywanych poza wierszem, które są indeksowane pełnotekstowo, skanowanie tabeli podstawowej w celu utworzenia partii danych może być wąskim gardłem. W takim przypadku przeniesienie mniejszych danych w wierszu przy użyciu varchar(max) lub nvarchar(max) może pomóc.

    • Jeśli tabela podstawowa jest bardzo pofragmentowana, skanowanie może być nieefektywne. Aby uzyskać informacje o przetwarzaniu danych poza wierszem i fragmentacji indeksu, zobacz sys.dm_db_partition_stats (Transact-SQL) i sys.dm_db_index_physical_stats (Transact-SQL).

      Aby zmniejszyć fragmentację, można zreorganizować lub ponownie skompilować indeks klastrowany. Aby uzyskać więcej informacji, zobacz Przebudowa i Odbudowa Indeksów.

Rozwiązywanie problemów z powolnym indeksowaniem dokumentów

Nota

W tej sekcji opisano problem, który dotyczy tylko klientów, którzy indeksują dokumenty (takie jak dokumenty programu Microsoft Word), w których osadzone są inne typy dokumentów.

Silnik Full-Text używa dwóch typów filtrów, gdy wypełnia indeks pełnotekstowy: filtry wielowątkowe i filtry jednowątkowe.

  • Niektóre dokumenty, takie jak dokumenty programu Microsoft Word, są filtrowane przy użyciu filtru wielowątkowego.
  • Inne dokumenty, takie jak Adobe Acrobat Portable Document Format (PDF), są filtrowane przy użyciu filtru jednowątkowego.

Ze względów bezpieczeństwa filtry są ładowane przez procesy hosta demona filtru. Wystąpienie serwera używa wielowątkowego procesu dla wszystkich filtrów wielowątkowych i jednowątkowego procesu dla wszystkich filtrów jednowątkowych. Gdy dokument korzystający z filtru wielowątkowego zawiera osadzony dokument, który używa filtru jednowątkowego, aparat Full-Text uruchamia proces jednowątkowy dla osadzonego dokumentu. Na przykład podczas napotkania dokumentu programu Word zawierającego dokument PDF, silnik Full-Text używa wielowątkowego procesu dla zawartości programu Word i uruchamia jednowątkowy proces dla zawartości PDF. Filtr jednowątkowy może jednak nie działać dobrze w tym środowisku i może zdestabilizować proces filtrowania. W pewnych okolicznościach, gdy takie osadzanie jest powszechne, destabilizacja może prowadzić do awarii procesu. W takim przypadku silnik Full-Text ponownie kieruje dowolny dokument, który nie został przetworzony poprawnie — na przykład dokument programu Word zawierający osadzoną zawartość PDF — do procesu filtrowania opartego na jednym wątku. W przypadku częstego ponownego routingu powoduje obniżenie wydajności procesu indeksowania pełnotekstowego.

Aby obejść ten problem, oznacz filtr dokumentu kontenera (dokument programu Word, w tym przykładzie) jako filtr jednowątkowy. Aby oznaczyć filtr jako filtr jednowątkowy, ustaw wartość rejestru ThreadingModel filtru na wartość Apartment Threaded. Aby uzyskać informacje o apartamentach jednowątkowych, zobacz oficjalny dokument Understanding and Using COM Threading Models (Zrozumienie i stosowanie modeli wątków COM).

Zobacz też

Opcje konfiguracji pamięci serwera
opcja konfiguracji serwera maksymalnego zakresu pełnotekstowego przeszukiwania
Wypełnianie indeksów Full-Text
tworzenie indeksów Full-Text i zarządzanie nimi
sys.dm_fts_memory_buffers (Transact-SQL)
sys.dm_fts_memory_pools (Transact-SQL)
Rozwiązywanie problemów z indeksowaniem Full-Text
architektura wyszukiwania Full-Text