Esse truque do Linux impede falhas do Next.js

Você executa `next build` em um novo droplet do Ubuntu e tudo parece bem por cerca de 10 segundos. Então, a carga média explode, a CPU atinge 100% e sua sessão SSH começa a perder caracteres como uma chamada ruim do Zoom. Um minuto depois, o terminal retorna com uma única palavra, irritante: “Mortos.”

Sem rastreio de pilha, sem código de erro organizado, apenas uma compilação morta. Execute novamente e você obtém o mesmo padrão: os ventiladores aceleram, o topo mostra o Node e uma enxurrada de trabalhadores consumindo CPU, então silêncio. Se você verificar os gráficos do seu provedor depois, verá um pico acentuado de CPU e memória, seguido por um despenhadeiro onde seu processo desapareceu.

Este modo de falha impacta mais intensamente os assentos baratos da nuvem. Aqueles instâncias de 1 GB de RAM que custam entre $5 e $7/mês da DigitalOcean, Vultr, Linode ou Lightsail são perfeitas para um aplicativo básico em Node—até que você peça para rodar uma build moderna do Next.js. Durante essa janela de build, seu “pequeno mas poderoso” droplet de repente se comporta como um Raspberry Pi tentando compilar o Chrome.

Os desenvolvedores costumam reagir a isso com o reflexo mais caro na computação em nuvem: assumir que o hardware é o problema. A história segue o mesmo caminho todas as vezes. A construção falha, o servidor parece congelado, e a reação instintiva é: “Esta máquina simplesmente não consegue suportar o Next.js. Preciso de 2 GB, talvez 4 GB.”

Os painéis de controle em nuvem até o incentivam a isso. Você vê a memória no limite, a CPU no máximo e um evento vermelho de "sem memória" nos logs. O botão de upgrade está a um clique de distância, prometendo que um nível de instância maior fará o problema desaparecer. Para muitas equipes, esse clique se torna parte do manual de implantação.

A realidade é menos glamourosa e muito mais barata. Esses travamentos geralmente não significam que seu aplicativo precisa de uma máquina permanentemente maior; significam que seu passo de compilação precisa momentaneamente de mais memória do que seu droplet pode oferecer. E em uma imagem padrão do Ubuntu com swap desativado, o kernel tem apenas uma maneira confiável de lidar com esse pico: encerrar sua compilação.

O Next.js se parece com um único processo `node` no `htop`, mas o `next build` se comporta mais como um pequeno sistema distribuído compactado em um único binário. Nos bastidores, o Next.js orquestra múltiplos trabalhadores Node, uma ferramenta de TypeScript, um empacotador e pipelines de ativos, todos competindo pela mesma limitada quantidade de 1 GB de RAM.

Comece com o Node em si. O processo principal inicia vários threads de trabalho ou processos filhos para paralelizar a compilação de páginas. Cada trabalhador carrega seu próprio pedaço do gráfico de dependências, heaps do V8 e metadados de construção. Em vez de um único processo de 200 a 300 MB, você rapidamente obtém vários, e seus picos se acumulam.

Em seguida, a história do TypeScript. Quando você executa `next build` em um projeto TypeScript, a ferramenta carrega o compilador TypeScript, analisa toda a sua base de código e realiza a verificação de tipos. Isso significa que várias grandes ASTs, tabelas de símbolos e caches ficam na memória ao mesmo tempo, muitas vezes consumindo centenas de megabytes em projetos de médio porte.

Além disso, o Next.js invoca um empacotador (Webpack ou Turbopack) para gerar tanto os pacotes do cliente quanto os do servidor. Cada alvo precisa de seu próprio gráfico de dependências, passes de otimização e mapas de origem. Grandes bibliotecas de componentes, frameworks de UI e sistemas de design inflacionam esses gráficos, de modo que um projeto que funciona bem com 300–400 MB em produção pode chegar a 800–900 MB ou mais durante uma construção.

Em seguida, vêm as imagens e ativos estáticos. Quando você habilita next/image ou processa mídias grandes, o pipeline de construção decodifica, redimensiona e recomprime arquivos. As operações de imagem consomem muita memória: algumas imagens hero em 4K ou folhas de sprites podem ocupar temporariamente dezenas ou centenas de megabytes por trabalhador antes de serem gravadas de volta no disco.

