Průvodce architekturou vláken a úloh

platí pro:SQL ServerAzure SQL Databaseazure SQL Managed Instance

Plánování úkolů operačního systému

Vlákna jsou nejmenší jednotky zpracování spuštěné operačním systémem a umožňují oddělení logiky aplikace do několika souběžných cest provádění. Vlákna jsou užitečná, když mají složité aplikace mnoho úloh, které lze provádět současně.

Když operační systém spustí instanci aplikace, vytvoří jednotku označovanou jako proces pro správu instance. Proces má vlákno provádění. Toto je série programovacích instrukcí prováděných kódem aplikace. Pokud má například jednoduchá aplikace jednu sadu instrukcí, které lze provádět sériově, je tato sada instrukcí zpracována jako jeden úkola existuje pouze jedna cesta spuštění (nebo vlákno) prostřednictvím aplikace. Složitější aplikace mohou mít několik úloh, které je možné provádět souběžně místo sériově. Aplikace to může provést spuštěním samostatných procesů pro každou úlohu, což je operace náročná na prostředky, nebo spustit samostatná vlákna, která jsou relativně méně náročná na prostředky. Kromě toho lze každé vlákno naplánovat pro spuštění nezávisle na ostatních vláknech přidružených k procesu.

Vlákna umožňují složitým aplikacím efektivnější využití procesoru (CPU), dokonce i na počítačích, které mají pouze jeden procesor. S jedním procesorem může být najednou vykonáváno pouze jedno vlákno. Pokud jedno vlákno spustí dlouhotrvající operaci, která nepoužívá procesor, například čtení nebo zápis disku, může další vlákno provést, dokud se nedokončí první operace. Díky možnosti spouštět vlákna, zatímco ostatní vlákna čekají na dokončení operace, může aplikace maximalizovat využití procesoru. To platí zejména pro aplikace náročné na vstupně-výstupní operace pro více uživatelů, jako je databázový server. Počítače s více procesory mohou současně spouštět jedno vlákno na procesor. Pokud má například počítač osm procesorů, může současně spouštět osm vláken.

Plánování úloh SQL Serveru

V rámci SQL Serveru je požadavek logickým znázorněním dotazu nebo dávkového úkolu. Požadavek také představuje operace vyžadované systémovými vlákny, jako je kontrolní bod nebo zapisovač protokolů. Požadavky existují v různých stavech po celou dobu jejich životnosti a mohou nahromadět čekání, když prostředky potřebné ke spuštění požadavku nejsou k dispozici, například uzamkne nebo západky. Další informace o stavech žádostí najdete v tématu sys.dm_exec_requests.

Úkoly

úkol představuje jednotku práce, kterou je potřeba dokončit, aby bylo možné požadavek splnit. Jeden nebo více úkolů je možné přiřadit k jednomu požadavku.

• Paralelní požadavky mají několik aktivních úkolů, které se spouští souběžně místo sériově, s jedním nadřazeným úkolem (nebo koordinačním úkolem) a více podřízenými úkoly. Výkonný plán pro paralelní požadavek může obsahovat sériové větve – oblasti plánu s operátory, které neprobíhají paralelně. Nadřazená úloha je zodpovědná také za provádění těchto sériových operací.
• Sériové požadavky mají během provádění pouze jednu aktivní úlohu v libovolném časovém okamžiku. Úkoly existují v různých státech po celou dobu jejich života. Další informace o stavech úkolů naleznete v tématu sys.dm_os_tasks. Úlohy ve stavu SUSPENDED čekají na prostředky potřebné ke spuštění úlohy, aby byly k dispozici. Další informace o čekajících úkolech viz sys.dm_os_waiting_tasks.

Dělníci

SQL Server pracovní vlákno, označované také jako pracovní nebo vlákno, je logické znázornění vlákna operačního systému. Při spouštění sériových požadavkůvytvoří databázový stroj SQL Serveru pracovní proces, který spustí aktivní úlohu (1:1). Při provádění paralelních požadavků v řádkovém režimudatabázový stroj SQL Serveru přiřazuje pracovníka, který koordinuje podřízené pracovní procesy zodpovědné za provádění jim přiřazených úkolů (také 1:1), a toto se nazývá nadřazené vlákno (nebo koordinační vlákno). Nadřazené vlákno má přidruženou nadřazenou úlohu. Nadřazené vlákno je bodem vstupu požadavku a existuje ještě před tím, než modul parsuje dotaz. Hlavními povinnostmi nadřazeného vlákna jsou:

