Javítsa a teljes szöveges indexek teljesítményét

A következőkre vonatkozik:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Ez a cikk bemutatja a teljes szöveges indexek és lekérdezések gyenge teljesítményének gyakori okait, valamint azokat a csökkentést.

A teljesítményproblémák gyakori okai

Ez a rész a teljes szöveges indexek használatakor gyakori teljesítményproblémák okát írja le.

Hardvererőforrás-problémák

A hardveres erőforrások, mint a memória, lemez sebessége, CPU sebessége és gépi architektúra, befolyásolják a teljes szöveges indexelések és a teljes szöveges lekérdezések teljesítményét.

A hardveres erőforrás-korlátok csökkentik a teljes szöveges indexelési teljesítményt.

• CPU. Ha a szűrődémon-gazdafolyamat (fdhost.exe) vagy az SQL Server folyamatának (sqlservr.exe) CPU-használata megközelíti a 100 százalékot, akkor a CPU a szűk keresztmetszet.

• Memória. A fizikai memóriahiány szűk keresztmetszetet okozhat.

• Lemez. Ha az átlagos lemezvárakozási soridő hossza kétszeresebb, mint a lemezfejek száma, akkor szűk keresztmetszet van a lemezen. Az elsődleges kerülőmegoldásként a teljes szövegű katalógusokat úgy kell létrehozni, hogy azok különállóak legyenek az SQL Server adatbázisfájloktól és naplóktól. Helyezze a naplókat, adatbázisfájlokat és teljes szöveges katalógusokat külön lemezekre. A gyorsabb lemezek telepítése és a RAID használata szintén segíthet az indexelési teljesítmény javításában.

Problémák a teljes szöveg kötegelt feldolgozásával

Ha a rendszernek nincsenek hardveres szűk keresztmetszetei, a teljes szöveges keresés indexelési teljesítménye főként a következő tényezőktől függ:

• Mennyi időbe telik a Database Engine-nek teljes szöveges adagok létrehozása.

• Milyen gyorsan fogyasztja el a szűrődémon-folyamat azokat a kötegeket.

Teljes szöveges indexpopulációval kapcsolatos problémák

• Populáció típusa. A teljes népességgel ellentétben az inkrementális, manuális és automatikus változáskövető populáció nem arra van tervezve, hogy maximalizálja a hardveres erőforrásokat a gyorsabb sebesség eléréséhez. Ezért a cikkben szereplő hangolási javaslatok nem feltétlenül javítják a teljes szöveges indexelést, ha az inkrementális, manuális vagy automatikus változáskövető populációt használ.

• Fő egyesítés. Amikor a populálás befejeződik, egy végső összevonási folyamat az indextöredékeket egyetlen master teljes szöveges indexszé egyesíti. Ez a folyamat javítja a lekérdezési teljesítményt, mivel csak a fő indexet kell lekérdezni, nem pedig több indexfragmentumot. Jobb pontozási statisztikákat lehet használni relevancia rangsorolásában. Azonban a master merge lehet I/O intenzív, mivel nagy mennyiségű adatot kell írni és olvasni, amikor indexfragmentumokat egyesítenek. Bár nem blokkolja a bejövő lekérdezéseket.

  Nagy mennyiségű adat master merge-je hosszan futó tranzakciót hozhat létre, ami késlelteti a tranzakciónapló csonkítását az ellenőrzőpont során. Ebben az esetben a teljes helyreállítási modell alatt a tranzakciónapló jelentősen növekedhet. Ajánlott eljárásként a teljes helyreállítási modellt használó adatbázisokban lévő nagy, teljes szöveges index átrendezése előtt győződjön meg arról, hogy a tranzakciónapló elegendő helyet tartalmaz egy hosszú ideig futó tranzakcióhoz. További információ: A tranzakciós naplófájl méretének kezelése.

A teljes szöveges indexek teljesítményének finomhangolása

A teljes szöveges indexek teljesítményének maximalizálása érdekében hajtsa végre az alábbi ajánlott eljárásokat:

• Az összes CPU-mag maximális kihasználásához módosítsa a(z) max full-text crawl range értékét a rendszerben található magok számára. További információkért lásd: Kiszolgáló konfigurációja: a teljes szöveges bejárás maximális tartománya.

