Zlepšení výkonu indexů Full-Text

platí pro:SQL Serverazure SQL Database

Toto téma popisuje některé běžné příčiny nízkého výkonu fulltextových indexů a dotazů. Obsahuje také několik návrhů, jak tyto problémy zmírnit a zlepšit výkon.

Běžné příčiny problémů s výkonem

Problémy s hardwarovými prostředky

Výkon fulltextového indexování a fulltextových dotazů je ovlivněn hardwarovými prostředky, jako jsou paměť, rychlost disku, rychlost procesoru a architektura počítače.

Hlavní příčinou sníženého výkonu fulltextového indexování je omezení hardwarových prostředků.

• procesoru. Pokud se využití procesoru procesem démona filtru (fdhost.exe) nebo procesem SQL Serveru (sqlservr.exe) blíží 100 procent, je kritickým bodem procesor.

• paměť. Pokud je nedostatek fyzické paměti, může být paměť omezujícím faktorem.

• disku. Pokud je průměrná délka fronty čekání na disk větší než dvojnásobek počtu diskových hlav, je na disku úzké hrdlo. Hlavním alternativním řešením je vytvořit fulltextové katalogy, které jsou oddělené od souborů a protokolů databáze SQL Serveru. Umístěte protokoly, soubory databáze a fulltextové katalogy na samostatné disky. Instalace rychlejších disků a použití raidu může také pomoct zlepšit výkon indexování.

  Poznámka

  Počínaje systémem SQL Server 2008 (10.0.x) může modul Full-Text používat paměť AWE, protože modul Full-Text je součástí procesu sqlservr.exe. Další informace najdete v tématu Full-Text architektury vyhledávání.

Problémy s dávkovým zpracováním fulltextu

Pokud systém nemá žádné hardwarové kritické body, indexování výkonu fulltextového vyhledávání většinou závisí na následujících:

• Jak dlouho trvá SQL Serveru vytvořit fulltextové dávky.

• Jak rychle může démon filtru tyto dávky zpracovávat.

Problémy s populací fulltextového indexu

• typ populace. Na rozdíl od úplného počtu obyvatel nejsou přírůstkové, ruční a automatické sledování změn navrženy tak, aby maximalizovaly hardwarové prostředky, aby se dosáhlo rychlejší rychlosti. Návrhy ladění v tomto tématu proto nemusí zvýšit výkon fulltextového indexování při použití přírůstkového, ručního nebo automatického sledování změn populace.

• hlavní sloučení. Po dokončení populace se aktivuje závěrečný proces sloučení, který sloučí fragmenty indexu do jednoho hlavního fulltextového indexu. Výsledkem je vyšší výkon dotazů, protože pouze hlavní index je potřeba dotazovat místo počtu fragmentů indexů a lepší bodovací statistiky se dají použít pro hodnocení relevance. Hlavní sloučení ale může být náročné na vstupně-výstupní operace, protože při sloučení fragmentů indexu je nutné zapsat a číst velké objemy dat, i když neblokuje příchozí dotazy.

  Ovládání sloučení velkého množství dat může vytvořit dlouhotrvající transakci a zpozdit zkrácení transakčního logu během kontrolního bodu. V tomto případě se v rámci úplného modelu obnovení může transakční protokol výrazně zvětšit. Osvědčeným postupem je před změnou uspořádání velkého fulltextového indexu v databázi, která používá úplný model obnovení, zajistit, aby váš transakční protokol obsahoval dostatek místa pro dlouho běžící transakci. Další informace naleznete v tématu Správa velikosti souboru transakčního protokolu.

Ladění výkonu fulltextových indexů

Pokud chcete maximalizovat výkon fulltextových indexů, implementujte následující osvědčené postupy:

• Pokud chcete použít všechny procesory nebo jádra na maximum, nastavte sp_configure „maximální rozsah fulltextového procházení“ na počet CPU v systému. Pro informace o této možnosti konfigurace serveru, viz maximální rozsah fulltextového procházení.

• Ujistěte se, že základní tabulka obsahuje clusterovaný index. Pro první sloupec clusterovaného indexu použijte celočíselné datové typy. Nepoužívejte identifikátory GUID v prvním sloupci clusterovaného indexu. Počet obyvatel s více rozsahy v clusterovém indexu může způsobit nejvyšší rychlost populace. Doporučujeme, aby sloupec, který slouží jako fulltextový klíč, byl celočíselným datovým typem.

