Ubuntu Server 24.04 Minimal vs Standard: Análise dos Benchmarks de Desempenho

Um servidor virtual privado (VPS) está com pouca memória, então você reinstala o Ubuntu Server 24.04 LTS e se depara com uma escolha inicial: a instalação padrão do Ubuntu Server ou o Ubuntu Server (minimizado). É tentador presumir que menos pacotes significam automaticamente requisições web mais rápidas, consultas de banco de dados mais curtas e maior desempenho da CPU. A diferença é mais sutil. Um conjunto inicial de pacotes menor pode reduzir o uso de disco e a atividade em segundo plano, mas isso não torna, por si só, o processador ou o dispositivo de armazenamento mais rápidos.

Resumindo: escolha a instalação minimizada quando desejar um ponto de partida enxuto e se sentir confortável em adicionar apenas as ferramentas necessárias. Escolha a instalação padrão quando desejar o conjunto de ferramentas padrão do servidor mais abrangente. Compare o tempo de inicialização, a memória ociosa, o espaço em disco e o desempenho real do aplicativo separadamente, em vez de agrupá-los em um único rótulo de "mais rápido".

Nota sobre as evidências (9 de outubro de 2026): Este artigo explica um método de avaliação comparativa reproduzível e os resultados que cada métrica pode gerar. Ele não apresenta as pontuações originais medidas em duas instalações idênticas do Ubuntu 24.04. Nenhum valor não verificado de RAM, disco, tempo de inicialização ou taxa de transferência é apresentado como resultado dos testes.

Qual a diferença entre o Ubuntu Server padrão e o minimizado?

O instalador Subiquity do Ubuntu Server oferece duas fontes de instalação: uma ubuntu-serverpara a versão padrão (a padrão) e outra ubuntu-server-minimalpara a versão minimizada. A Canonical documenta esses identificadores de fonte e recomenda verificar casper/install-sources.yamla ISO escolhida, pois os identificadores do instalador podem mudar. Consulte a documentação da fonte de instalação automática do Subiquity da Canonical .

Ambos são Ubuntu Server 24.04 LTS, não duas arquiteturas de CPU otimizadas de forma diferente ou distribuições Linux separadas. O que muda principalmente é o software entregue durante a instalação. Os pacotes que aparecem dependem da revisão da mídia de instalação, das opções escolhidas, das atualizações, dos drivers e dos aplicativos instalados posteriormente. Não assuma que uma lista publicada para uma determinada versão da imagem se aplica sem alterações a todos os instaladores de versões pontuais do Ubuntu 24.04.

A opção de servidor minimizado não deve ser confundida com as imagens de nuvem mínimas do Ubuntu , uma família de imagens separada, ou com a opção de instalação mínima do Ubuntu Desktop. As notas de lançamento do Ubuntu 24.04 LTS mencionam uma redução substancial na quantidade de pacotes e no tamanho do download das imagens de nuvem mínimas em relação às versões anteriores. Esses exemplos de imagens de nuvem publicados não constituem um benchmark controlado de ISOs de servidor live padrão versus minimizado, e seus números não devem ser reutilizados como se fossem.

Quais indicadores de desempenho são importantes?

O comportamento esperado não é um resultado mensurável. Uma máquina otimizada pode consumir menos recursos imediatamente após a instalação. Mas, uma vez que ambas as máquinas estejam executando o mesmo banco de dados, ambiente de execução de contêiner, agente de monitoramento e servidor web, a diferença observada pode diminuir, desaparecer ou mudar de direção. A única conclusão defensável vem da medição da carga de trabalho alvo.

Comece com uma configuração de teste justa, não com um cronômetro.