• Győződjön meg arról, hogy az alaptábla fürtözött indexet tartalmaz. Használjon egész adattípust a klaszterezett index első oszlopához. Kerülje a GUID-k használatát a csoportosított index első oszlopában. A csoportosított index többtartományú sokasága a legnagyobb lekérdezési sebességet eredményezheti. Használj egész szám adattípust az oszlophoz, amely teljes szöveges kulcsként szolgál.

• Frissítse az alaptábla statisztikáit az UPDATE STATISTICS utasítás használatával. A legfontosabb, hogy frissítse a klaszterezett index vagy a teljes szöveg kulcsának statisztikáit a teljes populációhoz. Ez a művelet segít egy többtartományos populációnak jó partíciókat létrehozni a táblán.

• Mielőtt teljes populációt végeznél egy nagy többmagos számítógépen, ideiglenesen korlátozd a pufferpool méretét azzal, hogy beállítsd az max server memory értéket, hogy elegendő memóriát hagyjon a fdhost.exe folyamat és az operációs rendszer használatához. További információért lásd: A szűrő démon gazdafolyamat memóriaigényeinek becslése (fdhost.exe) a cikk későbbi részében.

• Ha növekményes sokaságot használ egy időbélyegoszlop alapján, hozzon létre egy másodlagos indexet a időbélyeg oszlopra a növekményes sokaság teljesítményének javítása érdekében.

Teljes populációk teljesítményének hibaelhárítása

A következő szakaszban a teljes populációval kapcsolatos teljesítményproblémák megoldására hivatkozhatunk.

A teljes szöveges bejárási naplók megtekintése

A teljesítményproblémák diagnosztizálásához tekintse át a teljes szövegű feltérképezési naplókat.

Ha egy bejárás során hiba történik, a Full-Text Keresési bejárás naplózási létesítmény létrehoz és karbantart egy bejárási naplót, amely egy egyszerű szöveges fájl. Minden bejárási napló egy adott teljes szöveges katalógusnak felel meg. Alapértelmezés szerint egy adott példány bejárási naplói (ebben a példában az alapértelmezett példány) %ProgramFiles%\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\LOG mappában találhatók.

A bejárási naplófájl a következő elnevezési sémát követi:

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

A bejárási naplófájl nevének változó részei a következők.

• <DatabaseID>: Az adatbázis azonosítója, vezető nullákkal ellátott ötjegyű számként.

• <FullTextCatalogID>: Teljes szövegű katalógus azonosító, öt jegyjegyű szám első nullákkal.

• <n>: Egy egész szám, amely azt jelzi, hogy ugyanazon teljes szövegű katalógusból egy vagy több crawl log létezik.

A SQLFT0000500008.2 például egy adatbázis bejárási naplófájlja, amelynek adatbázis-azonosítója = 5, a teljes szöveges katalógus azonosítója pedig = 8. A fájlnév végén lévő 2 azt jelzi, hogy az adatbázis-/katalóguspár két bejárási naplófájlt tartalmaz.

Fizikai memória használatának ellenőrzése

Teljes szöveges populáció esetén az fdhost.exe or sqlservr.exe folyamat memóriája elfogyhat, vagy akár kifogyhat a memóriából.

• Ha a teljes szöveges crawl napló azt mutatja, hogy fdhost.exe gyakran újraindul vagy 8007008 hibakódot ad vissza, az azt jelenti, hogy valamelyik folyamat kifogyik a memóriából.

• Ha fdhost.exe dumpokat eredményez, különösen nagy, többmagos rendszereken, akkor a memória kifogyhat.

• A teljes szöveges crawl által használt memóriapufferekről információért lásd: sys.dm_fts_memory_buffers.

Az alacsony memória vagy a memóriahiány lehetséges okai a következők:

• kevés memória. Ha a teljes populáció alatt elérhető fizikai memória mennyisége nulla, akkor a Database Engine buffer pool a rendszer fizikai memóriájának nagy részét fogyaszthatja.

  A sqlservr.exe folyamat megpróbálja megragadni a pufferkészlet összes rendelkezésre álló memóriáját a kiszolgáló konfigurált maximális memóriájához. Ha az max server memory allokáció túl nagy, memóriahiányos állapotok és megosztott memória elmaradása előfordulhat a fdhost.exe folyamatban.

  Állítsd be max server memory megfelelően a Database Engine pufferpool értékét ennek a problémának a megoldásához. További információért lásd: A szűrő démon gazdafolyamat memóriaigényeinek becslése (fdhost.exe) a cikk későbbi részében. A teljes szöveges indexeléshez használt batch méret csökkentése is segíthet.