• Koordinovat paralelní skenování
• Spusťte paralelní dělníky.
• Shromážděte řádky z paralelních vláken a odešlete je klientovi.
• Proveďte místní a globální agregace.

Poznámka

Pokud má plán dotazu sériové a paralelní větve, zodpovídá jeden z paralelních úloh za provádění sériové větve.

Počet pracovních vláken vytvářených pro jednotlivé úlohy závisí na:

• Zda požadavek měl nárok na paralelismus určený optimalizátorem dotazů.

• Jaký je skutečný dostupný stupeň paralelismu (DOP) v systému na základě aktuálního zatížení. To se může lišit od odhadovaného DOP, který je založený na konfiguraci serveru pro maximální stupeň paralelismu (MAXDOP). Například konfigurace serveru pro MAXDOP může být 8, ale dostupný DOP za běhu může být pouze 2, což má vliv na výkon dotazů. Zatížení paměti a nedostatek pracovníků jsou dvě podmínky, které snižují dostupnost DOP během doby běhu.

Poznámka

maximální stupeň paralelismu (MAXDOP) limit je nastavený na každou úlohu, ne na požadavek. To znamená, že během paralelního provádění dotazů může jeden požadavek vytvořit více úloh až do limitu MAXDOP a každý úkol bude používat jeden pracovní proces. Další informace o maxDOP naleznete v tématu Konfigurace maximálního stupně paralelismu Server Configuration Option.

Plánovače

Plánovač , označovaný také jako plánovač SOS, spravuje pracovní vlákna, která vyžadují dobu zpracování pro provádění práce jménem úkolů. Každý plánovač je mapován na jednotlivé procesory (CPU). Čas, kdy může pracovník zůstat aktivní v plánovači, se nazývá kvantum OS s maximálně 4 ms. Po vypršení kvantového času předá pracovník svůj čas jiným pracovníkům, kteří potřebují přístup k prostředkům procesoru, a změní svůj stav. Tato spolupráce mezi pracovníky, která maximalizuje přístup k prostředkům procesoru, se nazývá kooperativní plánování, označované také jako nepreemptivní plánování. Změna stavu pracovníka se pak rozšíří do úkolu přidruženého k danému pracovníkovi a do požadavku přidruženého k úkolu. Další informace o stavech pracovníků najdete v tématu sys.dm_os_workers. Další informace o plánovačích najdete v tématu sys.dm_os_schedulers.

V souhrnu může žádost vytvořit jeden nebo více úkolů, provádět jednotky práce. Každý úkol je přiřazený pracovnímu vláknu, který je zodpovědný za dokončení úkolu. Každé pracovní vlákno musí být naplánováno (umístěné v plánovači) pro aktivní spuštění úlohy.

Představte si následující scénář:

• Pracovník 1 je dlouhotrvající úloha, například dotaz pro čtení s využitím read-ahead u tabulek založených na disku. Pracovní proces 1 najde požadované datové stránky, které už jsou ve fondu vyrovnávací paměti, takže nemusí čekat na vstupně-výstupní operace a může před výnosem spotřebovat své úplné kvantové stránky.
• Pracovník 2 provádí kratší úlohy v submilisekundách a proto je nutné, aby uvolnil před vyčerpáním svého plného kvanta.

V tomto scénáři a až do SQL Serveru 2014 (12.x) je Worker 1 povolen prakticky monopolizovat plánovač tím, že má více celkového kvantového času.

Počínaje SQL Serverem 2016 (13.x) zahrnuje kooperativní plánování prioritní plánování metody Large Deficit First (LDF). Při plánování LDF se monitorují vzorce využití kvant a žádné pracovní vlákno neovládá plánovač. Ve stejném scénáři může Pracovník 2 využívat opakovaně kvanta dříve, než budou povolena další kvanta pro Pracovníka 1, a tím zabraňuje tomu, aby Pracovník 1 monopolizoval plánovač nevhodným způsobem.

Plán paralelních úloh

Představte si SQL Server konfigurovaný s MaxDOP 8 a vazba CPU je nastavena na 24 procesorů (plánovačů) v uzlech NUMA 0 a 1. Plánovače 0 až 11 patří do uzlu NUMA 0, plánovače 12 až 23 patří do uzlu NUMA 1. Aplikace odešle do databázového stroje následující dotaz (požadavek):