• Aktualizujte statistiku základní tabulky pomocí příkazu UPDATE STATISTICS. Je důležitější aktualizovat statistiky pro clusterovaný index nebo fulltextový klíč pro úplnou populaci. To pomáhá populaci s různými rozsahy vytvářet dobré segmenty v tabulce.

• Před provedením úplného naplnění na výkonném počítači s více procesory doporučujeme dočasně omezit velikost fondu vyrovnávací paměti nastavením hodnoty maximální paměti serveru, aby zůstal dostatek paměti pro proces fdhost.exe a pro využití operačním systémem. Další informace najdete v části Odhadování požadavků na paměť hostitelského procesu démona filtru (fdhost.exe), v pozdější části tohoto tématu.

• Pokud použijete přírůstkovou populaci založenou na sloupci časového razítka, vytvořte sekundární index na časové razítko sloupci, abyste zlepšili výkon přírůstkového souboru.

Diagnostikovat výkon kompletních populací

Projděte si protokoly úplného procházení textu

Pokud chcete pomoct s diagnostikou problémů s výkonem, podívejte se na protokoly procházení fulltextu.

Když během procházení dojde k chybě, zařízení pro protokolování prohledávání Full-Text vytvoří a udržuje protokol procházení, což je soubor ve formátu prostého textu. Každý protokol procházení odpovídá určitému fulltextovému katalogu. Ve výchozím nastavení se protokoly procházení pro danou instanci (v tomto příkladu výchozí instance) nacházejí ve složce %ProgramFiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\LOG.

Schéma pojmenování souboru protokolu procházení je následující:

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

Proměnné části názvu souboru protokolu procházení jsou následující.

• < ID databáze> – ID databáze. < dbid> je pěticiferné číslo s počátečními nulami.
• < FullTextCatalogID> – ID fulltextového katalogu. < catid> je pěticiferné číslo s počátečními nulami.
• < n> – je celé číslo, které označuje jeden nebo více protokolů procházení stejného fulltextového katalogu.

Například SQLFT0000500008.2 je soubor protokolu procházení databáze s ID databáze = 5 a ID fulltextového katalogu = 8. Hodnota 2 na konci názvu souboru označuje, že pro tuto dvojici databáze nebo katalogu existují dva soubory protokolu procházení.

Kontrola využití fyzické paměti

Během plnění celé textové databáze může dojít k nedostatku paměti nebo k úplnému vyčerpání paměti u fdhost.exe nebo sqlservr.exe.

• Pokud protokol procházení fulltextu ukazuje, že fdhost.exe se často restartuje nebo že se vrací kód chyby 8007008, znamená to, že některému z těchto procesů dochází paměť.
• Pokud fdhost.exe vytváří výpisy paměti, zejména na velkých počítačích s více procesory, může mu docházet paměť.
• Informace o vyrovnávacích pamětích používaných při procházení fulltextu najdete v tématu sys.dm_fts_memory_buffers (Transact-SQL).

Možné příčiny problémů s nedostatkem nebo vyčerpáním paměti jsou následující:

• nedostatek paměti. Pokud je velikost fyzické paměti, která je k dispozici během úplného zaplnění, nula, může vyrovnávací paměť SQL Serveru využívat většinu fyzické paměti v systému.

  Proces sqlservr.exe se pokusí získat veškerou dostupnou paměť pro fond vyrovnávací paměti až do nakonfigurované maximální paměti serveru. Pokud je maximální velikost paměti serveru přidělení příliš velká, může dojít k nedostatku paměti a selhání přidělení sdílené paměti pro proces fdhost.exe.

  Tento problém můžete vyřešit tak, že nastavíte maximální paměť serveru hodnotu fondu vyrovnávací paměti SQL Serveru odpovídajícím způsobem. Další informace naleznete v části odhady paměťových požadavků procesu démona filtru (fdhost.exe), dále v tomto tématu. Snížení velikosti dávky používané pro fulltextové indexování může také pomoct.