• memória-versengés. Teljes szöveges populáció során egy többmagos rendszeren fdhost.exe , és sqlservr.exe versenyezhet a pufferpool memóriáért. A megosztott memória hiánya a folyamat során kötött újrajátszásokat, memória áttörést és dumpokat fdhost.exe okoz.

• lapozási problémák. Az oldalfájl mérete nem elég, például egy olyan rendszeren, ahol kis oldalfájl van korlátozott növekedéssel, szintén okozhat az fdhost.exe or sqlservr.exe folyamat memóriájának kifogyását. Ha a crawl naplók nem mutatnak memóriahibákat, akkor a túlzott lapolás valószínűleg lassú teljesítményt okoz.

Becsüld meg a szűrő démon gazdafolyamatának memóriaigényét (fdhost.exe)

A folyamatnak a feltöltéshez szükséges memória fdhost.exe mennyisége főként a teljes szöveges crawl-tartományok számától, a bejövő megosztott memória (ISM) méretétől és az ISM példányok maximális számától függ.

A szűrő démon gazda memóriafogyasztását nagyjából becslést lehet becslni a következő képlettel:

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

Az előző képlet változóinak alapértelmezett értékei a következők:

Az alábbi táblázat iránymutatásokat mutat be a memória követelményeinek becsléséhez.fdhost.exe A táblázatban szereplő képletek a következő értékeket használják:

• F, amely a fdhost.exe számára szükséges memória becsült értéke (MB-ban).

• T, amely a rendszeren elérhető teljes fizikai memória (MB-ban).

• M, ami az optimális max server memory beállítás.

Az alábbi képletekkel kapcsolatos alapvető információkért tekintse meg a táblázatot követő megjegyzéseket.

1. Ha több teljes populáció zajlik, számoljuk ki mindegyik fdhost.exe memóriaigényét külön-külön, F1, F2 és így tovább. Ezután számoljuk ki M-etT - Σ(Fi)-ként.

2. Az 500 MB a rendszer más folyamatai által igényelt memória becslése. Ha a rendszer további munkát végez, ennek megfelelően növelje ezt az értéket.

3. ism_size feltételezhetően 8 MB x64 platformoknál.

Példa: Becsülje meg a(z) fdhost.exe memóriaigényét.

Ez egy 64 bites számítógép esetében van, amely 8 GB RAM-mal és 4 kétmagos processzorral rendelkezik. Az első számítás megbecsüli a fdhost.exeF számára szükséges memóriát. A bejárási tartományok száma 8.

F = 8 * 10 * 8 = 640

A következő számítás kiszámítja max server memory (M) optimális értékét. A rendszeren elérhető teljes fizikai memória mérete MB-ban, (T): 8192.

M = 8192 - 640 - 500 = 7052

Példa: Beállítás max server memory

Ez a példa a sp_configure és RECONFIGURE Transact-SQL állításokat használja, hogy max server memory az előző példában M-re számított értéket állítsák: 7052

USE master;
GO

EXECUTE sp_configure 'max server memory', 7052;
GO

RECONFIGURE;
GO

További információért a szervermemória opciókról lásd: Szervermemória konfigurációs opciók.

Cpu-használat ellenőrzése

A teljes populációk teljesítménye nem optimális, ha az átlagos CPU-fogyasztás körülbelül 30 százaléknál alacsonyabb. Az alábbiakban néhány tényezőt talál, amelyek befolyásolják a processzorhasználatot.

• Oldalak magas várakozási ideje

  Annak megállapításához, hogy az oldal várakozási ideje magas-e, futtassa a következő Transact-SQL utasítást:

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

  Az alábbi táblázat az érdekes várakozási típusokat ismerteti.

  Várakozás típusa	Leírás	Lehetséges megoldás
  PAGEIO_LATCH_SH (_EX vagy _UP)	Ez a várakozási típus az I/O-műveletekben jelentkező szűk keresztmetszetre utalhat, ilyenkor általában magas az átlagos lemezvárólista-hossz is.	A teljes szöveges index áthelyezése egy másik fájlcsoportba egy másik lemezen segíthet csökkenteni az I/O szűk keresztmetszetét.
  PAGELATCH_EX (vagy _UP)	Ez a várakozási típus sok ellentétet jelezhet a szálak között, amelyek ugyanarra az adatbázis-fájlra próbálnak írni.	Fájlok hozzáadása a teljes szöveges index fájlcsoporthoz segíthet enyhíteni az ilyen vitákat.

  További információ: sys.dm_os_wait_stats.