Tudo isso acontece em um intervalo apertado de alguns segundos a alguns minutos. Imagine um café com 20 assentos que de repente recebe uma flash mob de 60 pessoas. O fluxo normal funciona bem, mas aquele curto e caótico surto bloqueia as entradas, sobrecarrega a equipe e deixa os clientes regulares presos do lado de fora. `next build` cria exatamente esse tipo de sobrecarga temporal em um droplet de 1 GB.

Em um servidor Ubuntu de 1 GB sem swap, essa multidão de acesso rápido eleva o uso da memória além do limite físico. O kernel começa a recuperar memória de forma agressiva, os caches desaparecem e, quando ainda não consegue encontrar RAM suficiente, o OOM killer entra em ação e termina os processos mais pesados. Seu `próximo build` morre com uma epitáfio de uma palavra: `Killed`.

O OOM killer soa dramático porque realmente é. Quando um sistema Linux fica sem RAM física, o kiler de fora da memória (OOM killer) entra em ação como uma válvula de segurança de último recurso, analisando cada processo em execução e decidindo qual sacrifício fazer para que a máquina inteira não travasse. Sem ele, um droplet de 1 GB do Ubuntu sob pressão de memória simplesmente congelaria, interrompendo sessões SSH e deixando você com um terminal inativo e uma reinicialização forçada.

As compilações do Next.js são alvos perfeitos. Durante o `next build`, o Node gera múltiplos processos de trabalho, carrega compiladores como o TypeScript, processa pacotes e, às vezes, processa imagens, facilmente elevando o uso de memória centenas de megabytes acima da linha de base em um breve pico. Para o kernel, isso se parece com um processo grande, recente e não essencial que pode ser encerrado com impacto mínimo “sistêmico”.

O Linux usa uma heurística chamada oom_score (e oom_score_adj) para classificar as vítimas. Processos grandes que alocaram recentemente uma grande quantidade de memória, não são executados como root e não pertencem a serviços centrais do sistema flutuam para o topo. Uma construção Next.js em um droplet de 1 GB, já ao lado do nginx, sshd e talvez um pequeno banco de dados, muitas vezes se torna a coisa mais volumosa e descartável na RAM.

Nenhuma troca muda completamente as apostas. Quando a RAM atinge 100% e não há swap configurado, o kernel tem apenas duas opções: travar enquanto tenta desesperadamente recuperar páginas ou invocar o OOM killer. Essa escolha binária explica por que seu terminal fica parado por um momento e depois exibe uma única palavra—“Killed”—sem rastreamento de pilha, sem erro do Next.js e sem dica útil do Node.

A linha "Killed" não é uma ofensa do npm; é a assinatura do kernel. Você a verá em execuções falhadas de `pnpm install`, `npm install` ou `next build` quando o OOM killer encerra o processo no meio da execução. Os logs do sistema (`dmesg` ou `journalctl -k`) geralmente revelam a origem do problema com entradas como "Fora da memória: Matar processo 1234 (node) pontuação 900 ou sacrificar o filho."

O swap oferece ao kernel outra jogada. Com um arquivo de swap de 1 a 2 GB, o sistema pode transferir páginas frias—daemons ociosos, páginas de cache, bibliotecas pouco utilizadas—para o disco, liberando RAM para que a construção possa ser concluída em vez de ser cortada. Para orientações passo a passo, recursos como Como criar um arquivo de swap para implantar um aplicativo NextJS e Docker em um VPS Ubuntu detalham uma configuração adequada para produção.

O espaço de swap atua como uma válvula de pressão para a memória do seu pequeno servidor. Em vez de encerrar imediatamente o `next build` quando a RAM chega a 100%, o kernel do Linux pode despejar dados excedentes em um bloco dedicado do disco e continuar. Esse bloco é o seu arquivo de swap.

Pense no swap como uma “RAM de transbordo” que reside no armazenamento em vez de no silício. O Linux reserva um arquivo ou partição no disco e o trata como uma extensão da memória física, medida nas mesmas páginas de 4 KB que a RAM comum utiliza.

Quando seu droplet de 1 GB fica sem RAM durante uma construção Next.js, o kernel inicia a triagem. Páginas pertencentes a daemons ociosos, caches antigos ou serviços em segundo plano são movidas da RAM para o arquivo de swap, liberando memória real para os caminhos de código quente da construção.