SELECT h.SalesOrderID,
    h.OrderDate,
    h.DueDate,
    h.ShipDate
FROM Sales.SalesOrderHeaderBulk AS h
INNER JOIN Sales.SalesOrderDetailBulk AS d
    ON h.SalesOrderID = d.SalesOrderID
WHERE (h.OrderDate >= '2014-3-28 00:00:00');

Spropitné

Ukázkový dotaz lze spustit pomocí databáze AdventureWorks2016_EXT. Tabulky Sales.SalesOrderHeader a Sales.SalesOrderDetail byly zvětšeny 50krát a přejmenovány na Sales.SalesOrderHeaderBulk a Sales.SalesOrderDetailBulk.

Plán vykonávání zobrazuje Hash spojení mezi dvěma tabulkami a každý z operátorů běžící paralelně, což je znázorněno tím žlutým kruhem se dvěma šipkami. Každý operátor paralelismu představuje jinou větev v plánu. Proto existují tři větve v následujícím plánu provádění.

Poznámka

Pokud plán provádění považujete za strom, větev je oblast plánu, která seskupuje jeden nebo více operátorů mezi operátory paralelismu, označované také jako Iterátory Exchange. Další informace o operátorech plánu naleznete v tématu Showplan Logické a fyzické operátory Referenční.

V plánu provádění existují tři větve, ale v každém okamžiku během provádění se v tomto plánu provádění můžou provádět pouze dvě větve:

1. Větev, ve které se clusterovaný indexový sken používá v Sales.SalesOrderHeaderBulk (vstup sestavení spojení) se spustí samostatně.
2. Potom větev, ve které se clusterovaný indexový sken používá na Sales.SalesOrderDetailBulk (vstup sondy spojení), se spustí souběžně s větví, ve které byla vytvořena bitmapová a aktuálně se spouští shoda hodnot hash.

Xml showplan ukazuje, že 16 pracovních vláken bylo rezervováno a použito na uzlu NUMA 0:

<ThreadStat Branches="2" UsedThreads="16">
  <ThreadReservation NodeId="0" ReservedThreads="16" />
</ThreadStat>

Rezervace vláken zajišťuje, že databázový stroj má dostatek pracovních vláken k provádění všech úloh potřebných pro požadavek. Vlákna mohou být rezervována napříč několika uzly NUMA, nebo pouze v jednom uzlu NUMA. Rezervace vláken procesoru se provádí během běhu programu před jeho spuštěním a závisí na zatížení plánovače. Počet vyhrazených pracovních vláken je obecně odvozený ze vzorce concurrent branches * runtime DOP a vylučuje nadřazené pracovní vlákno. Každá větev je omezená na počet pracovních vláken, které se rovnají MaxDOP. V tomto příkladu jsou dvě souběžné větve a MaxDOP je nastavena na 8, a proto 2 * 8 = 16.

Pro referenci sledujte plán živého spouštění z statistiky živého dotazu, kde se dokončila jedna větev a souběžně se provádějí dvě větve.

Databázový stroj SQL Serveru přiřadí pracovní vlákno ke spuštění aktivní úlohy (1:1), které lze během provádění dotazu pozorovat dotazováním sys.dm_os_tasks zobrazení dynamické správy, jak je vidět v následujícím příkladu:

SELECT parent_task_address, task_address,
       task_state, scheduler_id, worker_address
FROM sys.dm_os_tasks
WHERE session_id = <insert_session_id>
ORDER BY parent_task_address, scheduler_id;

Spropitné

Sloupec parent_task_address je pro nadřazený úkol vždy NULL.

Spropitné

Na velmi zaneprázdněném databázovém stroji SQL Serveru je možné zobrazit řadu aktivních úloh, které jsou nad limitem nastaveným vyhrazenými vlákny. Tyto úlohy mohou patřit do větve, která se už nepoužívá, jsou v přechodném stavu a čekají na vyčištění.

Tady je sada výsledků. Všimněte si, že je 17 aktivních úkolů pro větve, které jsou právě vykonávány: 16 podřízených úkolů odpovídajících vyhrazeným vláknům, a také nadřazený úkol neboli koordinační úkol.

