Jump to content
From ArchWiki
< Improving performance (Português)
Status de tradução: Esse artigo é uma tradução de Improving performance/Boot process. Data da última tradução: 2020-04-09. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Artigos relacionados

- Melhorando o desempenho
- Inicialização silenciosa
- Daemon
- e4rat
- Kexec

Melhorar o desempenho de inicialização de um sistema pode fornecer tempos de espera de inicialização reduzidos e um meio de aprender mais sobre como certos arquivos e scripts do sistema interagem entre si. Este artigo tenta agregar métodos sobre como melhorar o desempenho de inicialização de um sistema Arch Linux.

## Analisando o processo de inicialização

### Usando systemd-analyze

systemd fornece uma ferramenta chamada `systemd-analyze` que pode ser usada para mostrar detalhes de tempo sobre o processo de inicialização, incluindo um gráfico svg mostrando as unidades aguardando suas dependências. Você pode ver quais arquivos da unidade estão causando uma lentidão no processo de inicialização. Você pode otimizar seu sistema adequadamente.

Para ver quanto tempo foi gasto no kernelspace e no espaço do usuário na inicialização, basta usar:

    $ systemd-analyze

Dica: Se você inicializar via UEFI e usar um gerenciador de inicialização que implemente a Boot Loader Interface do systemd (que atualmente systemd-boot e GRUB do), systemd-analyze também pode mostrar quanto tempo foi gasto no firmware EFI e no próprio carregador de inicialização.

Para listar os arquivos da unidade iniciada, classificados pelo tempo que cada um deles levou para iniciar:

    $ systemd-analyze blame

Em alguns pontos do processo de inicialização, as coisas não podem continuar até que uma determinada unidade seja bem-sucedida. Para ver quais unidades se encontram nesses pontos críticos da cadeia de inicialização, faça:

    $ systemd-analyze critical-chain

Você também pode criar um arquivo SVG que descreva graficamente seu processo de inicialização, semelhante a Bootchart:

    $ systemd-analyze plot > plot.svg

Consulte systemd-analyze(1) para detalhes.

### Usando bootchart2

Você também pode usar uma versão do bootchart para visualizar a sequência de inicialização. Como você não pode colocar um segundo init na linha de comando do kernel, não poderá usar nenhuma das configurações padrão do bootchart. No entanto, o pacote bootchart2AUR do AUR vem com um serviço systemd não documentado. Depois de instalar o bootchart2, faça:

    # systemctl enable bootchart2

Você pode visualizar os resultados abrindo `/var/log/bootchart.png` ou, se desejar mais recursos, iniciando:

    $ pybootchartgui -i

Leia a documentação do bootchart2 para obter mais detalhes sobre o uso desta versão do bootchart.

## Compilando um kernel personalizado

A compilação de um kernel personalizado pode reduzir o tempo de inicialização e o uso de memória. Embora com a padronização da arquitetura de 64 bits e a natureza modular do kernel Linux, esses benefícios não sejam tão grandes quanto o esperado. Consulte Kernel#Compilação para mais informações.

## Initramfs

Em uma abordagem semelhante a #Compilando um kernel personalizado, o initramfs pode ser reduzido. Uma maneira simples é incluir o hook `autodetect` do mkinitcpio. Se você quiser ir além disso, consulte Minimal initramfs.

## Início antecipado para serviços

Um recurso central do systemd é o D-Bus e a ativação do soquete. Isso faz com que os serviços sejam iniciados quando são acessados pela primeira vez e geralmente é uma coisa boa. No entanto, se você souber que um serviço (como upower) sempre será iniciado durante a inicialização, o tempo total de inicialização poderá ser reduzido iniciando-o o mais cedo possível. Isso pode ser alcançado (se o arquivo de serviço estiver configurado para ele, o que na maioria dos casos é) emitindo:

    # systemctl enable upower

Isso fará com que o systemd inicie o UPower o mais rápido possível, sem causar corridas com a ativação do D-Bus ou soquete.

## Rotação escalonada

Alguns implementos de hardware rotação escalonada (ou staggered spin-up), o que faz com que o sistema operacional examine as interfaces ATA em série, o que pode girar as unidades um a um e reduzir o consumo de energia de pico. Isso diminui a velocidade de inicialização e, na maioria dos hardwares de consumo, não oferece benefícios, pois as unidades já irão girar imediatamente quando a energia for ligada. Para verificar se SSS está sendo usado:

    # dmesg | grep SSS

Se não foi usado durante a inicialização, não haverá saída.

Para desativá-lo, adicione parâmetro do kernel `libahci.ignore_sss=1`.

## Montagem dos sistemas de arquivos

Graças ao hook `fsck` do mkinitcpio, você pode evitar uma remontagem possivelmente cara da partição raiz alterando `ro` para `rw` na linha do kernel: as opções podem ser definidas com `rootflags=rw, outros_pontos_de_montagem`. A entrada deve ser removida do arquivo `/etc/fstab`, caso contrário, o `systemd-remount-fs.service` continuará tentando aplicar essas configurações. Como alternativa, pode-se tentar mascarar essa unit.

Se o btrfs estiver em uso para o sistema de arquivos raiz, não há necessidade de um fsck em cada inicialização, como outros sistemas de arquivos. Se for esse o caso, o gancho `fsck` de mkinitcpio pode ser removido. Você também pode mascarar o `systemd-fsck-root.service` ou pedir para não fsck o sistema de arquivos raiz na linha de comando do kernel usando `fsck.mode=skip`. Sem o hook `fsck` de mkinitcpio, o systemd ainda fsck qualquer sistema de arquivos relevante com o `systemd-fsck@.service`

Você também pode remover os sistemas de arquivos de API do `/etc/fstab`, pois o systemd os montará (consulte `pacman -Ql systemd | grep '\.mount$'` para uma lista). Não é incomum que os usuários tenham uma entrada `/tmp` transferida do sysvinit, mas você deve ter notado no comando acima que o systemd já cuida disso. Portanto, ele pode ser removido com segurança.

Outros sistemas de arquivos como `/home` ou partição de sistema EFI podem ser montados com unidades de montagem personalizadas. Adicionar `noauto,x-systemd.automount` às opções de montagem armazenará em buffer todo o acesso a essa partição e vai executar fsck e mount no primeiro acesso, reduzindo o número de sistemas de arquivos que eles devem fsck/montar durante o processo de inicialização.

Nota:

- Isso tornará seu sistema de arquivos `/home` tipo `autofs`, que é ignorado por mlocate por padrão. A aceleração da montagem automática `/home` pode não ser superior a um segundo ou dois, dependendo do seu sistema, portanto, esse truque pode não valer a pena.
- Se o sistema estiver instalado em um subvolume btrfs (especificamente: o próprio diretório raiz `/` é um subvolume) e `/home` é um sistema de arquivos separado, você também pode desejar para impedir a criação de um subvolume `/home`. Mascare o arquivo tmp `home.conf`: `ln -s /dev/null /etc/tmpfiles.d/home.conf`.

## Menos saída durante a inicialização

Para alguns sistemas, particularmente aqueles com um SSD, o desempenho lento do TTY é realmente um gargalo e, portanto, menos saída significa uma inicialização mais rápida. Consulte o artigo Inicialização silenciosa para obter sugestões.

## Suspensão para RAM

A melhor maneira de reduzir o tempo de inicialização é não inicializar. Considere suspender seu sistema para a RAM.

Category:

- Boot process (Português)