Crie duas máquinas virtuais descartáveis ​​a partir da mesma revisão ISO do Ubuntu Server 24.04 LTS, uma padrão e outra minimizada. Atribua contagens idênticas de vCPUs, RAM, discos virtuais, sistemas de arquivos, modo de inicialização, configurações do hipervisor, conexão de rede e classe de armazenamento. Para as máquinas físicas, use hardware equivalente e teste sob condições térmicas e de energia semelhantes. Mantenha as máquinas virtuais fora do tráfego de produção.

Em ambos os sistemas, aplique as mesmas atualizações de segurança e reinicie. Registre os cat /etc/os-releasevalores de `<nome_do_sistema> uname -r`, `<nome_do_sistema>` e `<nome_do_sistema> lscpu`, além da versão da imagem do instalador e a data do teste. O Ubuntu Server 24.04 normalmente usa o kernel de disponibilidade geral, mas pode opcionalmente usar kernels com suporte a hardware (HWE); diferentes versões do kernel comprometeriam uma comparação baseada apenas no tipo de instalação. A documentação do kernel do Ubuntu sobre kernels GA e HWE explica essa distinção.

Reúna dois conjuntos de medidas:

1. Configuração básica de instalação limpa: Imediatamente após atualizações idênticas, antes da instalação de uma carga de trabalho. Isso isola as diferenças práticas nas configurações padrão de instalação.
2. Configuração inicial semelhante à de produção: após instalar os mesmos pacotes de aplicativos, habilitar os mesmos serviços e aplicar configurações idênticas, verifica-se se a diferença inicial na infraestrutura ainda é relevante.

Use pelo menos várias execuções por teste, de preferência cinco ou mais após um aquecimento, e compare as medianas, bem como a variabilidade. Reinicie e meça o tempo de inicialização em várias inicializações. Nunca compare um resultado de inicialização a frio em um sistema com um resultado de inicialização já aquecida em outro.

Comece por medir as diferenças mais simples.

1. Conte os pacotes instalados e verifique o espaço em disco.

A quantidade de pacotes e o uso de armazenamento geralmente são as características mais fáceis de verificar. Em cada máquina virtual, execute:

dpkg-query -W -f='${binary:Package}\n' | wc -l
df -h /
lsblk -f

Registre a contagem, o espaço usado no sistema de arquivos raiz e o layout do sistema de arquivos. Certifique-se de que as partições raiz tenham tamanhos comparáveis; caso contrário, uma diferença aparente pode ser decorrente do particionamento. O uso do disco também inclui logs, caches de pacotes e metadados do sistema de arquivos, portanto, horários de instalação idênticos e históricos de atualização comparáveis ​​são importantes.

2. Compare a RAM disponível, não apenas a RAM "livre".

Após ambos os sistemas permanecerem ociosos por um período consistente de estabilização, execute:

free -h
systemctl --type=service --state=running --no-pager

Observe também a availablecoluna `cache` . O Linux utiliza memória ociosa para cache, que pode ser liberada quando os aplicativos precisarem. Um valor menor na coluna `cache` não indica automaticamente um problema. Verifique se o uso adicional de memória pertence a serviços que você realmente pretende manter.freeusedfree

3. Compare o tempo de inicialização e identifique os serviços lentos.

Para cada inicialização, utilize as ferramentas systemd fornecidas com a distribuição:

systemd-analyze time
systemd-analyze blame
systemd-analyze critical-chain

systemd-analyze timeO relatório indica o tempo de inicialização, mas isso não significa necessariamente que o aplicativo esteja pronto para aceitar solicitações. A blamelista também pode ser enganosa, pois as unidades podem ser inicializadas em paralelo e alguns tipos de serviço não são medidos da mesma maneira. Investigue a cadeia crítica e, em seguida, verifique separadamente o endpoint de serviço específico que lhe interessa. Essas limitações estão documentadas no manual do systemd-analyze do Ubuntu 24.04 .

Por exemplo, se um servidor executa uma API HTTP, meça o tempo decorrido desde a reinicialização até que o endpoint de integridade da API seja acessado com sucesso. Se um host executa um banco de dados, verifique se uma consulta é bem-sucedida. Essa medição de prontidão é mais útil do que simplesmente verificar se o sistema operacional atingiu um ponto de inicialização específico.