O kernel faz isso automaticamente através de seu gerenciador de memória virtual. Você não precisa reescrever seu aplicativo ou tocar nas flags do Node; uma vez que a troca existe e está ativa, o sistema discretamente move páginas menos usadas para longe e reserva a memória mais rápida para a tarefa que está realizando mais trabalho no momento.

O disco é lento em comparação com a RAM — milissegundos em vez de nanosegundos — por isso usar swap sempre adiciona latência. Para uma compilação de curta duração, no entanto, a estabilidade supera a velocidade: um `next build` que termina em 90 segundos em um servidor com swap é muito melhor do que um que morre após 20 segundos com uma única palavra, "Morto".

Em um servidor com swap configurado, aquele mesmo pico brutal de memória parece entediante. A CPU ainda sobe, os ventiladores continuam girando, mas sua sessão SSH permanece responsiva, o `top` mostra o uso de swap aumentando e a compilação avança em vez de detonar a tabela de processos.

Em um servidor sem swap, o kernel não tem saída. Uma vez que a RAM se enche, ele ou trava enquanto busca por páginas recuperáveis ou invoca o OOM killer, finalizando o Node, seu gerenciador de pacotes ou qualquer outra coisa que pareça descartável apenas para continuar funcionando.

Esse contraste é marcante: com o swap, as construções parecem pesadas, mas confiáveis; sem ele, a mesma carga de trabalho pode travar seu shell, destruir sua implantação e forçá-lo a cuidar de um droplet reiniciado.

Comece confirmando se sua máquina Ubuntu já possui swap. Execute `sudo swapon --show`. Um resultado vazio significa que não há dispositivos de swap ativos. Em seguida, execute `free -h` para ver a RAM total e o swap atual, depois `df -h` para verificar o uso do disco. Em um droplet típico de 25 GB, você normalmente verá menos de 20% em uso, o que deixa bastante espaço para um arquivo de swap de 2 GB.

Com o espaço em disco confirmado, aloque o arquivo de troca. Para um servidor com 1 GB de RAM, um arquivo de 2 GB dá ao Next.js builds um verdadeiro espaço para respirar sem sobrecarregar o disco. Use `sudo fallocate -l 2G /swapfile`. Isso reserva 2 GB instantaneamente sem realmente escrever zeros. Verifique com `ls -lh /swapfile` e você deve ver `2.0G` na coluna de tamanho.

Neste momento, `/swapfile` é apenas um arquivo comum que qualquer um pode acessar. Proteja-o para que apenas o root possa lê-lo ou escrevê-lo. Execute `sudo chmod 600 /swapfile`. Verifique as permissões novamente com `ls -lh /swapfile` e você deverá ver `-rw-------` no início da linha, o que confirma que o arquivo é privado para o root.

Em seguida, transforme esse arquivo simples em um verdadeiro espaço de troca. Use `sudo mkswap /swapfile`. O Ubuntu responderá com algo como `configurando espaço de troca versão 1, tamanho = 2 GiB`. Essa mensagem significa que o kernel agora reconhece `/swapfile` como uma área de troca válida, mas ainda está inativo até que você a habilite explicitamente.

Ative a troca com um único comando: `sudo swapon /swapfile`. Execute `sudo swapon --show` novamente e você deverá ver uma tabela listando `/swapfile`, seu tamanho (cerca de `2G`) e sua prioridade. O comando `free -h` também mostrará `Swap: 2.0Gi` no resumo, confirmando que o kernel agora pode descarregar páginas de memória quando os picos de builds do Next.js ocorrerem.

Neste momento, essa configuração sobrevive a reinicializações apenas se você torná-la permanente. Edite `/etc/fstab` com `sudo nano /etc/fstab` e adicione uma linha na parte inferior:

- `/swapfile nenhum swap sw 0 0`

Salve, saia e você terminou. Na próxima reinicialização, o Ubuntu habilitará automaticamente o `/swapfile`, para que suas compilações do Next.js continuem funcionando mesmo após atualizações do kernel, reinicializações ou falhas inesperadas.

A troca que você acabou de criar sobrevive apenas enquanto a inicialização atual durar. O comando `swapon /swapfile` ativa um interruptor em tempo de execução; assim que o kernel reinicia, esse estado desaparece e suas builds do Next.js voltam a morrer com `Killed`.