adresa_nadřazeného_úkolu	adresa_úkolu	stav_úkolu	scheduler_id	adresa_pracovníka
NULA	0x000001EF4758ACA8	POZASTAVENÝ	3	0x000001EFE6CB6160
0x000001EF4758ACA8	0x000001EFE43F3468	POZASTAVENÝ	0	0x000001EF6DB70160
0x000001EF4758ACA8	0x000001EEB243A4E8	POZASTAVENÝ	0	0x000001EF6DB7A160
0x000001EF4758ACA8	0x000001EC86251468	POZASTAVENÝ	5	0x000001EEC05E8160
0x000001EF4758ACA8	0x000001EFE3023468	POZASTAVENÝ	5	0x000001EF6B46A160
0x000001EF4758ACA8	0x000001EFE3AF1468	POZASTAVENÝ	6	0x000001EF6BD38160
0x000001EF4758ACA8	0x000001EFE4AFCCA8	POZASTAVENÝ	6	0x000001EF6ACB4160
0x000001EF4758ACA8	0x000001EFDE043848	POZASTAVENÝ	7	0x000001EEA18C2160
0x000001EF4758ACA8	0x000001EF69038108	POZASTAVENÝ	7	0x000001EF6AEBA160
0x000001EF4758ACA8	0x000001EFCFDD8CA8	POZASTAVENÝ	8	0x000001EFCB6F0160
0x000001EF4758ACA8	0x000001EFCFDD88C8	POZASTAVENÝ	8	0x000001EF6DC46160
0x000001EF4758ACA8	0x000001EFBCC54108	POZASTAVENÝ	9	0x000001EFCB886160
0x000001EF4758ACA8	0x000001EC86279468	POZASTAVENÝ	9	0x000001EF6DE08160
0x000001EF4758ACA8	0x000001EFDE901848	POZASTAVENÝ	10	0x000001EFF56E0160
0x000001EF4758ACA8	0x000001EF6DB32108	POZASTAVENÝ	10	0x000001EFCC3D0160
0x000001EF4758ACA8	0x000001EC8628D468	POZASTAVENÝ	11	0x000001EFBFA4A160
0x000001EF4758ACA8	0x000001EFBD3A1C28	POZASTAVENÝ	11	0x000001EF6BD72160

Všimněte si, že každý z 16 podřízených úkolů má přiřazené jiné pracovní vlákno (zobrazené ve sloupci worker_address), ale všechna pracovní vlákna jsou přiřazena do stejného fondu osmi plánovačů (0,5,6,7,8,9,10,11) a že nadřazený úkol je přiřazen plánovači mimo tento fond (3).

Důležitý

Po naplánování první sady paralelních úkolů v dané větvi bude databázový stroj používat stejný fond plánovačů pro všechny další úkoly v jiných větvích. To znamená, že stejná sada plánovačů se bude používat pro všechny paralelní úlohy v celém plánu provádění, pouze omezena parametrem MaxDOP.

Databázový stroj SQL Serveru se vždy pokusí přiřadit plánovače ze stejného uzlu NUMA pro provádění úkolů a přiřazovat je postupně, ve stylu round-robin, pokud jsou plánovače k dispozici. Pracovní vlákno přiřazené nadřazené úloze však může být umístěné v jiném uzlu NUMA než jiné úlohy.

Pracovní vlákno může zůstat aktivní pouze v plánovači během svého kvanta (4 ms) a musí po uplynutí tohoto kvanta uvolnit plánovač, aby pracovní vlákno přiřazené k jinému úkolu mohlo být aktivní. Když vyprší platnost kvantového procesu a už není aktivní, příslušná úloha se umístí do fronty FIFO ve stavu RUNNABLE, dokud se znovu nepřesune do stavu SPUŠTĚNO, za předpokladu, že úloha nevyžaduje přístup k prostředkům, které nejsou v tuto chvíli dostupné, jako je západka nebo zámek, v takovém případě by se úloha umístila do pozastaveného stavu místo SPUSTITELNÉho stavu. dokud tyto prostředky nebudou k dispozici.

Spropitné

V zobrazení DMV uvedeném výše jsou všechny aktivní úlohy ve stavu "SUSPENDED". Další podrobnosti o čekajících úkolech jsou k dispozici dotazováním sys.dm_os_waiting_tasks zobrazení dynamické správy.