Em seguida, teste a CPU e o armazenamento sob carga controlada.

4. Execute a mesma carga de trabalho da CPU em ambas as máquinas.

Para uma comparação simples de CPUs, instale uma versão idêntica do sysbench em cada máquina virtual descartável após registrar o consumo de recursos da instalação limpa. Em seguida, execute o mesmo comando:

sudo apt update
sudo apt install sysbench
sysbench --threads=1 --time=30 cpu --cpu-max-prime=20000 run

Compare o número de eventos por segundo e a latência em execuções repetidas. A documentação do projeto sysbench fornece a sintaxe do comando e o teste de CPU integrado. Use uma segunda execução com a mesma contagem de threads mais alta somente se ela corresponder à contagem de CPU atribuída. Um conjunto de pacotes reduzido por si só não justifica a alegação de um aumento de velocidade da CPU; diferenças inesperadas devem levar a uma verificação da contenção da CPU do host, do comportamento do relógio, da versão do kernel e dos processos em segundo plano.

5. Teste de E/S de disco sem realizar benchmarks em um disco de produção.

Para um experimento opcional de armazenamento, instale o fio em ambas as máquinas de teste e crie arquivos de teste idênticos em um sistema de arquivos descartável com bastante espaço livre. Os comandos a seguir criam um arquivo de 256 MiB no diretório inicial do usuário atual e, em seguida, executam uma carga de trabalho de leitura aleatória limitada nesse arquivo:

sudo apt install fio
dd if=/dev/urandom of="$HOME/fio-sample.bin" bs=1M count=256 status=progress
fio --name=randread --filename="$HOME/fio-sample.bin" --rw=randread --bs=4k --size=256M --ioengine=libaio --iodepth=16 --direct=1 --runtime=30 --time_based --group_reporting

Execute ambas as máquinas com discos e parâmetros de E/S idênticos. Um arquivo de 256 MiB pode ser muito pequeno para modelar seu banco de dados ou dispositivo de armazenamento com precisão; aumente o tamanho do arquivo e varie a carga de trabalho somente quando houver espaço suficiente disponível para testes temporários e um ambiente de teste seguro. Registre a distribuição de IOPS, largura de banda e latência, não apenas o maior valor de largura de banda. O manual do fio do Ubuntu 24.04 explica os parâmetros de carga de trabalho. Nunca execute testes de gravação em um dispositivo de bloco bruto que contenha dados úteis.

6. Teste o aplicativo real por último.

Instale exatamente a mesma pilha de aplicativos em ambas as máquinas, incluindo versões web e de banco de dados, limites de conexão, registro de logs, TLS, cache e monitoramento. Envie uma combinação equivalente de requisições a partir de um gerador de carga separado, com a mesma concorrência e duração do teste. Meça a taxa de transferência, a latência de resposta mediana e do 95º percentil, a taxa de erros, a utilização da CPU, a pressão na memória e o uso de swap. Utilize o mesmo conjunto de dados e certifique-se de que nenhuma das máquinas compartilhe um backend de armazenamento ruidoso sem considerar a contenção.

Para um servidor de API pequeno, uma diferença na memória ociosa é relevante se uma das configurações começar a usar a memória virtual (swap) durante períodos de carga. Para um servidor com uso intensivo de CPU e bastante RAM disponível, o mesmo binário de aplicação pode apresentar desempenho essencialmente similar. Nenhum dos dois resultados pode ser garantido antes de testes.

Como interpretar resultados de benchmarks conflitantes

