Otimizando Contêineres Docker: Solucionando Gargalos de Desempenho

Quando um contêiner Docker está lento, o contêiner raramente é a explicação completa. O problema geralmente está uma camada abaixo: limitação de CPU, pressão de memória, gravações lentas em disco, atrasos de DNS, vizinhos barulhentos no host ou uma aplicação que já era ineficiente antes de ser conteinerizada.

A maneira mais rápida de perder tempo é começar a alterar flags do Docker antes de saber qual recurso está limitado. Comece com evidências, isole um gargalo, mude uma coisa e meça novamente.

Comece com Triagem, Não Ajuste

docker stats fornece uma visão ao vivo rápida:

docker stats
docker stats --no-stream

Use-o para responder perguntas básicas:

• A CPU está alta e sustentada?
• A memória está próxima do limite configurado?
• A E/S de bloco está aumentando durante requisições lentas?
• A contagem de processos está inesperadamente alta?
• A E/S de rede está alinhada com a carga de trabalho?

Em seguida, verifique o estado do contêiner e os logs:

docker logs --tail 100 <nome_ou_id_do_contêiner>
docker inspect <nome_ou_id_do_contêiner> --format 'OOM={{.State.OOMKilled}} Exit={{.State.ExitCode}} Restarting={{.State.Restarting}}'

Também observe o host. Um contêiner pode parecer inocente enquanto o host está fazendo swap ou o disco está saturado:

top
free -m
vmstat 1
iostat -xz 1

iostat pode exigir o pacote sysstat. Se você estiver no Docker Desktop, lembre-se de que há uma VM entre o sistema operacional host e os contêineres Linux, o que altera o comportamento de arquivos e rede.

Gargalos de CPU

CPU alta pode significar que a aplicação está ocupada, subdimensionada ou limitada. Esses são problemas diferentes.

Verifique as configurações de CPU:

docker inspect <contêiner> --format '{{json .HostConfig.NanoCpus}} {{json .HostConfig.CpuQuota}} {{json .HostConfig.CpuPeriod}}'

Se o contêiner estiver com um limite muito restrito, as requisições podem enfileirar mesmo que o host ainda tenha CPU ociosa. Tente um aumento controlado:

docker run -d --name api --cpus="2" my-api:latest

Se a CPU permanecer alta após aumentar o limite, analise a aplicação. Por exemplo, um serviço Node pode estar preso em serialização JSON, um worker Python pode estar limitado pela CPU sob o GIL, e um serviço Java pode estar gastando tempo em coleta de lixo. O Docker não pode corrigir isso sozinho.

Pressão de Memória e Mortes por OOM

Problemas de memória geralmente se manifestam como reinicializações, picos de latência ou o processo desaparecendo sob carga.

Verifique se o Docker detectou uma morte por OOM:

docker inspect <contêiner> --format '{{.State.OOMKilled}}'

Se a memória sobe lentamente e nunca cai, procure por um vazamento ou cache ilimitado. Se a memória dispara durante requisições específicas, reproduza esse caminho sob carga. Se um runtime de linguagem tem seu próprio limite de heap, alinhe-o com o contêiner. Uma JVM que não entende o orçamento real do contêiner pode se comportar mal; JVMs modernas são conscientes de contêineres, mas as configurações de heap ainda merecem revisão.

Os limites de memória devem deixar margem. Um contêiner usando 950 MB de um limite de 1 GB durante tráfego normal não está saudável. Coleta de lixo, buffers temporários, TLS, compressão e picos de requisições precisam de espaço.

Resolvendo Problemas de Desempenho de Entrada/Saída (E/S)

Acesso lento a disco afeta bancos de dados, filas, mecanismos de busca, aquecimento de cache e logs excessivos. Primeiro, descubra se as gravações estão indo para a camada gravável do contêiner, um volume nomeado ou uma montagem bind.

docker inspect <contêiner> --format '{{json .Mounts}}'
docker info --format 'StorageDriver={{.Driver}}'

Em instalações modernas do Docker Linux, overlay2 é o driver de armazenamento padrão comum. Geralmente é uma boa escolha, mas gravar dados mutáveis pesados na camada do contêiner ainda é um padrão ruim.

Use volumes nomeados para dados persistentes da aplicação:

docker volume create app-data
docker run -d --name app -v app-data:/var/lib/app my-image

Use montagens bind quando precisar de um caminho específico do host, mas teste-as. Montagens bind do Docker Desktop no macOS e Windows podem ser muito mais lentas que o acesso nativo ao sistema de arquivos Linux porque as operações de arquivo cruzam uma fronteira de virtualização.

Para arquivos temporários de alta velocidade, /dev/shm pode ajudar, mas é baseado em memória e limitado:

docker run --shm-size=512m my-image

Isso é comum para navegadores, executores de teste e aplicações que precisam de memória compartilhada. Não substitui o armazenamento real.

Otimizando o Tamanho da Imagem e o Desempenho do Build

O tamanho da imagem afeta principalmente o tempo de build, pull, escaneamento e deploy. Geralmente não torna o processamento de requisições mais rápido uma vez que o contêiner está em execução, mas ainda importa operacionalmente.

Use builds multi-estágio para que compiladores, caches de pacotes e ferramentas de teste não entrem na imagem de runtime:

FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o app

FROM alpine:3.20
COPY --from=builder /app/app /app
CMD ["/app"]

Ordene as instruções do Dockerfile para reutilização de cache:

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

Alterar o código fonte não deve forçar o download de dependências, a menos que os arquivos de dependência tenham mudado.

Considerações sobre Desempenho de Rede

Lentidão de rede geralmente parece lentidão de aplicação. Teste de dentro do contêiner:

docker exec -it <contêiner> sh
time getent hosts api.example.com
time wget -qO- https://api.example.com/health

Se a resolução de DNS for lenta ou instável, inspecione /etc/resolv.conf no contêiner e compare com o host. Você pode fornecer servidores DNS em tempo de execução:

docker run -d --name web --dns 1.1.1.1 my-image

Faça isso como uma escolha diagnóstica ou de política, não como uma correção aleatória. Em redes corporativas, o DNS interno pode ser necessário.

A rede bridge padrão do Docker adiciona processamento NAT e iptables. Para a maioria das aplicações web, a sobrecarga é aceitável. A rede host pode reduzir a sobrecarga no Linux:

docker run --network host my-image

Ela também remove o isolamento do namespace de rede e altera o tratamento de portas. Use-a quando você mediu uma necessidade real.

Uma Lista de Verificação de Campo

Quando um contêiner está lento, percorra esta lista:

1. Reproduza a lentidão com uma requisição, trabalho ou carga de trabalho específica.
2. Capture docker stats --no-stream, logs e a saída de inspect do contêiner.
3. Verifique CPU, memória, swap, E/S de disco e rede do host.
4. Identifique o recurso limitado antes de alterar limites.
5. Mova gravações persistentes ou pesadas para volumes.
6. Compare o comportamento da montagem bind no Linux versus Docker Desktop se o desenvolvimento local for o único lugar lento.
7. Analise a aplicação quando as métricas do contêiner não explicarem a lentidão.
8. Altere uma configuração e meça novamente.

A mentalidade útil é simples: o Docker fornece isolamento e empacotamento, mas não remove o trabalho normal de sistemas. CPU, memória, disco e rede ainda decidem quão rápido o serviço parece.