• konflikt přístupu k paměti. Během procesu fulltextové distribuce na počítači s více procesory může dojít ke kolizi vyrovnávací paměti poolu mezi fdhost.exe a/nebo sqlservr.exe. Výsledný nedostatek sdílené paměti způsobuje opakované dávkové zpracování, výkonové ztráty kvůli paměti a výpisy způsobené procesem fdhost.exe.

• problémy se stránkováním. Nedostatečná velikost stránkového souboru, například v systému s malým stránkovým souborem s omezeným růstem, může také způsobit vyčerpání paměti u fdhost.exe nebo sqlservr.exe. Pokud protokoly procházení nenaznačují žádné chyby související s pamětí, je pravděpodobné, že kvůli nadměrnému stránkování je výkon pomalý.

Odhad požadavků na paměť procesu hostitele démona filtru (fdhost.exe)

Množství paměti vyžadované procesem fdhost.exe pro populaci závisí hlavně na počtu rozsahů fulltextového prohledávání, které používá, velikosti příchozí sdílené paměti (ISM), a maximálním počtu instancí ISM.

Velikost paměti (v bajtech) spotřebovaná hostitelem démona filtru může být přibližně odhadována pomocí následujícího vzorce:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

Výchozí hodnoty proměnných v předchozím vzorci jsou následující:

proměnná	Výchozí hodnota
počet_rozsahů_procházení	Počet procesorů
ism_size	1 MB pro počítače x86 4 MB, 8 MB nebo 16 MB pro počítače x64 v závislosti na celkové fyzické paměti
max_outstanding_isms	25 pro počítače x86 5 pro počítače x64

Následující tabulka obsahuje pokyny k odhadu požadavků na paměť fdhost.exe. Vzorce v této tabulce používají následující hodnoty:

• F, což je odhad paměti potřebné fdhost.exe (v MB).

• T, což je celková fyzická paměť dostupná v systému (v MB).

• M, což je optimální nastavení maximální paměti serveru.

Základní informace o následujících vzorcích najdete v poznámkách, které následují v tabulce.

Platforma	Odhad požadavků na paměť fdhost.exe v MB–F^1	Vzorec pro výpočet maximální paměti serveru –M^2
x86	F = Počet rozsahů procházení * 50	M =minimum(T, 2000) - F - 500
x64	F = Počet rozsahů procházení * 10 * 8	M = T - F - 500

Poznámky ke vzorcům

1. Pokud probíhá více celých populací, vypočítejte fdhost.exe požadavky na paměť každého samostatně, jak je F1, F2atd. Pak M vypočítat jako T- sigma**(_F_i)**.
2. 500 MB je odhad paměti vyžadované jinými procesy v systému. Pokud systém provádí další práci, odpovídajícím způsobem tuto hodnotu zvyšte.
3. .ism_size se předpokládá, že pro platformy x64 bude 8 MB.

Příklad: Odhad požadavků na paměť fdhost.exe

Tento příklad je určený pro 64bitový počítač, který má 8 GB paměti RAM a 4 procesory se 4 dvěma jádry. První výpočetní odhady paměti potřebné pro fdhost.exe -F. Počet rozsahů procházení je 8.

F = 8*10*8 = 640

Další výpočet získá optimální hodnotu pro maximální paměť serveru -M. Celková fyzická paměť dostupná v tomto systému v MB -T- je 8192.

M = 8192-640-500 = 7052

Příklad: Nastavení maximální paměti serveru

Tento příklad používá příkazy sp_configure a RECONFIGURE Transact-SQL k nastavení maximální paměti serveru na hodnotu vypočítanou pro M v předchozím příkladu 7052:

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

Pro více informací o možnostech paměti serveru viz Server Memory Server Configuration Options.

Kontrola využití procesoru

Výkon úplných populací není optimální, pokud je průměrná spotřeba procesoru nižší než přibližně 30 procent. Tady jsou některé faktory, které ovlivňují spotřebu procesoru.

