«

»

ago 08

Priority Boost

 

Vamos ver evidências de que o Priority Boost é um risco a estabilidade e a disponibilidade, inimigo de qualquer SLA. Esta é uma opção bem discutida, tem bastante conteúdo recomendando que seja desabilitada, mas é difícil vermos evidências.

  Vamos ver um caso real e entender como funciona.
 

O Windows possui vários níveis de prioridade, uma forma de privilegiar threads na fila até o processador. Threads com prioridade maior furam a fila, e são classificadas de 0 a 31:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Depois de habilitar o Priority Boost, de acordo com este artigo do MSDN (em inglês) quando o serviço do SQL for reiniciado chamará a API SetPriorityClass setando HIGH_PRIORITY_CLASS. Este nível de prioridade deve ser definido apenas para processos que realizam tarefas críticas ao Sistema Operacional, resumidamente, deixa o nível de prioridade dos worker threads em 15 que é muito perto do maior nível de prioridade do Sistema Operacional.

Os times de suporte relatam diversos problemas com o Priority Boost habilitado, principalmente em ambientes em Cluster, mas vamos ver um caso real e recente.

É um ambiente composto por Windows Server 2008 R2 Enterprise Service Pack 1, SQL Server Standard, e seu período de maior demanda é durante as cargas de dados, chegando a ultrapassar 120.000 transações por segundo. O nó onde o serviço do SQL Server estava rodando sofreu um unexpected shutdown, vejamos os logs:

 

USER_MODE_HEALTH_MONITOR (9e) 
One or more critical user mode components failed to satisfy a health check. 
Hardware mechanisms such as watchdog timers can detect that basic kernel 
services are not executing. However, resource starvation issues, including 
memory leaks, lock contention, and scheduling priority misconfiguration, 
may block critical user mode components without blocking DPCs or 
draining the nonpaged pool. 
Kernel components can extend watchdog timer functionality to user mode 
by periodically monitoring critical applications. This bugcheck indicates 
that a user mode health check failed in a manner such that graceful 
shutdown is unlikely to succeed. It restores critical services by 
rebooting and/or allowing application failover to other servers. 
Arguments: 
Arg1: fffffa80af4476f0, Process that failed to satisfy a health check within the 
configured timeout 
Arg2: 00000000000004b0, Health monitoring timeout (seconds) 
Arg3: 0000000000000000 
Arg4: 0000000000000000 

 

Log Name: System 
Source: Microsoft-Windows-FailoverClustering 
Date: 28/07/2013 09:02:06 
Event ID: 1230 
Task Category: Resource Control Manager 
Level: Error 
Keywords: 
User: SYSTEM 
Computer: SQL-01.domain,com 
Description: 
Cluster resource ”VIPNAME” (resource type ””, DLL ”clusres.dll”) either crashed or deadlocked. The Resource Hosting Subsystem (RHS) process will now attempt to terminate, and the resource will be marked to run in a separate monitor. 

Veja que uma tarefa importante deixou de ser executada e o próprio log explica o motivo:

 

Hardware mechanisms such as watchdog timers can detect that basic kernel 
services are not executing. However, resource starvation issues, including 
memory leaks, lock contention, and scheduling priority misconfiguration
may block critical user mode components without blocking DPCs or 
draining the nonpaged pool. 

Cluster resource ”VIPNAME” (resource type ””, DLL ”clusres.dll”) either crashed or deadlocked. 

 

Em seguida o servidor sofreu um blue screen e reiniciou.

 

Verifique sempre seu ambiente, Priority Boost é uma opção pra benchmark, pra nerdisse nossa de testes e experimentos, devendo ficar longe de ambientes de produção.

 

 

 

1 comentário

  1. Angelo Máximo Moreira Silva

    Muito bom Mercante, já havia lido sobre os “perigos” do Priority Boost, mas não tinha noção que ele pode causar problemas a ponto de indisponibilizar o servidor.
    Parabéns.

Deixe uma resposta