postgresql vps
Bancos de dados e cargas de trabalho em memória
Memória suficiente para o disco parar de importar.
O que implantaríamos
€ 125,30/mês
€ 179−30% anual
Acima de um certo tamanho de working set, a única otimização que conta é caber tudo na RAM. FORGE oferece até dezesseis gigabytes por núcleo de ECC registrado com hugepages pré-configurados e colocação ciente de NUMA, o que é o que PostgreSQL, Redis, ClickHouse e grandes heaps JVM querem. Por baixo, é Gen5 NVMe em RAID10, então as gravações que realmente atingem o disco também não são o gargalo.
Por que essa configuração
FORGE com afinidade de NUMA de soquete único mantém o acesso à memória local ao soquete que faz o trabalho. Adicione backups noturnos com trinta pontos de restauração, porque o modo de falha que você realmente vai encontrar é uma migração ruim, não um disco morto.
O que implantaríamos
Dimensionamento
Dimensione a RAM para o working set, não para o banco de dados. O working set são páginas de índice quentes mais linhas realmente acessadas, geralmente de 10-20% de um conjunto de dados OLTP de 2 TB. Defina o buffer pool InnoDB em 70-75% da RAM, ou shared_buffers do Postgres em 25% e deixe o page cache segurar o resto. FORGE alcança 16 GB por núcleo, então um buffer pool de 512 GB fica em cerca de 700 GB de RAM e pelo menos 44 núcleos. Se leituras erram o cache mais de 1% do tempo, compre RAM.
Hugepages, e por que THP não é a mesma coisa
Um buffer pool de 256 GB mapeado em páginas de 4 KB precisa de cerca de 64 milhões de entradas de tabela de páginas. O TLB não pode segurar uma fração significativa disso, então acesso aleatório paga um page walk na maioria dos lookups. Hugepages estáticos de 2 MB cortam a contagem de entradas por 512 e os walks com isso — espere uma queda mensurável no tempo de CPU por consulta em pools grandes. Aloque-os no boot via vm.nr_hugepages, dimensione para o pool mais aproximadamente 10%, e dê ao usuário do banco o limite de memlock. Hugepages transparentes alcançam o mesmo mapeamento, mas fazem isso oportunisticamente, com stalls de compactação. Desabilite THP e aloque explicitamente.
Working set, medido em vez de adivinhado
Não estime o working set a partir do tamanho do diretório de dados. Meça. No Postgres, pg_buffercache diz quais relações ocupam shared_buffers, e a razão de heap_blks_hit para heap_blks_read em pg_statio_user_tables dá a taxa de acerto de cache por tabela. No MySQL, Innodb_buffer_pool_reads contra Innodb_buffer_pool_read_requests dá o mesmo sinal. Acima de 99% você está em memória e adicionar RAM compra pouco. Entre 95% e 99% você está na beira do precipício, e uma única consulta sem índice pode empurrar você. Abaixo de 95%, todo número de latência que você tem é realmente um número de latência de disco disfarçado.
O que dá errado
- Deixar transparent hugepages habilitados. A desfragmentação do THP para o processo por milissegundos em momentos imprevisíveis, o que aparece como latência p99 que ninguém explica. Defina para never e aloque hugepages estáticos em vez disso.
- Ignorar NUMA em um FORGE dual-socket. O buffer pool cai em um nó, metade dos núcleos lê através do interconnect, e o MySQL pode fazer swap apesar da memória livre. Use numactl --interleave=all ou bind explicitamente.
- Dimensionar IOPS a partir do throughput médio. Checkpoints, vacuum e backups são os picos que importam. Um pool que lida bem com o estado estável vai travar a instância inteira durante um flush de checkpoint.
Ajuste a máquina
- Agendamento de CPU — Afinidade de nó NUMA único · € 14
- Backups — Backup diário, trinta pontos de restauração · € 11
- Tudo mais — Métricas com resolução de segundo e alertas · € 5
- Armazenamento e criptografia — ZFS com snapshots horários · € 7
Mais
Feito para trabalhos específicos
Hospedagem de servidor de jogos
Tick rate é um problema de thread única. Todo o resto é ruído.
VPS para trading e baixa latência
Distância até o mecanismo de matching, e nada entre você e o wire.
Endpoints privados de VPN e proxy
Sua própria saída, em uma jurisdição que você escolheu de propósito.
Seedboxes e armazenamento em massa
Terabytes que continuam baratos e uma porta que permanece aberta.
Nós workers Kubernetes
Barato por núcleo, denso e idêntico toda vez.
Inferência e fine-tuning de IA
Uma GPU inteira, passada diretamente, sob um compromisso que faz a matemática funcionar.