Dela via


Serverkonfiguration: maximalt antal arbetstrådar

gäller för:SQL Server

Den här artikeln beskriver hur du konfigurerar serverkonfigurationsalternativet max worker threads i SQL Server med hjälp av SQL Server Management Studio eller Transact-SQL. Alternativet max worker threads konfigurerar antalet arbetstrådar som är tillgängliga för HELA SQL Server för att bearbeta frågebegäranden, inloggning, utloggning och liknande programbegäranden.

SQL Server använder operativsystemens interna trådtjänster för att säkerställa följande villkor:

  • En eller flera trådar stöder samtidigt varje nätverk som SQL Server stöder.
  • En tråd hanterar databaskontrollpunkter.
  • En pool med trådar hanterar alla användare.

Standardvärdet för max worker threads är 0. Detta gör det möjligt för SQL Server att automatiskt konfigurera antalet arbetstrådar vid start. Standardinställningen är bäst för de flesta system. Men beroende på systemkonfigurationen kan inställningen max worker threads till ett visst värde ibland förbättra prestandan.

Begränsningar

Det faktiska antalet frågebegäranden kan överskrida det värde som anges i max worker threads vilket fall SQL Server poolar arbetstrådarna så att nästa tillgängliga arbetstråd kan hantera begäran. En arbetstråd tilldelas endast till aktiva begäranden och släpps när begäran har betjänats. Detta händer även om användarsessionen/anslutningen som begäran gjordes på förblir öppen.

Serverkonfigurationsalternativet max worker threads begränsar inte alla trådar som kan skapas i motorn. Systemtrådar som krävs för uppgifter som LazyWriter, Checkpoint, Log Writer, Service Broker, Lock Manager eller andra skapas utanför den här gränsen. Tillgänglighetsgrupper använder några av arbetstrådarna inifrån max worker thread limit men använder även systemtrådar (se Trådanvändning efter tillgänglighetsgrupper). Om antalet konfigurerade trådar överskrids innehåller följande fråga information om systemuppgifterna som skapade ytterligare trådar.

SELECT s.session_id,
    r.command,
    r.status,
    r.wait_type,
    r.scheduler_id,
    w.worker_address,
    w.is_preemptive,
    w.state,
    t.task_state,
    t.session_id,
    t.exec_context_id,
    t.request_id
FROM sys.dm_exec_sessions AS s
    INNER JOIN sys.dm_exec_requests AS r
        ON s.session_id = r.session_id
    INNER JOIN sys.dm_os_tasks AS t
        ON r.task_address = t.task_address
    INNER JOIN sys.dm_os_workers AS w
        ON t.worker_address = w.worker_address
WHERE s.is_user_process = 0;

Rekommendationer

Det här alternativet är ett avancerat alternativ och bör endast ändras av en erfaren databasproffs.

Om du misstänker att det finns ett prestandaproblem är det förmodligen inte tillgängligheten för arbetstrådar. Det är troligare att orsaken är relaterad till aktiviteter som upptar arbetstrådarna och inte frigör dem. Exempel är tidskrävande frågor eller flaskhalsar i systemet (I/O, blockering, spärrvänte, nätverksvänte) som orsakar långvariga frågor. Det är bäst att hitta grundorsaken till ett prestandaproblem innan du ändrar inställningen för maximala arbetstrådar. Mer information om hur du utvärderar prestanda finns i Övervaka och justera för prestanda.

Trådpooler hjälper till att optimera prestanda när ett stort antal klienter ansluter till servern. Vanligtvis skapas en separat operativsystemtråd för varje frågebegäran. Men med hundratals anslutningar till servern kan en tråd per frågebegäran förbruka stora mängder systemresurser. Alternativet max worker threads gör det möjligt för SQL Server att skapa en pool med arbetstrådar för att betjäna ett större antal frågebegäranden, vilket förbättrar prestandan.

I följande tabell visas det automatiskt konfigurerade antalet maximala arbetstrådar (när värdet är inställt på 0), baserat på olika kombinationer av logiska processorer, datorarkitektur och versioner av SQL Server, med hjälp av formeln: Standard max workers + ((logiska processorer - 4) * Arbetare per CPU).

Antal logiska processorer 32-bitars dator (upp till SQL Server 2014 (12.x)) 64-bitars dator (upp till SQL Server 2016 (13.x) SP1) 64-bitars dator (från och med SQL Server 2016 (13.x) SP2 och SQL Server 2017 (14.x))
<= 4 256 512 512
8 288 576 576
16 352 704 704
32 480 960 960
64 736 1472 1472
128 1248 2496 4480
256 2272 4544 8576

