Calculadora de pool de conexões e planejamento de capacidade para bancos de dados em produção. Calcule com precisão o dimensionamento ideal do pool por pod Kubernetes, evite thread thrashing, estime tempos de espera em fila e proteja a memória do banco contra falhas de OOM utilizando a Lei de Little, fórmulas de saturação do HikariCP e taxas de multiplexação de transações do PgBouncer.
Calcule o tamanho ideal do pool e conexões com base no QPS alvo e tempo médio de consulta.
# ==============================================================================
# HikariCP Production Configuration (Spring Boot application.yml)
# Mode: forward_sizing | DB: postgresql
# Target Pod Replicas: 15 | Sized Pool per Pod: 4
# ==============================================================================
spring:
datasource:
type: com.zaxxer.hikari.HikariDataSource
url: jdbc:postgresql://db-cluster-endpoint:5432/app_db?sslmode=require
hikari:
pool-name: AppHikariPool
maximum-pool-size: 4
minimum-idle: 2
connection-timeout: 30000
idle-timeout: 600000
max-lifetime: 1800000
leak-detection-threshold: 5000
validation-timeout: 3000
auto-commit: true
data-source-properties:
cachePrepStmts: true
prepStmtCacheSize: 250
prepStmtCacheSqlLimit: 2048
useServerPrepStmts: true
useLocalSessionState: true
rewriteBatchedStatements: trueCalculadora de pool de conexões de banco de dados e planejamento de capacidade para produção. Dimensione com precisão o tamanho ideal do pool por pod Kubernetes, evite thread thrashing, estime tempos de espera em fila e proteja a memória do banco contra falhas de Out-Of-Memory (OOM) aplicando a Lei de Little, saturação de núcleos do HikariCP e multiplexação de transações no PgBouncer.
Núcleos físicos de CPU ou threads lógicas (hyperthreads) disponíveis na instância do banco de dados.
Tempo médio de processamento de consultas no banco de dados, excluindo trânsito de rede e tempo de espera para obtenção de conexão no pool.
Proporção de conexões de clientes da aplicação atendidas por uma única conexão persistente de backend no PgBouncer ou AWS RDS Proxy em modo de transação.
Margem de segurança aplicada sobre a concorrência em estado estável (Lei de Little) para absorver picos repentinos de tráfego.
No HikariCP e em pools de conexão de alto throughput, mantenha minimumIdle igual a maximumPoolSize para estabelecer um pool de tamanho fixo. Redimensionar pools dinamicamente durante picos de tráfego introduz handshakes TCP, negociações TLS e latência de autenticação no momento exato em que o sistema já está sob estresse.
Nunca calcule o tamanho do pool por pod de forma isolada sem verificar a soma agregada contra os limites máximos de CPU e memória do banco de dados. Sempre defina: pool_size_per_pod = (db_safe_connections / max_hpa_pod_replicas).
No PostgreSQL, o work_mem é alocado por operação de ordenação (sort) ou tabela hash, e NÃO por conexão. Uma consulta complexa com múltiplos joins e sorts pode alocar de 3x a 5x o valor de work_mem simultaneamente. Um número elevado de conexões combinado a um work_mem generoso aciona invocações catastróficas do Linux OOM Killer.
O PgBouncer moderno (v1.21+) suporta prepared statements a nível de protocolo no modo de pooling por transação. Garanta que o driver da aplicação desative a limpeza de prepared statements nomeados no cliente ou utilize declarações não nomeadas para maximizar a compatibilidade com o PgBouncer.
Identifique consultas lentas via pg_stat_activity ou no slow query log do MySQL; otimize as queries com índices compostos; caso a utilização de CPU do banco esteja baixa (<50%), aumente o pool de forma incremental ou implemente o PgBouncer.
Implemente o PgBouncer em modo de transação entre os pods Kubernetes e o PostgreSQL, ou reduza o maximumPoolSize por pod de modo que (max_pods * pool_size) < max_connections.
Reduza o max_connections ou diminua o work_mem. Assegure que shared_buffers (tipicamente 25% da RAM) somado a max_connections * 20MB reserve pelo menos 20% a 30% da RAM livre para o page cache do sistema operacional.
O dimensionamento ideal baseia-se em dois princípios fundamentais: a Lei de Little para a demanda de concorrência da aplicação e os limites de saturação de hardware para a capacidade do banco. Primeiro, calcule a concorrência pela Lei de Little: Concorrência = QPS Alvo * (Latência Média da Consulta em segundos). Por exemplo, 2.000 QPS com latência média de 5 ms (0,005 s) exige exatamente 10 conexões ativas. Adicionar 30% de margem para picos resulta em 13 conexões. Em seguida, verifique o ponto ideal de hardware do banco: ((Núcleos de CPU * 2) + Spindles de Disco). Em um banco com 16 vCPUs e armazenamento SSD, o limite de hardware é de aproximadamente 33 conexões. Se houver 5 pods Kubernetes em execução, configure o pool HikariCP de cada pod com 3 conexões (15 no total), mantendo-se com segurança abaixo do teto de hardware de 33 conexões e sem enfileiramento.
Essa fórmula empírica foi popularizada por Brett Wooldridge (criador do HikariCP) com base em benchmarks de hardware conduzidos por engenheiros de performance do PostgreSQL e da Oracle. Um único núcleo de CPU executa apenas um fluxo de instruções por vez. Quando uma consulta acessa dados em memória cache, 1 conexão satura 1 núcleo integralmente. Contudo, em esperas ocasionais de I/O de disco (mesmo em SSDs NVMe velozes), a thread entra em estado de I/O wait, permitindo que uma segunda thread aproveite os ciclos de CPU. Adicionar uma segunda conexão por núcleo ((Cores * 2)) mais o fator de spindles garante a saturação total do pipeline de CPU sem provocar troca excessiva de contexto (context switching). Benchmarks comprovaram que reduzir um pool de 2.048 conexões para 96 conexões diminuiu a latência das consultas de 100 ms para 2 ms, aumentando simultaneamente o throughput global.
O superdimensionamento de conexões desencadeia três modos críticos de falha: 1) Saturação e Thrashing por Troca de Contexto de CPU: Quando centenas de threads disputam núcleos de CPU, o kernel do sistema operacional consome mais ciclos salvando e restaurando registradores do que executando instruções SQL reais. 2) Esgotamento de Memória e Crashes por OOM: Cada conexão aloca memória privada de sessão (como a memória de backend do PostgreSQL ou buffers de thread do MySQL). Sob consultas pesadas com ordenação ou hash, a memória total excede a RAM física, levando o OOM Killer do Linux a encerrar o processo principal do banco. 3) Serialização e Fila de I/O de Disco: Um volume excessivo de gravações simultâneas sobrecarrega controladores de disco e filas de cache, elevando os tempos de espera de I/O e gerando timeouts de conexão em cascata por todos os microsserviços.
Ao dimensionar pools entre microsserviços ou pods com autoscaling no Kubernetes, dimensione de dentro do banco para fora, nunca a partir dos pods. Primeiro, determine a cota segura de conexões do banco (ex.: max_connections = 200, reservando 20 para DBAs e monitoramento, restando 180 para aplicações). Identifique o número máximo de pods sob pico do Horizontal Pod Autoscaler (HPA) (ex.: 30 pods). Divida o orçamento de conexões pelo número máximo de pods: 180 / 30 = 6 conexões por pod. Se 6 conexões por pod forem insuficientes para atender à Lei de Little no QPS alvo, adicione um pooler de conexões por transação, como PgBouncer ou AWS RDS Proxy, entre os pods e o banco de dados em vez de aumentar o pool de cada pod.
No modo Session Pooling (pooling por sessão), o PgBouncer aloca uma conexão dedicada do servidor ao cliente assim que ele se conecta, mantendo-a até que a aplicação se desconecte. Embora ofereça suporte transparente a todos os recursos SQL, proporciona ganho desprezível de multiplexação para pools persistentes de microsserviços. No modo Transaction Pooling (pooling por transação), o PgBouncer vincula uma conexão ao cliente estritamente durante o ciclo de uma transação SQL (BEGIN ... COMMIT). Assim que a transação é finalizada, a conexão retorna ao pool e é imediatamente reutilizada por outro pod, viabilizando taxas de multiplexação de 5:1 a 10:1. Entretanto, o pooling por transação restringe recursos de sessão, como LISTEN/NOTIFY, PREPARE sem nomeação explícita, tabelas temporárias e advisory locks de sessão.
No PostgreSQL, cada conexão cria um processo independente no sistema operacional consumindo de 5 MB a 10 MB de memória residente base. Além disso, cada backend aloca dinamicamente work_mem (padrão de 4 MB) por nó de ordenação, hash ou join em uma consulta. Uma consulta complexa com 3 operações desse tipo pode consumir 12 MB de work_mem, elevando o consumo da conexão para 22 MB. No MySQL InnoDB, as conexões utilizam threads que demandam de 256 KB a 1 MB de stack mais buffers de sessão (read_buffer_size, sort_buffer_size, join_buffer_size), com média de 2 MB a 6 MB por conexão. Suportar 1.000 conexões no PostgreSQL requer provisionar entre 10 GB e 20 GB de RAM apenas para os processos de conexão, reduzindo diretamente a memória disponível para shared_buffers e para o cache de páginas de disco do sistema operacional.
High-performance processing executed entirely in browser memory.
Calcule códigos de cores de resistores de 3, 4, 5 e 6 faixas com decodificação bidirecional instantânea, margens de tolerância, deriva por coeficiente de temperatura, síntese reversa da série E e equivalências SMD segundo a IEC 60062.
Calculadora interativa de memória e throughput para filas RabbitMQ com análise e visualização em tempo real no navegador.
Calcule os parâmetros de memória do PostgreSQL e gere configurações postgresql.conf via PGTune. Otimize shared_buffers, work_mem, effective_cache_size e max_connections.
Calcule a capacidade de armazenamento útil em TB decimais e TiB binários para arranjos RAID 0, 1, 5, 6, 10, 50, 60 e ZFS RAIDZ1/Z2/Z3 com overhead de paridade, risco de falha por URE no rebuild, tempo de reconstrução e visualizador de baias.
Calcule o tamanho exato da amostra, o poder estatístico e a duração de testes A/B. Inclui cálculo reverso de MDE, métricas contínuas, correção de Bonferroni multibraço e SRM.