• Az alaptábla szkennelésében fellépő hatékonysági problémák

  A teljes állomány átvizsgálja az alaptáblát kötegek előállításához. Ez a táblázatszkennelés az alábbi esetekben hatástalan lehet:

  • Ha az alaptábla nagy százalékban tartalmazza a soron kívüli oszlopokat, amelyek teljes szöveges indexelése folyamatban van, akkor az alaptábla kötegek előállításához való vizsgálata szűk keresztmetszetet jelenthet. Ebben az esetben segíthet, ha a kisebb adatokat sorban mozgatjuk varchar(max) vagy nvarchar(max) használatával.

  • Ha az alaptábla nagyon töredezett, előfordulhat, hogy a vizsgálat nem hatékony. A soron kívüli adatok és az index fragmentáció számításáról információért lásd sys.dm_db_partition_stats és sys.dm_db_index_physical_stats.

    A töredezettség csökkentése érdekében átrendezheti vagy újraépítheti a fürtözött indexet. További információ: Indexkarbantartás optimalizálása a lekérdezési teljesítmény javítása és az erőforrás-felhasználás csökkentése érdekében.

Dokumentumok lassú indexelésének hibaelhárítása

A Full-Text motor két szűrőtípust használ, amikor teljes szöveges indexet tölt fel: többszálú szűrőket és egyszálú szűrőket.

• Néhány dokumentum, például a Word dokumentumok, többszálas szűrőt használnak.
• Más dokumentumok, például az Adobe Acrobat Portable Document Format (PDF) dokumentumok, egyszálas szűrőket használnak.

Biztonsági okokból a szűrőket a szűrődémon gazdagép folyamatai töltik be. A kiszolgálópéldány többszálas folyamatot használ az összes többszálas szűrőhöz, és egyszálas folyamatot az összes egyszálas szűrőhöz. Ha egy többszálas szűrőt használó dokumentum egy egyszálas szűrőt használó beágyazott dokumentumot tartalmaz, a Full-Text motor elindít egy egyszálas folyamatot a beágyazott dokumentumhoz. Ha például egy PDF-dokumentumot tartalmazó Word-dokumentumot talál, a Full-Text motor a Word-tartalom többszálú folyamatát használja, és elindít egy egyszálú folyamatot a PDF-tartalomhoz. Azonban egy egyszálas szűrő ebben a környezetben nem feltétlenül működik jól, és destabilizálhatja a szűrési folyamatot.

Bizonyos esetekben, amikor az ilyen beágyazás gyakori, a destabilizálás a folyamat összeomlásához vezethet. Amikor ez a feltétel bekövetkezik, a Full-Text Engine átirányítja a meghibásodott dokumentumot (például egy Word dokumentumot, amely beágyazott PDF tartalmat tartalmaz) az egyszálas szűrőfolyamatba. Ha gyakran történik újrairányítás, az a teljes szöveges indexelési folyamat teljesítménycsökkenéséhez vezet.

Ennek a problémának a megkerüléséhez jelöljük meg a konténer dokumentum szűrőjét (ebben a példában a Word dokumentumot) egyszálas szűrőként. Ha egy szűrőt egyszálas szűrőként szeretne megjelölni, állítsa a szűrő ThreadingModel beállításazonosítóját Apartment Threaded értékre. Az egyszálas lakásokról szóló információkért lásd: A COM szálas modellek megértése és használata.

Kapcsolódó tartalom

• kiszolgáló memóriakonfigurációs beállításai
• Szerver konfiguráció: maximális teljes szöveges crawl tartomány
• Full-Text indexek feltöltése
• Teljes szöveges indexek létrehozása és kezelése
• sys.dm_fts_memory_buffers (Transact-SQL)
• sys.dm_fts_memory_pools (Transact-SQL)
• Teljes szöveges indexelés hibaelhárítása
• Full-Text Keresési architektúra