Dostrajanie wydajności i optymalizacji indeksy pełnotekstowe
Wydajność indeksowania pełnotekstowego i kwerend pełnego tekstu ma wpływ zasobów sprzętowych, takich jak pamięć, szybkość dysku, szybkość Procesora i architektura maszyny.Główną przyczyną obniżoną wydajność indeksowania pełnotekstowego jest limitów zasób sprzętowych:
Jeśli użycie Procesora przez demona filtru proces (fdhost.exe) hosta lub SQL Server proces (sqlservr.exe) jest zbliżona do 100 procent, Procesora jest wąskie gardło.
Jeżeli więcej niż dwa razy liczba głowic dysku jest średnia długość kolejki dysku oczekiwania, istnieje wąskiego gardła na dysku.Podstawowa metoda obejścia problemu jest tworzenia wykazów pełnego tekstu, które są niezależne od SQL Server pliki bazy danych i dzienników.Umieścić dzienników, pliki bazy danych i katalogów pełnego tekstu na oddzielnych dyskach.Kupowanie szybsze dyski i używa macierzy RAID może również zwiększyć wydajność indeksowania.
W przypadku niedoboru pamięci fizycznej (limit 3 GB) pamięci może być wąskie gardło.Możliwe we wszystkich systemach są ograniczenia pamięci fizycznej i w systemach 32-bitowych może zmniejszyć ciśnienie pamięci wirtualnej niedziałający indeksowania pełnotekstowego.
Ostrzeżenie
Począwszy od SQL Server 2008, aparat pełnego tekstu można użyć AWE pamięci, ponieważ aparat pełnego tekstu jest częścią sqlservr.exe.
Jeśli system ma wąskie gardła nie sprzętu, wydajność indeksowania przeszukiwanie pełnego tekstu głównie zależy od następujących:
Jak długo trwa SQL Server w celu utworzenia instancji pełnego tekstu.
Jak szybko demona filtru można wykorzystać te partie.
Ostrzeżenie
W przeciwieństwie do pełnego zapełnianie przyrostowe, ręczne i automatyczne zmian zapełnianie nie są przeznaczone do maksymalizacji zasobów sprzętowych w celu osiągnięcia większej szybkości.Dlatego te sugestie strojenia nie może zwiększyć wydajność indeksowania pełnotekstowego.
Po zakończeniu zapełnianie procesu scalania końcowym zostanie wywołany, który scala fragmenty indeksu razem jednego wzorca indeksu pełnotekstowego.To wyniki wydajności udoskonalone kwerendy, ponieważ tylko indeks główny musi kwerendy zamiast liczbę fragmentów indeksu i lepiej punktacji statystyki mogą być stosowane do klasyfikacji istotności.Scalanie główne może zawierać obciążenie We/Wy, ponieważ duże ilości danych muszą być zapisywane i odczytać, gdy indeks fragmenty są scalane, chociaż nie blok przychodzących kwerend.
.gif "Ważna informacja") Ważne: |
|---|
Wzorzec scalanie dużą ilość danych, można utworzyć długo działającą transakcję, opóźnianie obcinania dziennika transakcji podczas punkt kontrolny.W takim przypadek w pełni model odzyskiwanie, dziennika transakcji może się znacząco rozrosnąć.Najlepszym rozwiązaniem przed reorganizowanie dużych indeksu pełnotekstowego w bazie danych używające pełnego model odzyskiwanie, upewnij się, że dziennik transakcji zawiera wystarczająco dużo miejsca dla transakcji długotrwały.Aby uzyskać więcej informacji, zobacz Rozmiar pliku dziennika transakcji. |
Dostrajanie wydajności indeksy pełnotekstowe
Aby zmaksymalizować wydajność indeksy pełnotekstowe, zaimplementować następujące wskazówki:
To use all processors or cores to the maximum, set sp_configure ‘max full-text crawl ranges’ to the number of CPUs on the system.Aby uzyskać informacje dotyczące tej opcji konfiguracja, zobacz maksymalny zakres przeszukiwanie pełnego tekstu, opcja.
Upewnij się, że tabela bazowa ma indeks klastrowany.Użyj danych typu Liczba całkowita dla pierwszej kolumna indeks klastrowany.Należy unikać identyfikatory GUID w pierwszym kolumna indeks klastrowany.Multi-zakres ludności na indeks klastrowany może wygenerować najwyższej prędkości zapełnianie.Zalecane kolumna, służąc jako klucz pełnotekstowego danych typu Liczba całkowita.
Aktualizowanie statystyki tabela bazowa za pomocą Aktualizacji statystyk instrukcja.Co ważniejsze, aktualizacji statystyk na indeks klastrowany lub klucz pełnotekstowego dla pełnego zapełnianie.Pomaga to multi-zakres zapełnianie do generowania dobrej partycjach tabela.
Budowanie indeksu pomocniczego na timestamp kolumna, jeśli chcesz zwiększyć wydajność przyrostowe zapełnianie.
Przed wykonaniem pełnego zapełnianie na komputerze dużych Wieloprocesorowych, zaleca się tymczasowo ograniczyć rozmiar pula buforów przez ustawienie max server memory wartość pozostawienie wystarczającej ilości pamięci dla procesu fdhost.exe i używany system operacyjny.Aby uzyskać więcej informacji, zobacz "Szacowanie wymagań pamięci procesu hosta demona filtru (fdhost.exe)" w dalszej części tego tematu.
Rozwiązywanie problemów wydajności populacji pełny
Do diagnozowania problemów z wydajnością, sprawdź dzienniki przeszukiwanie pełnego tekstu.Aby uzyskać informacje dotyczące przeszukiwanie dzienników, zobacz Rozwiązywanie problemów z błędami w populacji pełnego tekstu (przeszukiwanie)).
Zalecane jest, że następującej kolejności rozwiązywania problemów należy stosować, jeśli wydajność pełnego populacji nie.
Wykorzystanie pamięci fizycznej
Podczas pełnego tekstu zapełnianie jest fdhost.exe lub sqlservr.exe Uruchom mało pamięci lub pamięci.Jeśli przeszukiwanie pełnego tekstu dziennika pokazuje, że fdhost.exe jest ponownie uruchamiany często lub że kod błędu 8007008 jest zwracany oznacza to jedną z tych procesów zaczyna brakować pamięci.Jeśli fdhost.exe jest produkujących zrzuty, szczególnie w dużych, Wieloprocesorowych komputerach, może być uruchomiony pamięci.
Ostrzeżenie
Aby uzyskać informacje dotyczące bufory pamięci używane przez przeszukiwanie pełnego tekstu, zobacz sys.dm_fts_memory_buffers (języka Transact-SQL).
Możliwe przyczyny są następujące:
Jeśli ilość pamięci fizycznej, która jest dostępna podczas pełnego zapełnianie wynosi zero, SQL Server pula buforów może zajmująca większość fizycznej pamięci w systemie.
Proces sqlservr.exe próbuje chwyć całą dostępną pamięć dla pula buforów, do skonfigurowanego serwera maksymalnej pamięci.Jeśli Maksymalna pamięć alokacji jest zbyt duży, braku pamięci warunków i nie można przydzielić pamięci współużytkowanej może wystąpić w procesie fdhost.exe.
Ostrzeżenie
Podczas zapełnianie pełnego tekstu na komputerze Wieloprocesorowe, takiego jak komputer IA64 sposób 64 rywalizacja o pamięci pula buforów mogą wystąpić między fdhost.exe lub sqlservr.exe.Brak wynikowy ponownych prób partia powoduje pamięci współużytkowanej pamięci thrashing i zrzuty przez proces fdhost.exe.
Problem można rozwiązać przez ustawienie Maksymalna pamięć wartość SQL Server pula buforów odpowiednio.Aby uzyskać więcej informacji, zobacz "Szacowanie wymagań pamięci procesu hosta demona filtru (fdhost.exe)" w dalszej części tego tematu. Zmniejszenie partia rozmiar, używane do indeksowania pełnotekstowego również mogą pomóc.
Problem stronicowania
Rozmiar pliku strona niewystarczające, takie jak w systemie, który ma mały plik strona z ograniczeniami wzrostu może powodować również fdhost.exe lub sqlservr.exe do pamięci.
Jeśli dzienniki przeszukiwanie nie wskazują błędów związanych z pamięcią, jest prawdopodobne, że wydajność jest niska ze względu na nadmierne stronicowanie.
Szacowanie wymagań pamięci procesu hosta demona filtru (fdhost.exe)
Ilość pamięci wymaganej przez proces fdhost.exe zapełnianie zależy głównie od liczby zakresów przeszukiwanie pełnego tekstu korzysta, rozmiar pamięci współużytkowanej przychodzących (ISM) i maksymalnej liczby wystąpień ISM.
Ilość pamięci (w bajtach) zużytego przez hosta demona filtru można oszacować przybliżeniu za pomocą następującego wzoru:
number_of_crawl_ranges * ism_size * max_outstanding_isms * 2
Domyślne wartości zmiennych w powyższej formuły są następujące:
Variable |
Wartość domyślna |
|---|---|
number_of_crawl_ranges |
Liczba procesorów |
ism_size |
1 MB dla x 86 komputerom 4 MB, 8 MB lub 16 MB dla komputerów 64, w zależności od tego, całkowita pamięć fizyczna x |
max_outstanding_isms |
25 dla x 86 komputerom 5 dla komputerów 64 x |
Poniższa tabela przedstawia wytyczne dotyczące sposobu szacowania wymagania pamięci fdhost.exe.Formuły w tej tabela używają następujących wartości:
F, który jest oszacowanie pamięci wymaganego przez fdhost.exe (w MB).
T, który jest dostępny w systemie (w MB) całkowita pamięć fizyczna.
M, który jest optymalny Maksymalna pamięć ustawienie.
| Ważne: |
|---|
Dla podstawowych informacji na temat formuł, zobacz 1, 2, i 3, poniżej. |
Platforma |
Szacowanie wymagań pamięci fdhost.exe MB —F1 |
Formuła obliczania pamięci serwera max —M2 |
|---|---|---|
x 86 z AWE wyłączone |
F=Number of crawl ranges* 50 |
M=minimum(T, 2000)–F– 500 |
x 86 z AWE włączone |
F=Number of crawl ranges* 50 |
M=T–F– 500 |
x 64 lub IA643 |
F=Number of crawl ranges* 10 * 8 |
M=T–F– 500 |
1 w przypadku wielu pełnego populacji w toku, wymagania dotyczące pamięci fdhost.exe każdego obliczyć oddzielnie, jako F1, F2i tak dalej.Then calculate M as T**–** sigma**(Fi)**.
2 500 MB jest szacowana ilość pamięci wymaganej przez inne procesy w systemie.Jeśli system robi dodatkowej pracy, należy odpowiednio zwiększyć tę wartość.
3 .ism_size zakłada, że 8 MB dla x 64 platform.
Przykład: Szacowanie wymagań pamięci fdhost.exe
Ten przykład dotyczy komputera AMD64, zawierający 8 GM pamięci RAM i 4 procesorów dwurdzeniowych.Pierwsze oszacowania obliczania pamięci wymagane przez fdhost.exe—F.Liczba zakresów przeszukiwanie jest 8.
F = 8*10*8=640
The next calculation obtains the optimal value for max server memory—M.The total physical memory available on this system in MB—T—is 8192.
M = 8192-640-500=7052
Przykład: Ustawienie Maksymalna pamięć
This example uses the sp_configure and RECONFIGURE Transact-SQL statements to set max server memory to the value calculated for M in the preceding example, 7052:
USE master;
GO
EXEC sp_configure 'max server memory', 7052;
GO
RECONFIGURE;
GO
Aby zestaw opcji konfiguracja pamięci serwera max
Czynniki, które można zredukować zużycie Procesora
Oczekuje się, że wydajność pełnego populacji nie przebiega optymalnie, gdy średnie użycie Procesora jest niższy niż 30 procent.W tej sekcji omówiono niektóre czynniki wpływające na użycie Procesora.
Wysokie oczekiwania dla stron
Aby dowiedzieć się, czy czas oczekiwania strona jest wysoki, należy wykonać następujące Transact-SQL instrukcja:
Execute SELECT TOP 10 * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC;W poniższej tabela opisano typy oczekiwania odsetek tutaj.
Poczekaj typu
Opis
Możliwe rozwiązanie
PAGEIO_LATCH_SH (_EX lub _UP)
Może to wskazywać wąskie gardło operacji We/Wy, w którym to przypadek zazwyczaj również widoczna będzie długość kolejki dysku średnia wysoka.
Przenoszenie indeks pełnotekstowy z innym grupa plików na innym dysku może zmniejszyć wąskie gardło operacji We/Wy.
PAGELATCH_EX (lub _UP)
Może to oznaczać dużą rywalizacja między wątków, które próbujesz zapisać do tego samego plik bazy danych.
Dodawanie plików do grupa plików , na którym znajduje się indeks pełnotekstowy może ułatwić rozwiązanie takie rywalizacja.
Aby uzyskać więcej informacji, zobacz sys.dm_os_wait_stats (języka Transact-SQL).
Nieefektywność skanowanie tabela bazowa
zapełnianie pełne skanowanie tabela bazowa do produkcji partii.Skanowanie tabela może być mało wydajna w następujących scenariuszach:
Jeśli tabela bazowa ma wysoki procent kolumn poza wiersz, które są pełnotekstowe indeksowanych, skanowanie tabela bazowa do produkcji partii może być wąskie gardło.przypadek przenoszenia przy użyciu w wierszu dla mniejszych danych varchar(max) lub nvarchar(max) może pomocy.
tabela bazowa jest bardzo pofragmentowany, skanowanie może być mało wydajna.Informacje computing poza wiersz danych i indeks fragmentacji, zobacz sys.dm_db_partition_stats (języka Transact-SQL) i sys.dm_db_index_physical_stats (języka Transact-SQL).
Zmniejszenie fragmentacji, można reorganizować lub odbudować indeks klastrowany.Aby uzyskać więcej informacji, zobacz Reorganizowanie i odbudowa indeksów.
Zobacz także