Dimensionamento de hardware
Esta é a página que faz alguém comprar máquina. Número sem premissa é adivinhação com cara de fato, então cada faixa abaixo diz de onde saiu, e a metodologia está no fim.
O que realmente consome
Seção intitulada “O que realmente consome”Antes das faixas, a ordem de grandeza — porque ela contraria a intuição:
| Peça | Consumo | Comentário |
|---|---|---|
| Aplicação | 60 MiB de memória, ~0,5% de CPU em repouso | Não é o gargalo de memória. É o gargalo de CPU sob concorrência. |
| PostgreSQL | 1 GiB de memória em uso misto | Dimensione por volume de dado, não por número de usuários. |
| Armazenamento de objetos | 600 MiB de memória | Praticamente constante. O que cresce é o disco. |
A memória não é o problema; a CPU e o disco são. E o disco cresce por telemetria de endpoint, não por chamados.
Faixas sugeridas
Seção intitulada “Faixas sugeridas”Até 50 endpoints · até ~10 atendentes simultâneos
Seção intitulada “Até 50 endpoints · até ~10 atendentes simultâneos”| Recurso | Sugerido |
|---|---|
| CPU | 4 vCPU |
| Memória | 8 GB |
| Disco | 60 GB SSD |
| IOPS | 1 000 (SSD comum atende) |
Medido em 4 vCPU: 10 atendentes simultâneos com p50 de 122 ms e p95 de 156 ms; 20 simultâneos sobem para p50 278 ms. Serve com folga para uma equipe de suporte de porte médio.
Até 500 endpoints · até ~20 atendentes simultâneos
Seção intitulada “Até 500 endpoints · até ~20 atendentes simultâneos”| Recurso | Sugerido |
|---|---|
| CPU | 8 vCPU |
| Memória | 16 GB |
| Disco | 250 GB SSD, com espaço para crescer |
| IOPS | 3 000 |
Os 8 vCPU não são para a interface: são para a telemetria de 500 máquinas escrevendo em paralelo, mais o armazenamento de objetos e as rotinas de backup no mesmo hospedeiro. Se banco e armazenamento estiverem em máquinas próprias, 4 vCPU na aplicação continuam suficientes.
O disco é o item a decidir com cuidado nesta faixa — ver o cálculo da telemetria.
Acima de 500 endpoints
Seção intitulada “Acima de 500 endpoints”Aqui para de valer receita única, e a recomendação é separar:
| Peça | Sugerido |
|---|---|
| Aplicação | 2 contêineres × 4 vCPU / 8 GB, atrás do proxy |
| PostgreSQL | 8 vCPU / 32 GB, disco próprio, 5 000+ IOPS |
| Armazenamento de objetos | Máquina própria, disco dimensionado por retenção |
Com esse volume, decida a retenção antes de instalar os agentes. Ver o cálculo abaixo: a diferença entre 7 e 90 dias de telemetria é a diferença entre centenas de gigabytes e alguns terabytes.
O que faz o disco crescer
Seção intitulada “O que faz o disco crescer”Telemetria de endpoint — o item dominante
Seção intitulada “Telemetria de endpoint — o item dominante”Medição direta na tabela de telemetria de uma instalação em uso:
| Componente | Tamanho |
|---|---|
| Dados da tabela | 23 MB |
| Índices | 9,6 MB |
| Conteúdo fora de linha (TOAST) | 2 110 MB |
| Total | 2 143 MB, em 180 096 amostras |
98% do peso é o conteúdo fora de linha — o bloco de dados de cada amostra, guardado comprimido em
tabela separada pelo PostgreSQL. Medido: pg_column_size do bloco dá média de 11 kB por amostra.
A partir daí o cálculo é aritmética, e a cadência é o que manda:
| Cadência do sinal de vida | Amostras/dia | Por endpoint/dia | Por endpoint/mês |
|---|---|---|---|
| 60 s (padrão) | 1 440 | ~15,5 MB | ~465 MB |
| 300 s | 288 | ~3,1 MB | ~93 MB |
Multiplicando pela frota, com o padrão de 60 s:
| Endpoints | Por dia | Retenção de 7 dias | Retenção de 30 dias | Retenção de 90 dias |
|---|---|---|---|---|
| 50 | 775 MB | 5,4 GB | 23 GB | 70 GB |
| 500 | 7,6 GB | 53 GB | 227 GB | 682 GB |
| 2 000 | 30 GB | 210 GB | 900 GB | 2,7 TB |
Duas formas de reduzir, em ordem de efeito:
- Aumentar a cadência (
AGENT_HEARTBEAT_INTERVAL_SECONDS). De 60 s para 300 s corta o volume em cinco vezes. O custo é latência para detectar máquina que caiu. - Encurtar a retenção. Telemetria antiga raramente responde pergunta operacional; o histórico que importa costuma ser de dias, não de meses.
Chamados — muito menor do que se imagina
Seção intitulada “Chamados — muito menor do que se imagina”Medido em uma base de 491 chamados:
| Item | Tamanho |
|---|---|
| Dados dos chamados | 808 kB |
| Índices | 28 MB |
| Eventos e linha do tempo | ~3 MB |
Cerca de 1,6 kB por chamado nos dados, mais ~500 bytes por evento. Uma base de 50 mil chamados fica na casa de centenas de megabytes de dados — não é o que enche disco.
Os índices merecem nota: os 28 MB são dominados pelos índices de busca textual (trigram), que têm custo inicial alto e crescem devagar. Não extrapole esse número linearmente — 100 × 491 chamados não produz 100 × 28 MB.
Anexos não ficam no banco. Vão para o armazenamento de objetos, e é lá que o volume de chamados aparece como disco. Referência de comparação: uma base de sistema de chamados de 12,5 mil chamados ocupava 4,4 GB com anexos.
Armazenamento de objetos
Seção intitulada “Armazenamento de objetos”Medição dos buckets de uma instalação em uso:
| Bucket | Tamanho |
|---|---|
| Backups | 9,7 GB |
| Anexos e evidências | 1 004 MB |
| Arquivos do File Server | 194 MB |
| Telemetria de impressão | 40 MB |
| Mídia de conversa | 15 MB |
Backup domina, e é o item mais previsível: é o tamanho do banco vezes o número de cópias retidas. Dimensione-o por política, não por estimativa.
O que limita a concorrência
Seção intitulada “O que limita a concorrência”Medição de latência por número de atendentes simultâneos, em duas máquinas (27/07/2026):
| Atendentes simultâneos | 12 núcleos | 4 núcleos |
|---|---|---|
| 1 | 89 ms | 309 ms |
| 5 | 152 ms | 698 ms |
| 10 | 227 ms | 1 175 ms |
| 20 | 394 ms | 2 184 ms |
Essa medição foi feita com 50 mil chamados na base — carga alta de propósito. Com base vazia, a mesma máquina de 4 núcleos entregou p50 de 122 ms para 10 atendentes.
O gargalo é a CPU do processo da aplicação, não o banco: as consultas isoladas continuam em 80–120 ms mesmo com 4 núcleos. Cada abertura de tela dispara cerca de 4 requisições em paralelo (fila, indicadores, painel lateral e gráfico), e é a soma disso que consome núcleo.
Consequências práticas:
- Antes de comprar máquina, ajuste
MANAGER_WORKERSpara distribuir entre os núcleos existentes. - Depois disso, mais núcleos ajudam mais que mais memória.
- Duas cópias da aplicação atrás do proxy resolvem concorrência sem tocar no banco.
Metodologia
Seção intitulada “Metodologia”Para que estes números possam ser contestados — e refeitos:
Memória e CPU em repouso. docker stats --no-stream, hospedeiro de 6 vCPU e 15,6 GiB, carga média
0,69. O PostgreSQL e o armazenamento de objetos medidos são compartilhados com outros sistemas, então a
memória deles não é atribuível apenas ao OpenScale — é teto, não custo.
Tamanho por tabela. pg_relation_size (dados), pg_indexes_size (índices) e
pg_total_relation_size da tabela de conteúdo fora de linha, separados — somar tudo em um número só é o
que produz a conclusão errada de que “os índices estão inchados”.
Tamanho por amostra de telemetria. Média de pg_column_size do bloco de dados, sobre a tabela inteira.
Buckets. du -sh no diretório de dados do armazenamento.
Latência e concorrência. Medição de 27/07/2026 em duas máquinas, com a base carregada com 50 mil chamados sintéticos distribuídos em 2 anos, 36 setores e todos os estados e canais.
Uma armadilha que encontramos, e que você pode encontrar
Seção intitulada “Uma armadilha que encontramos, e que você pode encontrar”Na instalação medida, a tabela de telemetria tinha 180 096 linhas para apenas 4 843 amostras distintas — cerca de 97% eram reenvios da mesma coleta, gravados de novo. O número de 11 kB por amostra usado nesta página é por amostra distinta, e portanto não está contaminado por isso.
Se a sua tabela de telemetria crescer muito acima do previsto pelas tabelas acima, verifique antes de comprar disco:
SELECT COUNT(*) AS linhas, COUNT(DISTINCT (agent_row_id, collected_at)) AS amostras_distintasFROM manager_endpoint_telemetry;Números muito diferentes indicam reenvio, não uso. Nesse caso o disco resolve o sintoma e não a causa.