V souhrnu vytvoří paralelní požadavek několik úloh. Každý úkol musí být přiřazen k jednomu pracovnímu vláknu. Každé pracovní vlákno musí být přiřazeno jednomu plánovači. Počet využitých plánovačů proto nemůže překročit počet paralelních úloh na větev, který je nastavený konfigurací MaxDOP nebo nápovědou dotazu. Koordinační vlákno nepřispívá k limitu MaxDOP.

Přidělení vláken procesorům

Ve výchozím nastavení každá instance SQL Serveru spouští každé vlákno a operační systém distribuuje vlákna z instancí SQL Serveru mezi procesory (procesory) v počítači na základě zatížení. Pokud je na úrovni operačního systému povolené spřažení procesů, přiřadí operační systém každé vlákno ke konkrétnímu procesoru. Naproti tomu databázový stroj SQL Serveru přiřazuje SQL Server pracovních vlákenplánovačům, které rovnoměrně distribuují vlákna mezi procesory ve stylu cyklického rozdělování.

Pokud chcete provádět multitasking, například když více aplikací přistupuje ke stejné sadě procesorů, operační systém někdy přesune pracovní vlákna mezi různé procesory. I když je tato aktivita z hlediska operačního systému efektivní, může tato aktivita snížit výkon SQL Serveru při vysokém zatížení systému, protože každá mezipaměť procesoru se opakovaně načítá s daty. Přiřazení procesorů ke konkrétním vlákenm může za těchto podmínek zlepšit výkon odstraněním opětovného načítání procesoru a snížením migrace vláken mezi procesory (čímž se snižuje přepínání kontextu); takové přidružení mezi vláknem a procesorem se nazývá spřažení procesoru. Pokud je spřažení povolené, operační systém přiřadí každé vlákno ke konkrétnímu procesoru.

Možnost masky spřažení je nastavena pomocí příkazu ALTER SERVER CONFIGURATION. Pokud maska spřažení není nastavená, instance SQL Serveru přidělí pracovní vlákna rovnoměrně mezi plánovače, které nebyly maskovány.

Opatrnost

Nekonfigurujte spřažení procesoru v operačním systému ani masku spřažení v SQL Serveru. Tato nastavení se pokouší dosáhnout stejného výsledku a pokud jsou konfigurace nekonzistentní, můžete mít nepředvídatelné výsledky. Další informace najdete v části volbu masky afinity .

Sdružování vláken pomáhá optimalizovat výkon při připojení velkého počtu klientů k serveru. Pro každý požadavek dotazu se obvykle vytvoří samostatné vlákno operačního systému. Při použití stovek připojení k serveru ale může použití jednoho vlákna na požadavek na dotaz spotřebovávat velké množství systémových prostředků. Možnost maximální počet pracovních vláken umožňuje SQL Serveru vytvořit fond pracovních vláken, aby mohl obsluhovat větší počet požadavků na dotazy, což zvyšuje výkon.

Použití možnosti zjednodušeného sdružování

Náklady spojené s přepínáním kontextů vláken možná nejsou příliš velké. Většina instancí SQL Serveru nezažívá žádné rozdíly ve výkonu mezi nastavením možnosti lightweight pooling na 0 nebo 1. Jedinými instancemi SQL Serveru, které by mohly těžit z zjednodušeného sdružování jsou ty, které běží na počítači s následujícími vlastnostmi:

• Velký server s více procesory
• Všechny procesory běží téměř s maximální kapacitou.
• Existuje vysoká úroveň přepínání kontextu.

Pokud je zjednodušená hodnota sdružování nastavená na hodnotu 1, můžou tyto systémy zaznamenat malý nárůst výkonu.

Důležitý

Nepoužívejte plánování režimu vláken pro běžný provoz. To může snížit výkon tím, že inhibuje pravidelné výhody přepínání kontextu, a protože některé komponenty SYSTÉMU SQL Server nemohou správně fungovat v režimu vláken. Další informace naleznete v části odlehčené sdružování.

Spouštění vláken a vláken

Systém Microsoft Windows používá systém s číselnou prioritou, který se pohybuje od 1 do 31 k naplánování vláken pro provádění. Nula je vyhrazená pro použití operačního systému. Když čeká na spuštění několika vláken, systém Windows odešle vlákno s nejvyšší prioritou.

Ve výchozím nastavení má každá instance SQL Serveru prioritu 7, která se označuje jako normální priorita. Toto výchozí nastavení dává vláknům SQL Serveru dostatečnou prioritu pro získání dostatečných prostředků procesoru, aniž by to mělo nepříznivý vliv na jiné aplikace.