Upp till SQL Server 2016 (13.x) med Service Pack 1 är Arbetare per PROCESSOR bara beroende av arkitekturen (32-bitars eller 64-bitars):

Antal logiska processorer 32-bitars dator 64-bitars dator
<= 4 256 512
> 4 256 + ((logiska processorer - 4) * 8) 512 †† + ((logiska processorer - 4) * 16)

Från och med SQL Server 2016 (13.x) kan SQL Server inte längre installeras på ett 32-bitars operativsystem. 32-bitars datorvärden visas för hjälp av kunder som kör SQL Server 2014 (12.x) och tidigare. Vi rekommenderar 1 024 som det maximala antalet arbetstrådar för en instans av SQL Server som körs på en 32-bitars dator.

†† Från och med SQL Server 2017 (14.x) divideras standardvärdet Max Workers med 2 för datorer med mindre än 2 GB minne.

Från och med SQL Server 2016 (13.x) SP2 och SQL Server 2017 (14.x) beror Arbetare per PROCESSOR på arkitekturen och antalet processorer (mellan 4 och 64 eller större än 64):

Antal logiska processorer 32-bitars dator 64-bitars dator
<= 4 256 512
> 4 och <= 64 256 + ((logiska processorer - 4) * 8) 512 †† + ((logiska processorer - 4) * 16)
> 64 256 + ((logiska CPU:er - 4) * 32) 512 †† + ((logiska processorer - 4) * 32)

Från och med SQL Server 2016 (13.x) kan SQL Server inte längre installeras på ett 32-bitars operativsystem. 32-bitars datorvärden visas för hjälp av kunder som kör SQL Server 2014 (12.x) och tidigare. Vi rekommenderar 1 024 som det maximala antalet arbetstrådar för en instans av SQL Server som körs på en 32-bitars dator.

†† Från och med SQL Server 2017 (14.x) divideras standardvärdet Max Workers med 2 för datorer med mindre än 2 GB minne.

Tips/Råd

Mer information om hur du använder fler än 64 logiska processorer finns i Metodtips för att köra SQL Server på datorer som har fler än 64 processorer.

När alla arbetstrådar är aktiva med tidskrävande frågor kan SQL Server verka otillgänglig förrän en arbetstråd slutför en fråga och blir tillgänglig. Även om det här beteendet inte är en defekt kan det ibland vara oönskat. Om en process verkar inte svara och inga nya frågor kan bearbetas ansluter du till SQL Server med hjälp av den dedikerade administratörsanslutningen (DAC) och stoppar processen. Förhindra detta genom att öka antalet maximala arbetstrådar.

Behörigheter

Utför behörigheter på sp_configure utan parametrar eller med endast den första parametern är som standard beviljade till alla användare. Om du vill köra sp_configure med båda parametrarna för att ändra ett konfigurationsalternativ eller för att köra RECONFIGURE-instruktionen måste en användare beviljas behörigheten ALTER SETTINGS servernivå. Behörighet ALTER SETTINGS hålls implicit av de fasta serverrollerna sysadmin och serveradmin.

Använda SQL Server Management Studio (SSMS)

  1. Högerklicka på en server i Object Explorer och välj Egenskaper.

  2. Välj noden Processorer .

  3. I rutan Max worker threads skriver du eller väljer ett värde mellan 128 och 65 535.

Tips/Råd

Använd alternativet max worker threads för att konfigurera antalet arbetstrådar som är tillgängliga för SQL Server-processer. Standardinställningen för max worker threads är bäst för de flesta system. Men beroende på systemkonfigurationen kan inställningen max worker threads till ett mindre värde ibland förbättra prestandan. Mer information finns i avsnittet Rekommendationer i den här artikeln.

Använd Transact-SQL

  1. Anslut till databasmotorn.

  2. I standardfältet väljer du Ny fråga.

  3. Kopiera och klistra in följande exempel i frågefönstret och välj Kör. Det här exemplet visar hur du använder sp_configure för att konfigurera max worker threads alternativet till 900.

    USE master;
    GO
    
    EXECUTE sp_configure 'show advanced options', 1;
    GO
    
    RECONFIGURE;
    GO
    
    EXECUTE sp_configure 'max worker threads', 900;
    GO
    
    RECONFIGURE;
    GO
    
    EXECUTE sp_configure 'show advanced options', 0;
    GO
    
    RECONFIGURE;
    GO
    

Ändringen börjar gälla omedelbart efter att omkonfigurationen har körts, utan att databasmotorn behöver startas om.