Para manter a troca online durante as reinicializações, é necessário registrá-la em `/etc/fstab`, a tabela de sistema de arquivos que o Linux lê na inicialização. Esse arquivo informa ao kernel quais discos, partições e áreas de swap devem ser montados automaticamente.

Antes de tocá-lo, faça um backup. Um `/etc/fstab` corrompido pode impedir que o servidor inicie completamente, deixando você à procura de um console de recuperação no seu painel de controle na nuvem.

Executar:

- `sudo cp /etc/fstab /etc/fstab.bak`

Agora abra o arquivo com um editor que tenha acesso root, por exemplo:

- `sudo nano /etc/fstab`

Role para baixo e adicione esta linha exata:

- `/swapfile nenhum swap sw 0 0`

Todos os campos são importantes. `/swapfile` é o caminho para o seu arquivo de swap. `none` representa um ponto de montagem, pois a swap não se monta na árvore de diretórios.

`swap` declara o tipo de sistema de arquivos, que informa ao kernel que esta entrada é memória virtual, não ext4 ou xfs. `sw` é a opção de montagem configurada, uma abreviação para "tratar isto como swap com o comportamento padrão."

Os últimos dois zeros controlam o comportamento do `dump` e do `fsck`. `0 0` significa que o sistema não tentará fazer o dump ou executar verificações de sistema de arquivos neste arquivo, que é exatamente o que você deseja para a partição de swap.

Após salvar, valide a sintaxe com:

- `sudo montar -a`

Nenhuma saída geralmente indica sucesso. Reinicie com `sudo reboot`, e depois confirme a persistência usando `free -h` ou `swapon --show`. Para um ajuste mais profundo e informações sobre o desempenho do swap, consulte Supercarregue Seu Sistema Linux com Espaço de Swap - Kite Metric.

O swap se comporta como uma válvula de pressão para a memória, não como um upgrade de desempenho gratuito. Usado com cuidado, ele mantém um pequeno gota de 1 GB funcionando por tempo suficiente para que as compilações do Next.js sejam concluídas. Usado de forma descuidada, pode levar um aplicativo em produção ao colapso.

Quando usar swap: picos curtos e agudos de memória. Um `next build` que executa por 2-5 minutos, aumentando brevemente o uso de 700-800 MB para 1.3-1.5 GB, é perfeito. O kernel pode eliminar páginas frias para o disco, liberar algumas centenas de megabytes, e sua compilação termina em vez de ser “Matada.”

As mesmas regras se aplicam a outras tarefas esporádicas que ocorrem raramente e não atendem ao tráfego ao vivo. Bons candidatos incluem: - `npm install`, `pnpm install` ou `yarn install` - Migrações de banco de dados ou importações de dados únicas - Scripts administrativos ou de manutenção ocasionais - Etapas de implantação em contêineres ou agentes de CI

Nesses casos, seu aplicativo fica ocioso bem abaixo da RAM física—digamos, 300–500 MB em um servidor de 1 GB—e só precisa de mais espaço durante compilações ou instalações. Você troca um pouco de velocidade por confiabilidade: uma compilação pode ser 20–40% mais lenta ao utilizar swap, mas na verdade é concluída. Para muitas equipes, ficar em um droplet menor compensa esse custo imediatamente.

Quando não usar swap: pressão de memória em estado estacionário do seu aplicativo principal. Se o seu servidor Next.js e o banco de dados juntos precisam de 1,4 GB em uma instância de 1 GB o dia todo, o kernel constantemente embaralha páginas de memória entre a RAM e o disco. Esse thrashing destrói o desempenho porque o disco, mesmo SSD, é várias ordens de magnitude mais lento que a RAM.

Você pode identificar a troca prejudicial com alguns sintomas concretos: - Alto I/O de disco (`iostat`, `iotop`) mesmo com baixo volume de requisições - Respostas HTTP lentas ou timeouts com apenas alguns usuários - `free -h` mostrando centenas de megabytes de swap utilizados e mal diminuindo em repouso - Média de carga disparando enquanto o uso da CPU permanece estranhamente modesto

Se essas bandeiras vermelhas aparecerem, a troca se comporta como um curativo em uma ferida de bala. A solução real é mais RAM ou orçamentos de memória mais rigorosos: reduza os trabalhadores Node, diminua os tamanhos do cache, divida serviços ou mova o banco de dados para fora do servidor. A troca deve lidar com picos raros, não sustentar seu aplicativo 24/7.

