Um ficheiro de swap grande do ZimaOS não é o mesmo que pressão de swap ativa, e eliminá-lo não é a forma correta de recuperar espaço no disco de arranque. Verifique a utilização real de swap, a pressão de memória, a utilização de disco do Docker, os registos e a localização do AppData antes de alterar a configuração da swap.
O tópico de origem de 2026 atribuía a um ficheiro .swap de 3,8 GB a quase total ocupação de um disco de arranque de 48 GB, mas os cálculos mostraram que a swap representava apenas uma pequena parte do espaço em falta. Mais tarde, o sistema recuperou cerca de 20 GB, o que aponta para uma limpeza temporária do Docker/cache, e não para a redução da swap.
Tamanho de swap reservado vs. utilização ativa da swap
Execute:
free -h
swapon --showUm ficheiro de swap de 4 GB pode existir no disco enquanto apenas uma pequena parte está a ser utilizada. O tamanho do ficheiro corresponde à capacidade reservada; não significa que a RAM tenha transbordado em 4 GB.
Descobrir o que está a ocupar o disco do sistema
Execute:
df -h
du -xh /var/lib/docker --max-depth=1 2>/dev/null | sort -hCamadas de imagens Docker, sobreposições com capacidade de escrita, registos, caches e dados temporários podem ocupar o pequeno disco do sistema, mesmo quando os ficheiros multimédia das aplicações estão mapeados noutro local.
Manter o AppData fora do disco do sistema
O atual guia de dados das aplicações do ZimaOS recomenda explicitamente definir a localização dos dados das aplicações para um espaço de armazenamento, em vez de ocupar o disco do sistema.
Isto não elimina toda a utilização do sistema pelo Docker, mas impede que as bases de dados das aplicações e as caches multimédia consumam, por predefinição, o dispositivo de arranque.
Verificar os registos dos contentores
Um contentor com muita atividade pode aumentar rapidamente os registos JSON. Verifique a utilização de disco do Docker e o tamanho dos registos dos contentores antes de eliminar ficheiros aleatoriamente.
Se uma aplicação for a responsável, corrija o comportamento do respetivo sistema de registo ou rode os registos, em vez de eliminar manualmente ficheiros de registo ativos.
Uma utilização elevada de swap pode ainda significar pressão de RAM
Se free -h mostrar pouca memória disponível e a swap estiver a ser utilizada ativamente, identifique os processos que estão a consumir RAM. Bases de dados pesadas, indexação de fotografias, cargas de trabalho de IA e máquinas virtuais podem levar um sistema com pouca memória a utilizar swap.
Não desative a swap apenas para ocultar o sintoma
A swap pode manter o sistema operacional durante picos breves de utilização de memória. Desativá-la num servidor com memória limitada pode transformar uma lentidão em encerramentos por falta de memória.
Quando adicionar RAM
Adicione RAM quando as cargas de trabalho sustentadas esgotarem consistentemente a memória física e os serviços importantes estiverem a utilizar muito a paginação. Não atualize a RAM apenas porque existe um ficheiro de swap.
O guia de resolução de problemas de desempenho ajuda a evitar tratar todos os servidores lentos como um problema de RAM.
Medir a pressão de memória ao longo do tempo
Uma única amostra de free -h pode induzir em erro, porque o Linux utiliza deliberadamente a RAM livre para cache. Observe a memória disponível e verifique se a atividade de entrada e saída da swap continua durante a carga de trabalho.
Se as ferramentas disponíveis no sistema mostrarem uma utilização sustentada da swap enquanto o servidor está lento, identifique a aplicação ou a máquina virtual que está a consumir memória, em vez de se concentrar apenas no tamanho do ficheiro de swap.
As imagens Docker continuam a consumir espaço do sistema
Mover o AppData para /DATA não move todas as camadas de imagens Docker nem todos os ficheiros de execução. Assim, instalar e atualizar muitas aplicações pode aumentar o espaço ocupado no disco do sistema, mesmo quando todos os volumes de dados visíveis para o utilizador apontam para outro local.
Antes de efetuar uma limpeza, utilize a vista de utilização de disco do próprio Docker para distinguir imagens, contentores, volumes locais e cache de compilação. Remova apenas os objetos que sabe que não estão a ser utilizados.
Verificar se um disco do sistema pequeno é o problema estrutural
Um disco de arranque de 48 GB pode funcionar, mas deixa pouca margem para várias imagens de aplicações, atualizações, registos e operações temporárias. Se o sistema se aproximar repetidamente dos 100% apesar de uma limpeza adequada, um disco do sistema maior ou a transferência de mais cargas de trabalho persistentes para o armazenamento principal poderá ser a solução sustentável.
Pouco espaço livre pode causar falhas secundárias
Quando a área do sistema com capacidade de escrita está quase cheia, as atualizações de aplicações, as gravações em bases de dados, os registos e os ficheiros temporários podem falhar de formas que parecem não estar relacionadas com o armazenamento. Considere o espaço livre muito reduzido um risco operacional, mesmo que o servidor tenha terabytes livres noutra matriz.
Perguntas frequentes
Porque é que o espaço livre em disco voltou durante a noite?
Camadas temporárias do Docker, caches, registos ou tarefas de limpeza podem ter libertado espaço. Isso não significa que o próprio ficheiro de swap tenha diminuído.
Devo eliminar o ficheiro .swap?
Não. Verifique primeiro a utilização ativa da swap e os verdadeiros responsáveis pelo espaço em disco.
É normal ter 3–4 GB de swap?
A existência de um ficheiro de swap com alguns gigabytes não é invulgar. O que importa é a quantidade de swap que está a ser utilizada ativamente e se a pressão de memória é sustentada.
Porque é que o meu disco de arranque continua ocupado quando o AppData está em /DATA?
Os metadados do motor Docker, as camadas de imagens, as sobreposições de execução, os registos e os ficheiros do sistema continuam armazenados fora dos dados das aplicações que mapeou.