Důležitý

Tato funkce bude odebrána v budoucí verzi SQL Serveru. Nepoužívejte tuto funkci v nové vývojové práci a naplánujte úpravu aplikací, které tuto funkci aktuálně používají.

Možnost konfigurace zvýšení priority lze použít ke zvýšení priority vláken z instance SQL Serveru na 13. To se označuje jako vysoká priorita. Toto nastavení dává vláknům SQL Serveru vyšší prioritu než většina ostatních aplikací. Vlákna SQL Serveru se proto obvykle odesílají vždy, když jsou připraveny ke spuštění a nejsou předem zrušeny vlákny z jiných aplikací. To může zvýšit výkon, když server běží pouze instance SQL Serveru a žádné jiné aplikace. Pokud však na SQL Serveru dojde k operaci náročné na paměť, jiné aplikace pravděpodobně nebudou mít dostatečnou prioritu pro odstranění vlákna SQL Serveru.

Pokud na počítači spouštíte více instancí SQL Serveru a zapnete zvýšení priority pouze u některých instancí, může to mít nepříznivý vliv na výkon všech instancí běžících v normální prioritě. Také výkon ostatních aplikací a komponent na serveru může klesnout, pokud je zapnuté zvýšení priority. Proto by měla být použita pouze za přísně kontrolovaných podmínek.

Přidání procesoru za běhu

Horké přidání procesoru je schopnost dynamicky přidávat procesory do spuštěného systému. K přidání procesorů může dojít fyzicky přidáním nového hardwaru, logicky prostřednictvím online dělení hardwaru nebo prakticky prostřednictvím virtualizační vrstvy. SQL Server podporuje horké přidání procesoru.

Požadavky na horké přidání procesoru:

• Vyžaduje hardware, který podporuje přidání procesoru za běhu.
• Vyžaduje podporovanou verzi edice Windows Server Datacenter nebo Enterprise. Počínaje Windows Serverem 2012 se v edici Standard podporuje horké přidání.
• Vyžaduje edici SQL Server Enterprise.
• SQL Server nejde nakonfigurovat tak, aby používal soft NUMA. Další informace o soft NUMA naleznete v tématu Soft-NUMA (SQL Server).

SQL Server po přidání nepoužívá procesory automaticky. To brání SQL Serveru v používání procesorů, které mohou být přidány pro nějaký jiný účel. Po přidání procesorů spusťte příkaz RECONFIGURE, aby SQL Server rozpoznal nové procesory jako dostupné prostředky.

Poznámka

Pokud je nakonfigurovaná maska spřažení64 , musí být maska spřažení64 upravena tak, aby používala nové procesory.

Osvědčené postupy pro spouštění SQL Serveru na počítačích s více než 64 procesory

Přiřazení hardwarových vláken k procesorům

Nepoužívejte možnosti konfigurace affinity mask a affinity64 mask serveru k přiřazení procesorů ke konkrétním vláknům. Tyto možnosti jsou omezené na 64 procesorů. Místo toho použijte možnost SET PROCESS AFFINITY v ALTER SERVER CONFIGURATION.

Správa velikosti souborů transakčního protokolu

Nespoléhejte na automatické zvětšování velikosti souboru transakčního protokolu. Zvýšení transakčního logu musí probíhat jako sériový proces. Rozšíření protokolu může bránit operacím zápisu transakcí, dokud se rozšíření protokolu nedokončí. Místo toho předlokujte místo pro soubory protokolu nastavením velikosti souboru na hodnotu dostatečně velkou, aby podporovala typickou úlohu v prostředí.

Nastavení maximálního stupně paralelismu pro operace indexu

Výkon operací indexů, jako je vytvoření nebo opětovné sestavení indexů, lze zlepšit na počítačích, které mají mnoho procesorů, tím, že dočasně nastavíte model obnovení databáze na hromadně protokolovaný nebo jednoduchý model obnovení. Tyto operace indexu můžou generovat významnou aktivitu protokolu a konflikty v protokolu můžou ovlivnit výběr optimálního stupně paralelismu (DOP) prováděného v SQL Serveru.