O swap lhe dá uma margem de manobra, mas um outro sabotador silencioso ainda pode derrubar sua construção: Node.js. Se o Node decidir que "precisa" de 8 GB de heap em um servidor de 1 GB, nenhuma quantidade de truques com swap o salvará do OOM killer. É aí que uma única e obscura flag muda tudo.

A flag `--max-old-space-size` do Node controla quanto de memória o motor V8 pode usar para seu heap principal de JavaScript, medido em megabytes. Quando esse limite é muito alto, o Node reserva agressivamente uma quantidade de memória que sua máquina simplesmente não possui, e o kernel responde encerrando o processo assim que a RAM + swap se esgotam.

Projetos Next.js frequentemente escondem essa armadilha dentro do `package.json`. Enterrado na seção `scripts`, você pode ver um comando de build como: - `"build": "NODE_OPTIONS='--max-old-space-size=8192' next build"`

Em um droplet de 1 GB, aquele alvo de heap de 8192 MB é uma fantasia. O Node vai felizmente tentar atingir esse valor, sua RAM de 1 GB e talvez 1–2 GB de swap vão evaporar, e sua construção irá sair com a mesma mensagem abrupta de `Killed` que você começou.

Primeiro passo: abra o `package.json` do seu projeto e inspecione todos os scripts relacionados a build. Procure por qualquer coisa que defina `NODE_OPTIONS` ou passe diretamente `--max-old-space-size` para `node` ou `next`, por exemplo: - `"build": "NODE_OPTIONS='--max-old-space-size=4096' next build"` - `"build": "node --max-old-space-size=6144 node_modules/next/dist/bin/next build"`

Então alinhe esse número com o seu orçamento real: RAM física + swap, menos a sobrecarga para o sistema operacional, banco de dados e serviços em segundo plano. Em um servidor de 1 GB com um arquivo de swap de 2 GB (aproximadamente 3 GB no total), um limite de `--max-old-space-size=2048` geralmente faz sentido e deixa espaço para tudo o mais.

Atualize o script, reinstale ou redistribua, e execute `next build` novamente. Com a troca ativada e a memória heap do Node limitada a algo realista, suas compilações param de fingir que estão rodando em uma estação de trabalho de 64 GB e começam a se comportar como se vivessem em um droplet pequeno e barato.

O Swap quieto corrige mais do que construções instáveis do Next.js. Qualquer carga de trabalho que ocasionalmente consome muita memória em um pequeno VPS ou caixa de desenvolvimento se beneficia de ter alguns gigabytes extras de memória virtual para recorrer, em vez de enfrentar a morte por falta de memória (OOM killer).

Os gerenciadores de pacotes são reincidentes aqui. Um único `npm install`, `pnpm install` ou `yarn install` em um monorepo moderno pode iniciar dezenas de trabalhadores Node, descompactar milhares de tarballs e calcular árvores de dependências em memória. Em um servidor de 1 GB, isso pode facilmente fazer o uso ultrapassar 90-100% da RAM por vários minutos.

Scripts pesados de importação de dados e migração se comportam da mesma maneira. Jobs de ETL que consomem algumas centenas de megabytes de JSON ou CSV na memória, migrações do Prisma ou do TypeORM que hidratam esquemas grandes, ou scripts administrativos ad-hoc que processam em lote registros de usuários, todos criam picos de memória curtos e brutais. Com a troca ativada, esses picos desaceleram em vez de detonar sua sessão SSH.

Ferramentas de banco de dados também dependem da RAM. Executar `pg_restore` em um dump PostgreSQL de vários gigabytes, importar um snapshot do MySQL ou realizar reindexação no Elasticsearch pode alocar temporariamente centenas de megabytes de buffers e caches. Um arquivo de swap de 1 a 2 GB oferece ao kernel espaço para armazenar páginas inativas enquanto os caminhos de código essenciais permanecem na RAM real.

Ambientes contêinerizados adicionam outra camada de fragilidade. Um contêiner Docker construindo um aplicativo Next.js, compilando módulos nativos ou executando testes pode atingir seu limite de memória cgroup muito antes do host. O espaço de swap a nível de host frequentemente age como o último buffer que impede que o kernel mate o contêiner durante a construção.