• Menor número de pacotes, mas pontuações de CPU iguais: Isso é totalmente coerente. Menos ferramentas instaladas não necessariamente alteram o desempenho computacional.
• Menor uso de disco, mas IOPS iguais: Espaço livre e velocidade do dispositivo são propriedades diferentes. Analise o hardware de armazenamento, o padrão de E/S, o sistema de arquivos e o cache.
• Inicialização do systemd mais rápida, mas preparação da aplicação igualmente lenta: o gargalo pode estar na inicialização da aplicação, nas dependências de rede ou na recuperação do banco de dados.
• Menos RAM ociosa, mas latência de requisição igual: a configuração minimizada pode oferecer uma folga de capacidade útil, embora a carga de trabalho atual não esteja limitada pela memória.
• Variações drásticas nos resultados entre as execuções: investigue a influência de vizinhos ruidosos, escalonamento da frequência da CPU, atualizações, tarefas agendadas, limitação térmica e aquecimento do cache antes de declarar um vencedor.

Se a vantagem observada for apenas uma pequena quantidade de espaço ocioso em disco, mas seu fluxo de trabalho operacional depender repetidamente de utilitários de administração ausentes, a instalação padrão pode ser a opção mais produtiva. Se seus servidores forem provisionados automaticamente e executarem um serviço bem definido, uma base mínima geralmente facilita a auditoria da seleção de pacotes.

Você deve mudar um servidor existente para o modo minimizado?

Geralmente, o objetivo não é apenas atingir números de benchmark. Para uma instalação padrão funcional, primeiro inspecione os serviços ativos e meça o desempenho da aplicação. Remover pacotes irrelevantes pode não melhorar uma carga de trabalho já adequada, e a remoção descuidada de pacotes pode comprometer a rede, a recuperação, o registro de logs ou o gerenciamento remoto. As diretrizes de segurança da Canonical para Ubuntu sobre pacotes desnecessários recomendam escolher uma instalação inicial mínima adequada em vez de remover indiscriminadamente os pacotes padrão.

Se uma reinstalação for necessária, faça backup dos dados e da configuração, verifique a restauração, instale a opção minimizada em uma nova instância e provisione explicitamente os pacotes necessários. Valide o acesso SSH, as atualizações, a sincronização de horário, os backups, o monitoramento, a política de firewall e a integridade do aplicativo antes de migrar o tráfego. Se um administrador depende regularmente de diagnósticos integrados ou de funções variadas, a instalação padrão pode ser preferível, mesmo que o tamanho da instalação seja maior.

A segurança é um aspecto relacionado, mas distinto: menos pacotes podem reduzir a quantidade de software que você precisa manter, mas isso não comprova uma redução específica de vulnerabilidades CVE. Ambos os tipos de instalação ainda exigem atualizações de segurança e reforço da segurança dos serviços.

Lista de verificação final

• Confirme se ambas as máquinas são Ubuntu Server 24.04 LTS com a mesma arquitetura, nível de patch, versão do kernel e geração do instalador.
• Documente a seleção da versão padrão ou minimizada, as opções de instalação opcionais e os serviços adicionados posteriormente.
• Compare a quantidade de pacotes, o uso do sistema de arquivos raiz e a memória disponível após atualizações idênticas e um período de estabilização ocioso.
• Repita as medições de inicialização e prontidão do aplicativo em várias reinicializações, relatando as medianas em vez de uma única execução ideal.
• Utilize parâmetros correspondentes para cargas de trabalho de CPU, armazenamento e aplicativos e registre as distribuições de erros e latência.
• Execute a aplicação com dependências, configuração e dados idênticos e, em seguida, decida se alguma diferença afeta a capacidade, a confiabilidade ou o tempo de implantação.

Conclusão prática: a configuração minimizada geralmente é a melhor opção inicial para servidores automatizados com escopo restrito; a configuração padrão oferece um conjunto de ferramentas padrão mais completo. Nenhuma das opções é universalmente mais rápida. No Ubuntu Server 24.04 LTS, o benchmark mais útil é aquele que mede o desempenho do seu serviço sob a carga de trabalho que ele realmente precisa suportar.