Kromě nastavení maximálního stupně paralelismu (MAXDOP) v konfiguraci serveru zvažte také nastavení paralelismu pro operace s indexy pomocí nastavení MAXDOP. Další informace najdete v tématu Konfigurace operací paralelního indexu. Další informace a pokyny k úpravě maximálního stupně konfigurace serveru paralelismu najdete v tématu Konfigurace maximálního stupně paralelismu serveru.

Maximální počet pracovních vláken

SQL Server dynamicky konfiguruje možnost konfigurace maximálního počtu pracovních vláken serveru při spuštění. SQL Server používá počet dostupných procesorů a systémovou architekturu k určení konfigurace tohoto serveru během spouštění pomocí zdokumentovaného vzorce.

Tato možnost je pokročilá a měla by být změněna pouze zkušeným správcem databáze nebo certifikovaným odborníkem na SQL Server. Pokud máte podezření, že došlo k problému s výkonem, pravděpodobně to není dostupnost pracovních vláken. Příčinou je pravděpodobně něco jako vstupně-výstupní operace, které způsobuje čekání pracovních vláken. Před změnou nastavení maximálního počtu pracovních vláken je nejlepší najít původní příčinu problému s výkonem. Pokud ale potřebujete ručně nastavit maximální počet pracovních vláken, musí být tato hodnota konfigurace vždy nastavena na hodnotu nejméně sedmkrát počet procesorů, které jsou přítomné v systému. Další informace najdete v tématu Konfigurace maximálního počtu pracovních vláken.

Vyhněte se použití nástroje SQL Trace a SQL Server Profiler

Doporučujeme nepoužívat Sledování SQL a SQL Profiler v produkčním prostředí. S rostoucím počtem procesorů se také zvyšuje režijní náklady na spouštění těchto nástrojů. Pokud je nutné použít trasování SQL v produkčním prostředí, omezte počet událostí trasování na minimum. Pečlivě profilujte a otestujte každou událost trasování při zatížení a vyhněte se použití kombinací událostí, které výrazně ovlivňují výkon.

Důležitý

Trasování SQL a SQL Server Profiler jsou zastaralé. Microsoft.SqlServer.Management.Trace oboru názvů, který obsahuje objekty trasování a přehrání SQL Server, je také zastaralý.

Tato funkce bude odebrána v budoucí verzi SQL Serveru. Nepoužívejte tuto funkci v nové vývojové práci a naplánujte úpravu aplikací, které tuto funkci aktuálně používají.

Místo toho použijte Rozšířené události. Další informace o rozšířených událostechnaleznete v Rychlý start: Rozšířené události v SQL Serveru a SSMS XEvent Profiler.

Poznámka

SQL Server Profiler pro úlohy Analysis Services není zastaralý a bude i nadále podporován.

Nastavení počtu datových souborů tempdb

Počet souborů závisí na počtu (logických) procesorů na počítači. Obecně platí, že pokud je počet logických procesorů menší nebo roven osmi, použijte stejný počet datových souborů jako logické procesory. Pokud je počet logických procesorů větší než osm, použijte osm datových souborů a pokud kolize potrvá, zvyšte počet datových souborů o násobky 4, dokud nedojde ke snížení kolizí na přijatelné úrovně nebo provedení změn úlohy nebo kódu. Mějte také na paměti další doporučení pro tempdb, která jsou k dispozici v Optimalizace výkonu databáze tempdb v SQL Serveru.

Pečlivým zvážením potřeb souběžnosti tempdbtím můžete snížit režijní náklady na správu databáze. Pokud má například systém 64 procesorů a obvykle pouze 32 dotazů používá tempdb, zvýšení počtu tempdb souborů na 64 nezlepší výkon.

Komponenty SQL Serveru, které můžou používat více než 64 procesorů

V následující tabulce jsou uvedeny součásti SYSTÉMU SQL Server a uvádí, zda mohou používat více než 64 procesorů.

Název procesu	Spustitelný program	Použití více než 64 procesorů
Databázový stroj SQL Serveru	Sqlserver.exe	Ano
Služby pro vytváření sestav	Rs.exe	Ne
Analytické služby	As.exe	Ne
Integrační služby	Is.exe	Ne
Service Broker	Sb.exe	Ne
Full-Text hledání	Fts.exe	Ne
Agent SQL Serveru	Sqlagent.exe	Ne
SQL Server Management Studio	Ssms.exe	Ne
Nastavení SQL Serveru	Setup.exe	Ne