• Vysoká doba čekání na stránky

  Pokud chcete zjistit, jestli je doba čekání na stránku vysoká, spusťte následující příkaz Transact-SQL:

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

  Následující tabulka popisuje typy čekání, které jsou zde zajímavé.

  Typ čekání	Popis	Možné řešení
  PAGEIO_LATCH_SH (_EX nebo _UP)	To může znamenat kritický bod vstupně-výstupních operací, v takovém případě byste obvykle viděli také vysokou průměrnou délku fronty disku.	Přesunutí fulltextového indexu do jiné skupiny souborů na jiném disku může pomoct snížit kritické body vstupně-výstupních operací.
  PAGELATCH_EX (nebo _UP)	To může znamenat velké množství kolizí mezi vlákny, které se pokouší zapisovat do stejného databázového souboru.	Přidání souborů do skupiny souborů, ve které se nachází fulltextový index, by mohlo pomoct zmírnit takové kolize.

  Další informace najdete v sys.dm_os_wait_stats (Transact-SQL).

• Neefektivita při skenování základní tabulky

  Úplná populace prohledá základní tabulku a vytvoří dávky. Tato kontrola tabulek může být neefektivní v následujících scénářích:

  • Pokud základní tabulka obsahuje vysoké procento sloupců uložených mimo řádky, které jsou indexovány fulltextem, může být skenování základní tabulky pro účely vytváření dávek omezením výkonu. V tomto případě může pomoct přesun menších dat v řádku pomocí varchar(max) nebo nvarchar(max).

  • Pokud je základní tabulka velmi fragmentovaná, může být prohledávání neefektivní. Informace o fragmentaci indexů a dat mimo řádky a o jejich výpočtu najdete v tématu sys.dm_db_partition_stats (Transact-SQL) a sys.dm_db_index_physical_stats (Transact-SQL).

    Pokud chcete snížit fragmentaci, můžete přeuspořádat nebo znovu sestavit clusterovaný index. Další informace naleznete v tématu změna uspořádání a opětovného sestavení indexů.

Řešení potíží s pomalým indexováním dokumentů

Poznámka

Tato část popisuje problém, který se týká jenom zákazníků, kteří indexují dokumenty (například dokumenty Aplikace Microsoft Word), ve kterých jsou vložené jiné typy dokumentů.

Modul Full-Text používá při naplnění fulltextového indexu dva typy filtrů: filtry s více vlákny a filtry s jedním vláknem.

• Některé dokumenty, například dokumenty Aplikace Microsoft Word, se filtrují pomocí vícevláknového filtru.
• Jiné dokumenty, jako jsou dokumenty Adobe Acrobat Portable Document Format (PDF), se filtrují pomocí filtru s jedním vláknem.

Pro bezpečnostní důvody jsou filtry načítány procesy hostitele démona filtru. Instance serveru používá vícevláknový proces pro všechny filtry s více vlákny a proces s jedním vláknem pro všechny filtry s jedním vláknem. Pokud dokument, který používá vícevláknový filtr obsahuje vložený dokument, který používá filtr s jedním vláknem, spustí modul Full-Text proces s jedním vláknem pro vložený dokument. Například při výskytu wordového dokumentu, který obsahuje dokument PDF, modul Full-Text používá vícevláknový proces pro obsah Wordu a spustí proces s jedním vláknem pro obsah PDF. Filtr s jedním vláknem ale nemusí v tomto prostředí dobře fungovat a mohl by proces filtrování stabilizovat. Za určitých okolností, kdy je takové vkládání běžné, může destabilizace vést k pádu procesu. Když k tomu dojde, modul Full-Text znovu směruje všechny neúspěšné dokumenty – například wordový dokument, který obsahuje vložený obsah PDF – do procesu filtrování s jedním vláknem. Pokud k opětovnému směrování dochází často, vede ke snížení výkonu procesu fulltextového indexování.

Chcete-li tento problém vyřešit, označte filtr pro dokument kontejneru (dokument aplikace Word v tomto příkladu) jako filtr s jedním vláknem. Pokud chcete filtr označit jako filtr s jedním vláknem, nastavte hodnotu registru ThreadingModel filtru na Apartment Threaded. Informace o jednovláknových apartmánech naleznete v dokumentu white paper Understanding and Using COM Threading Models.

Viz také

Možnosti konfigurace paměti serveru
Možnost konfigurace serveru pro maximální rozsah fulltextového procházení
naplnění indexů Full-Text
vytváření a správa indexů Full-Text
sys.dm_fts_memory_buffers (Transact-SQL)
sys.dm_fts_memory_pools (Transact-SQL)
Řešení potíží Full-Text indexování
architektura vyhledávání Full-Text