Por que seu /health simples falha sob ThreadPool starvation?

# Simulador interativo: fila global da ThreadPool

Dispare carga bloqueante e observe como os 3 mecanismos de resposta reagem à saturação da pool.

# Fundamentação teórica e trade-offs

Fundamentos de concorrência que explicam por que métodos tradicionais falham catastroficamente sob saturação de threads, e o custo sistêmico de cada modelo arquitetural.

# Matriz de compromissos arquiteturais

Nenhuma solução de software é isenta de custos. Avalie as penalidades operacionais e de engenharia de cada escolha:

# Como decidir qual mecanismo usar

Fluxo de decisão prático — pensado pra times que herdaram um monolito com sync-over-async espalhado e não podem corrigir tudo antes do próximo deploy.

flowchart TD
    A["Pod reiniciando em\nCrashLoopBackOff?"] -->|Sim| B{"dotnet-counters mostra\nThreadPool Queue Length > 0\nde forma contínua?"}
    A -->|Não| Z["Sem starvation.\nInvestigue outra causa\n(OOMKilled, exceção não tratada)"]
    B -->|Sim| C{"É viável corrigir o\nsync-over-async agora?"}
    B -->|Não| Z
    C -->|Sim, curto prazo| D["Corrija .Result/.Wait()\ne use SetMinThreads como\nmitigação temporária"]
    C -->|Não, é legado grande| E["Suba um listener dedicado\nem thread própria só para\nlivenessProbe (/livez)"]
    E --> F["Mantenha readinessProbe\napontando pro Kestrel normal"]
    D --> G["Releia com dotnet-counters\naté Queue Length ficar em 0"]
    F --> H["Rastreie o backlog de correção\n— thread dedicada é workaround,\nnão solução definitiva"]

# Outras mitigações antes de isolar o listener

O listener dedicado é a última linha de defesa. Antes de chegar lá, vale esgotar ajustes que atacam a causa raiz em vez de mascará-la:

• ThreadPool.SetMinThreads(n, n) eleva o piso de threads sempre disponíveis, mas só empurra o problema pra frente — se a carga bloqueante crescer, o novo piso também satura.
• Trocar .Result/.Wait() por await de ponta a ponta elimina a causa raiz; ferramentas como o analyzer VSTHRD002 (Roslyn) sinalizam esses pontos em build.
• HealthCheckOptions.Timeout maior no MapHealthChecks reduz falso-positivo, mas se o timeoutSeconds/periodSeconds do Kubernetes não acompanhar, o kubelet derruba o Pod primeiro mesmo assim.
• ASPNETCORE_<n>=/DOTNET_ThreadPool_UsePortableThreadPool e variáveis de ambiente de tuning do runtime ajudam em cenários específicos, mas exigem medir antes/depois — não são bala de prata.
• Separar o processo que sofre a carga bloqueante (ex.: um worker de integração legado) do processo que serve tráfego HTTP evita que a starvation de um contamine o health check do outro.

# Matriz comparativa técnica

Visão detalhada das características de execução e adequação arquitetural para contêineres e Kubernetes.

# Playbook de diagnóstico e investigação

Como comprovar tecnicamente que a ThreadPool está em starvation e rastrear a linha exata de código responsável pelas retenções.

dotnet-counters monitor -p 1 --counters System.Runtime

dotnet-dump collect -p 1 -o /tmp/starve.dmp
dotnet-dump analyze /tmp/starve.dmp

// HostedService ou inicializado no Program.cs
public static class DedicatedLivenessListener
{
    private static Thread? _thread;
    private static volatile bool _running = true;

    public static void Start(int port = 8081)
    {
        _thread = new Thread(() =>
        {
            using var listener = new HttpListener();
            listener.Prefixes.Add($"http://*:{port}/livez/");
            listener.Start();

            byte[] okResponse = "OK"u8.ToArray();

            while (_running)
            {
                try
                {
                    // Bloqueio SÍNCRONO puro no SO: NÃO toca na ThreadPool
                    var context = listener.GetContext();

                    context.Response.StatusCode = 200;
                    context.Response.ContentType = "text/plain";
                    context.Response.ContentLength64 = okResponse.Length;
                    context.Response.OutputStream.Write(okResponse, 0, okResponse.Length);
                    context.Response.Close();
                }
                catch (HttpListenerException) when (!_running) { break; }
                catch (Exception ex)
                {
                    Console.Error.WriteLine($"[LivenessListener] Erro: {ex.Message}");
                }
            }
        })
        {
            IsBackground = true,
            Name = "DedicatedLivenessWorkerThread",
            Priority = ThreadPriority.AboveNormal // Preempção suave em alta carga de CPU
        };

        _thread.Start();
    }

    public static void Stop() => _running = false;
}

# Onde ler mais sobre cada assunto

Compilado estruturado por tema com documentações oficiais, código-fonte do runtime, papers de concorrência e guias de diagnóstico.