Separar cedo demais custa dinheiro, e separar tarde demais custa lentidão. Três sinais mostram a hora certa.
- O banco deixa de caber na memória que a aplicação deixa livre.
- Picos da aplicação aumentam o tempo das consultas.
- A fila de processos passa do número de núcleos com frequência.
Banco, API e workers começaram juntos numa máquina, e isso foi o certo. Com o crescimento, chega um ponto em que um atrapalha o outro, e os números mostram quando.
O banco não cabe mais na memória
O PostgreSQL fica rápido quando os dados mais usados estão em memória. A taxa de acerto do cache mostra isso:
SELECT round(100.0 * sum(blks_hit) / nullif(sum(blks_hit) + sum(blks_read), 0), 1) AS acerto_cache
FROM pg_stat_database;Se ela cai abaixo de 99% nos horários de pico, o banco está indo ao disco com frequência, muitas vezes porque a aplicação e os workers ocupam a memória que ele usaria.
A aplicação atrasa o banco
Compare o tempo das consultas nos picos da API e dos workers com o resto do dia. Se as consultas ficam lentas justamente quando um job pesado roda, os dois estão disputando processador.
A fila de processos
No vmstat, a coluna r mostra quantos processos esperam CPU. Se ela passa do número de núcleos com frequência, a máquina está saturada. Antes de separar, confira se o banco está bem configurado.
Como separar
Mova primeiro o banco para uma máquina só dele. A latência entre duas máquinas no mesmo datacenter costuma ficar abaixo de um milissegundo, e o banco ganha toda a memória. O custo dessa decisão entra na conta de quanto custa um banco que roda o mês inteiro. Na MetalNode, a segunda máquina é contratada pelo site, sem passar por vendedor: veja como funciona.