O desenvolvimento local também não está imune. Executar `next dev`, Storybook, um banco de dados e um navegador cheio de abas em um laptop de 8 GB pode consumir memória rapidamente. Combinar um pequeno arquivo de troca com práticas de Como otimizar seu ambiente de desenvolvimento local - Next.js mantém sua máquina responsiva enquanto tudo compila.

Problemas de memória em pequenos servidores raramente precisam de um cartão de crédito maior. Eles precisam de um diagnóstico. Antes de você saltar de um droplet de 1 GB por $5/mês para uma instância de $20/mês, verifique se as compilações do Next.js estão estourando devido a um uso de memória curto e pontudo ou a um vazamento constante e lento.

Um simples fluxograma mental mantém você honesto:

- O crash ocorre apenas durante tarefas curtas e infrequentes (compilações do Next.js, `npm install`, migrações)? → Adicione swap primeiro e, em seguida, execute novamente a tarefa. - O servidor parece lento durante o tráfego normal, com alto uso de swap e latência elevada? → Faça um perfil da memória, otimize consultas e caches, ou atualize a RAM. - O uso de swap permanece alto mesmo quando o aplicativo está "ocioso"? → Você está mascarando um problema real de capacidade, não resolvendo-o.

Para cargas de trabalho intermitentes, um arquivo de troca de 1 a 2 GB em uma máquina com 1 GB de RAM frequentemente impede que o OOM killer interrompa sua compilação. Você troca alguns segundos ou minutos extras de tempo de compilação por uma compilação que realmente termina. Isso é um bom negócio quando as implantações ocorrem algumas vezes ao dia, e não milhares de vezes por segundo.

A matemática de custos torna o argumento brutal e claro. Permanecer em uma instância de $5/mês em vez de pular para $15 economiza $10 todos os meses, ou $120 por ano, por servidor. Amplie isso para 5 pequenos serviços e você mantém $600/ano no seu bolso pelo preço de um único `fallocate` e uma linha em `/etc/fstab`.

Escalonamento inteligente significa empilhar ferramentas, e não comprar caixas maiores de forma reflexiva. Use swap para lidar com picos raros, ajuste as flags de memória do Node.js quando as compilações ainda apresentarem problemas e, somente então, faça um upgrade de nível quando seu uso em estado estável provar que você realmente precisa disso.

Você acaba com uma infraestrutura que entende em vez de uma infraestrutura que teme. Quando uma construção falha com “Morto”, você sabe que deve verificar memória, swap e limites do Node.js antes de abrir a página de preços do seu provedor de nuvem. Esse conhecimento transforma a escalabilidade de um movimento de pânico em uma escolha deliberada e econômica.

Por que as builds do Next.js usam tanta memória?

As construções do Next.js são intensivas em memória porque geram múltiplos processos de trabalho para compilar TypeScript, agrupar código do cliente e do servidor, e processar ativos como imagens simultaneamente. Esse breve, mas intenso, surto de atividade pode facilmente sobrecarregar servidores com RAM limitada, como gotas de nuvem de 1GB.

Usar um arquivo de swap no Linux é mau para o desempenho?

A troca é significativamente mais lenta que a RAM, portanto, pode prejudicar o desempenho se sua aplicação contar constantemente com ela para operações diárias. No entanto, para picos de memória breves e infrequentes, como um processo de compilação, a leve desaceleração é uma troca válida pela estabilidade, já que permite que a compilação seja concluída com sucesso em vez de falhar.

Quanto espaço de swap eu devo adicionar para uma construção do Next.js?

Uma boa regra prática para um servidor pequeno (1-2GB de RAM) é adicionar um espaço de swap igual ou o dobro da quantidade de RAM física. Para um droplet de 1GB, criar um arquivo de swap de 1-2GB é frequentemente suficiente para lidar com os picos de memória durante uma compilação do Next.js.

Posso usar swap em vez de atualizar a RAM do meu servidor?

Você pode usar swap para evitar uma atualização se seus problemas de memória forem causados por picos temporários (como compilações ou instalações de pacotes). Se o uso diário de memória do seu aplicativo consistentemente exceder a RAM do seu servidor, você deve atualizar sua RAM, pois depender de swap para tráfego de produção levará a um desempenho ruim.