07/09/20
Atualização sobre lvm
Revisão: 02/09/20
- adicionado link para otimizar initramfs
- adiconado procedimento com xubuntu em um celeron
Revisão: 31/08/20
- Passo quatro remnovido
- Adicionado mais 5 passos, do nono ao décimo terceiro
- Adicionado links de pesquisa
Este conteúdo faz parte de uma série de tópicos que decidi criar, por causa de um bate-papo no fórum.
- [Distro/Desktop] Para que serve esta unit (unidade do systemd)? Não sabe? Comente aqui!
- [Distro/Desktop] Otimizando o Gnome3 - 10 passos (atualizado 07/09/20)
Primeiro tutorial que faço de modo offline, achei que ficou mais fácil a visualização.
Fontes pesquisadas para este tópico: (tem outras que no momento não encontro, mas vou colocar depois)
- CentOS / RHEL 7 : How to disable all tty consoles and enable only 1 – The Geek Diary
- Logging w/ journald: Why use it & how it performs vs syslog - Sematext
- https://www.it-swarm.dev/pt/boot/qual-e-utilidade-do-systemd-journal-flush.service/998366969/
- Erik's cheat sheet
- https://www.it-swarm.dev/pt/security/o-que-e-apparmor/961447761/
- 14.4. Introdução ao AppArmor
- https://wiki.archlinux.org/
Os passos que serão citados são pequenas configurações que podem otimizar o systemd. O ganho de memória e tempo de boot depende da sua máquina. Assuntos de compilação de kernel e outros meios não vou falar, pois hoje o ganho é quase nulo e é trabalhoso. Lembre-se que podemos remover ou desativar recursos e serviços. Caso venha utilizar eles no futuro terá que ativá-los. E também vamos configurar serviços e opções nativas do systemd.
Dependendo da máquina o melhor ganho é colocar ambientes desktop leves.
Otimizando systemd
Recomendo otimizar o systemd, e não só o ambiente desktop. Quanto antes acabar o carregamento do sistema mais rápido terminará e subirá o Wayland ou X11.
O ganho vai depender de serviços que rodam nele. Quanto mais serviços, e se o serviço for pesado, mais memória consumirá e mais tempo demorará para subir o desktop.
Não existe distro mais pesada que outra, lembre-se que os serviços e arquivos utilizados são os mesmos. Há uma padronização de instalação que cada distro escolhe , direcionados para notebooks ou não, e dependendo da distro você terá que instalar e configurar um determinado tipo de serviço pós-instalação, pode ser para economizar energia, compartilhar arquivos e outras tarefas.
Contudo podemos otimizar desativando serviços, customizando consoles e outros procedimentos.
Para se ter uma noção, instalando somente serviço de conexão e gerenciador de login em uma instalação com a distro Arch executada no virt-manager com 4GB de memória e 2 CPU demora 3 segundos para subir o sistema e 9 segundos para subir o ambiente Gnome.
O caminho é saber o que realmente precisa para ser inicializado no boot. Não recomendo tirar o que não sabe, procure saber antes de desativar. Para isso vou criar um tópico no fórum dedicado a isso.
Exemplos de máquinas que uso:
Procedimento com xubuntu em um celeron : [Distro/Desktop] Otimizando o systemd - 8 passos (adic. 5 passos e removido 1) 07/09/20 - #21 by swatquest
Configuração:
- Intel(R) Core™ i7-4770 CPU @ 3.40GHz
- 16GB de RAM
- Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
- SSD Kingston HyperX de 120GB – leitura 555MB e escrita 510MB
Antes demorava em torno de 35 segundos para iniciar Wayland no openSUSE com o usuário conectando automaticamente no gdm ao ambiente.
Resultado com sistema Arch e ambiente Gnome: [Distro/Desktop] Otimizando o systemd - 8 passos (adic. 5 passos e removido 1) 07/09/20 - #20 by swatquest
Resultado pelo systemd-analyze no openSUSE:
Como não sei se todos conhecem a leitura deste recurso, vai uma breve explicação da leitura.
Resultado do systemd-analyze com as modificações
~ $ systemd-analyze
Startup finished in 1.503s (kernel) + 2.889s (initrd) + 3.911s (userspace) = 8.303s
graphical.target reached after 3.899s in userspace
~ $ systemd-analyze –user
Startup finished in 500ms (userspace)
default.target reached after 500ms in userspace
~ $ systemd-analyze --user blame | grep -i wayland
5.313s gnome-shell-wayland.service
O primeiro é o tempo de inicialização do sistema até graphical.target. Isso pode ser visto pelo comando:
systemd-analyze plot > sistema.svg
Apenas a leitura da opção time é o suficiente, já que cada um inicia em um determinado tempo e termina na graphical.target. Logo temos:
8.303 + 3.899 = 12.202s
Analisando a sessão do usuário pela opção –user, vemos que tudo começa junto depois que default.target é iniciado. Repare que o valor é o mesmo.
Pode ser visto com a opção plot com –user.
systemd-analyze --user plot > usuários.svg
Logo adicionamos o tempo que o gnome-shell é inicializado, então:
0.500 + 5.313 = 5.813s
Para o cálculo final somamos o tempo das duas sessões:
12.202 + 5.813 = 18.015s
Agora leva 18.015s para inciar o Wayland.
Primeiro passo: Mascarando serviços não encontrados
Primeiro passo:
Mascarar unidades não instaladas. Para saber as unidades, execute:
Para sessão do sistema
systemctl -a -t not-found
Para sessão do usuário
systemctl –user -a -t not-found
Após descobrir todos os not-founds, vamos mascarar. Para isso execute os comandos:
Para sessão do sistema
sudo systemctl mask unidades-not-found
Para sessão do usuário
systemctl –user mask unidades-not-found
**Obs: **Caso queira desmascarar alguma unidade, use **unmask **.
Com isso já ganhamos algum tempinho. Pois o systemd não perderá tempo checando a unidade.
Segundo passo: Utilizando a automontagem de partições
Segundo passo:
Para otimizar o tempo de boot é interessante colocar as partições /boot ou /boot/efi, e também a partição /home (geralmente a maior) em modo automount. Você ganha de 1 a 4 segundos dependendo da máquina.
Para este processo adicione em /etc/fstab as opções de montagem nestas partições:
,noauto,x-systemd.automount
Exemplo: (não esqueça da vírgula)
/dev/sdb3 /home xfs defaults,noauto,x-systemd.automount 0 0
Nota: Podemos instalar sistemas Linux em uma só partição, mas para ter uma melhor performance é recomendado dividir com as partições /boot, /,e /home (caso use SSD também a /var)
Terceiro passo: Desativando rotação escalonada
Terceiro passo:
Rotação escalonada
Alguns hardwares implementam a rotação escalonada, o que faz com que o sistema operacional analise as interfaces ATA em série, o que pode aumentar a rotação dos drives um a um e reduzir o uso de energia de pico. Isso diminui a velocidade de inicialização e, na maioria dos hardwares de consumidor, não oferece nenhum benefício, pois as unidades já funcionam imediatamente quando a energia é ligada. Para verificar se o SSS está sendo usado:
dmesg | grep SSS
Se não foi usado durante a inicialização, não haverá saída.
Para desativar adicione na linha do kernel do grub o parâmetro:
libahci.ignore_sss=1
Para modo permanete modifique o arquivo /etc/default/grub.
Na linha
GRUB_CMDLINE_LINUX_DEFAULT=“adicione aqui dentro das aspas”
Salve e atualize o grub.
Cada distro tem um comando, pesquise para saber qual usar:
Exemplos:
**Ubuntu **
sudo update-grub
**Arch **
sudo grub-mkconfig -o /boot/grub/grub.cfg
[details=“Quarto passo: Utilizando o início precoce para serviço” ] Atenção: efeito contrário.
## Quarto passo:
Início precoce para serviços
Um recurso central do systemd é o D-Bus e ativação de soquete. Isso faz com que os serviços sejam iniciados quando eles são acessados pela primeira vez e geralmente é uma coisa boa. No entanto, se você sabe que um serviço (como o upower) sempre será iniciado durante a inicialização, o tempo geral de inicialização pode 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
[/details]
Quinto passo: Desabiltando todos consoles tty ou não
Quinto passo:
Desabilitar todos consoles tty ou não e habilitar somente 1
tty básico
- Pode-se alternar do tty1 até tty6 usando Ctrl + Alt + F [1-6] .
- Isso continua até tty6, ou seja, o número padrão de consoles tty permitidos são 6. ttys são gerenciados pelo systemd.
- Consoles tty são criados durante o acesso.
- O número permitido de consoles pode ser configurado no arquivo /etc/systemd/logind.conf .
Desative todos os consoplymouth-quit-wait.serviceles tty
NAutoVTs - Defina-o com um número desejado para que o systemd seja capaz de gerar muitos consoles tty. O padrão é 6. Quando definido como 0, a geração automática de serviços autovt é desabilitada.
ReserveVT - Pega um número inteiro positivo. Identifica um terminal virtual que deve ser incondicionalmente reservado para ativação autovt @ .service . O padrão é 6 (em outras palavras, sempre haverá um “getty” disponível no Alt-F6.). Quando definido como 0, a reserva VT é desativada.
Nota : N é o número de tty que você deseja ativar. Aceita um valor inteiro positivo. As ttys serão utilizadas por boot, desktop não serão desativadas.
Habilitar um console tty
- Para habilitar um único console tty, defina os parâmetros abaixo no arquivo /etc/systemd/logind.conf .
sudo nano /etc/systemd/logind.conf
NAutoVTs = 0
ReserveVT = 1
Se quiser reservar a 3 e ela não é utilizada por nenhum outro serviço. É o que uso. Deixo pelo menos uma se eu precisar.
sudo nano /etc/systemd/logind.conf
NAutoVTs = 0
ReserveVT = 3
Obs: O GDM roda em algumas distros na vt7, isso continuará assim, o desktop roda no vt2, isso continuará assim.
Mais informações
`man logind.conf
Sexto passo: Desabilitando serviços do boot que não for utilizar
Sexto passo:
**Desabilitar serviços **
ATENÇÃO: Isso é apenas uma sugestão
Para desabilitar do boot
sudo systemctl disable o-nome-da-unidade
NetworkManager-wait-online.service serve para acessar automaticamente recursos remotos.
sssd.service utilizado para logins com usuários de rede. Serviço relacionado ao ldap. Se você não faz login por rede pode desabilitar.
lvm2-monitor.service gerencia unidades configuradas em LVM. Se você não usa LVM pode desabilitar.
dvboxrv.service, vboxballoonctrl-service.service, vboxautostart-service.service, vboxweb-service.service serviços relacionados ao VirtualBox. É seguro desabilitar.
abrtd.service ferramenta de relatório de crash do sistema. Pode ser desabilitado para não rodar na inicialização.
avahi-daemon.service permite descobrir automaticamente os recursos de rede e se conectar a eles.
geoclue.service é um serviço D-Bus que fornece informações de localização. O objetivo do projeto Geoclue é tornar a criação de aplicativos com reconhecimento de localização o mais simples possível. ( só desativa se mascarar)
cron.service é um agendador. Se não for utilizar desative. Os serviços timer do systemd já fazem isso.
plymouth-quit-wait.service como o próprio nome já diz, espera serviços para finalizar. Se usa SSD recomendo desativar, para HDD pode tamb;em ganhar algum tempo. Não atrapalha em nada desativá-lo.
smb e nmb – Você realmente usa a rede. Usa somente para compartilhar impressora. Recomendo compartilhar via cups. (pode ganhar uns 4 segundos)
Para Windows é só colocar o caminho
Exemplo: ip da máquina que está a impressora
http://192.168.2.2:631/printers/Deskjet_2510
Para Linux é o mesmo processo, mas usa ipp
ipp://192.168.2.2:631/printers/Deskjet_2510
Mas claro, você tem que entrar na configuração do cups no navegador e marcar a opção compartilhar e abrir a porta tcp 631 do firewall se estiver habilitado.
Caso queira ativar temporariamente o serviço do samba
sudo systemctl start smb nmb
Atenção: Recomendo ver o nome do serviço da sua distro para este processo.
fstrim – serviço de trim para SSD. Se não tem, pode desativar.
Bluetooth – se não tem , pode desativar.
Sétimo passo: Limitando o tamanho do registro journal
Limite no tamanho do registro do journal
Se o journal é persistente (não volátil), seu tamanho limite é definido para um valor padrão de 10% do tamanho do respectivo sistema de arquivos, mas limitado a 4 GB. Por exemplo, com o /var/log/journal localizado em uma partição de 20 GB, o journal pode usar até 2 GB. Em uma partição de 50 GB, ela usaria no máximo até 4 GB.
O tamanho máximo do journal persistente pode ser controlado removendo o comentário e alterando o seguinte: ( definido para 50 ,100 ou outro valor)
/etc/systemd/journald.conf
SystemMaxUse=100M
Reinicie o systemd-journald.service após alterar essa configuração para aplicar imediatamente o novo limite.
sudo systemctl restart systemd-journald.service
Oitavo passo: Habilitando cliente NTP nativo do systemd
**OBS: **O Gnome se não tem nenhum outro serviço instalado utiliza este.
systemd-timesyncd é um daemon que foi adicionado para sincronizar o relógio do sistema na rede. Ele implementa um cliente SNTP. Em contraste com implementações NTP, como **chrony **ou o servidor de referência **NTP * *, isso apenas implementa um lado do cliente e não se preocupa com a complexidade total do NTP, focando apenas em consultar o tempo de um servidor remoto e sincronizar o relógio local para ele. A menos que você pretenda servir NTP para clientes em rede ou deseja se conectar a relógios de hardware locais, este cliente NTP simples deve ser mais do que apropriado para a maioria das instalações. O daemon é executado com privilégios mínimos e foi conectado ao networkd para operar apenas quando a conectividade de rede estiver disponível. O daemon salva o relógio atual no disco toda vez que uma nova sincronização NTP é adquirida e usa isso para possivelmente corrigir o relógio do sistema no início da inicialização, a fim de acomodar sistemas que não possuem um RTC, como o Raspberry Pi e dispositivos incorporados, e certifique-se de que o tempo progride monotonicamente nesses sistemas, mesmo que nem sempre seja correto. Para fazer uso deste daemon, um novo usuário do sistema e grupo “systemd-timesync” precisa ser criado na instalação do systemd.
Iniciar/habilitar systemd-timesyncd.service que está disponível com o systemd .
sudo systemctl start systemd-timesyncd.service
sudo systemctl enable systemd-timesyncd.service
Ao iniciar, o systemd-timesyncd lerá o arquivo de configuração /etc/systemd/timesyncd.conf, que se parece com este: Exemplo do openSUSE.
/etc/systemd/timesyncd.conf
[Time]
#NTP=
#FallbackNTP=0.opensuse.pool.ntp.org 1.opensuse.pool.ntp.org 2.opensuse.pool.ntp.org 3.opensuse.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048Para adicionar servidores de horário ou alterar os fornecidos, descomente a linha relevante e liste seus nomes do host ou ip separados por um espaço. Por exemplo, você pode usar qualquer servidor fornecido pelo projeto NTP pool:
pool.ntp.org: NTP Servers in Brazil, br.pool.ntp.org
/etc/systemd/timesyncd.conf
[Time]
NTP=0.br.pool.ntp.org 1.br.pool.ntp.org 2.br.pool.ntp.org 3.br.pool.ntp.org
FallbackNTP=0.opensuse.pool.ntp.org 1.opensuse.pool.ntp.org 2.opensuse.pool.ntp.org 3.opensuse.pool.ntp.org**Informações **
NTP → Uma lista separada por espaço de nomes de host de servidor NTP ou endereços IP. Durante o tempo de execução, esta lista é combinada com quaisquer servidores NTP por interface adquiridos de systemd-networkd.service (8). systemd-timesyncd entrará em contato com todos os servidores configurados do sistema ou com interface por vez até que seja encontrado um que responda. Quando a string vazia é atribuída, a lista de servidores NTP é redefinida e todas as atribuições anteriores a esta não terão efeito. Esta configuração é padronizada para uma lista vazia.
FallbackNTP → Uma lista separada por espaço de nomes de host de servidor NTP ou endereços IP a serem usados como servidores NTP de fallback (ou reserva). Quaisquer servidores NTP por interface obtidos de systemd-networkd.service (8) têm precedência sobre esta configuração, assim como qualquer servidor configurado via NTP = acima. Portanto, essa configuração é usada apenas se nenhuma outra informação do servidor NTP for conhecida. Quando a string vazia é atribuída, a lista de servidores NTP é redefinida e todas as atribuições anteriores a esta não terão efeito. Se esta opção não for fornecida, uma lista compilada de servidores NTP será usada. Normalmente esta opeção já vem preenchida com as configuraçòes da distro
Informaçòes do uso:
systemd-timesyncd - ArchWiki
systemd-timesyncd.service
Nono passo: Otimizando o apparmor
Apparmor é um sistema de controle de acesso obrigatório (ou MAC). Ele usa aprimoramentos de kernel do LSM para restringir programas a determinados recursos. O AppArmor faz isso com perfis carregados no kernel quando o sistema é iniciado. Apparmor tem dois tipos de modos de perfil, fiscalização e reclamação.
A instalaçào dele é recomendada. Algumas distros já vem com ele por padrão.
Ele pode demorar até 6s ou mais. Para otimizar usaremos o recurso de cache dele. Assim o carregamento ficará bem mais rápido.
Como o AppArmor precisa converter os perfis configurados em um formato binário, isso pode aumentar significativamente o tempo de inicialização. Você pode verificar o tempo de inicialização atual do AppArmor com:
$ systemd-analyze blame | grep apparmor
Para habilitar o cache AppArmor , descomente:
/etc/apparmor/parser.conf
## Turn creating/updating of the cache on by default
write-cache
Caso queira alterar a localização da pasta cache:
/etc/apparmor/parser.conf
cache-loc=/path/to/location
Reinicie ocomputador e faça novamente a verificação.
Décimo passo: Otimizando o agendador do kernel pela udev
Podemos configurar um tipo de agendador para cada tipo de dispositivo.
Cada distro tem um meio de configurar, openSuse já vem com está configuração por padrão.
Você terá que ver como habilitar o bfq para sua distro e se as opções mq-deadline e none existem
Para ver o agendador do momento:
cat /sys/block/sda/queue/scheduler
cat /sys/block/sdb/queue/scheduler
cat /sys/block/sdc/queue/scheduler
Isso é feito criando uma regra no udev: Aqui vamos habilitar o bfq para HDD, SSD mq-deadline e none para NVMe
/etc/udev/rules.d/60-scheduler.rules
Com o seguinte conteúdo:
# definindo agendador para NVMe
ACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"
# definindo agendador para SSD e eMMC
ACTION=="add|change", KERNEL=="sd[a-z]|mmcblk[0-9]*", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"
# definindo agendador para discos rotativos
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="bfq"
Reinicie e veja novamente o agendador usado.
Décimo primeiro passo: Otimizando o journal do systemd
Vimos no passo 7 que podemos limitar o tamanho.
Aqui vamos adicionar outras configurações, descomentado a opções em:
/etc/systemd/journald.conf
SystemMaxFiles=5 # manter no máximo 5 arquivos
MaxFileSec=1month # deletar logs velhos depois de 1 mês
Caso nào tenha, instale o logrotate, e descomente ou adicone as seguintes configurações em:
logrotate é projetado para facilitar a administração de sistemas que geram um grande número de arquivos de log. Ele permite rotação automática, compactação, remoção e envio de arquivos de log. Cada arquivo de log pode ser tratado diariamente, semanalmente, mensalmente ou quando fica muito grande.
/etc/logrotate.conf
maxsize 100M # tamanho máx do arquivo
size 100M # tamanho do arquivo
delaycompress # não comprime na primeira rotação .1
e habilite o timer no boot
sudo systemctl enable logrotate.timer
sudo systemctl start logrotate.timer
Décimo segundo passo: Desabilitando serviços do boot que já são inicializados por outro serviço
Alguns serviços já serão inicializados por outros e você pode ganhar algum tempo no boot desativando (não mascarar) pelo systemctl.
Já vi algumas distros colocando eles no boot. exemplos:
dbus.service
accounts-daemon.service
colord.service
udisk.service
Tem outros, terá que ver se inicializa.
Pode ser visto pelo:
systemd-analyze blame
Décimo terceiro passo: Desativando LVM se não utiliza
Caso não utilize o LVM, não tem porque deixar este serviço carregando no boot.
Comop obter os serviços:
systemctl list-unit-files | gre -i lvm
Exemplos:
lvm2-activation-early.service
lvm2-activation-net.service
lvm2-activation.service
lvm2-lvmetad.service
lvm2-lvmpolld.service
lvm2-monitor.service
lvm2-pvscan@.service
Para tirarmos do boot, precisamos mascarar.
sudo systemctl mask lvm2-activation-early.service lvm2-activation-net.service lvm2-activation.service lvm2-lvmetad.service lvm2-lvmpolld.service lvm2-monitor.service lvm2-pvscan@.service
Se quiser desmacarar use o unmask.
Para pegar os nomes dos arquivos mascarados:
systemctl list-unit-files --state masked
Recomendo ver com systemd-analyze blame se tem mais algum rodando.
Para desativar o lvmetad do gerenciador grub
/etc/lvm/lvm.conf
procure por
use_lvmetad = 1
e modifique para
use_lvmetad = 0
salve e execute a atualização do menu do grub
com
Ubuntu
update-grub
openSUSE e Fedora
grub2-mkgconfig -o /boot/grub2/grub.cfg
Arch
grub-mkgconfig -o /boot/grub/grub.cfg
Ficou com dúvida? Está complicado? Comente aqui!
Para quem quiser otimizar initramfs…
Recomendo ter 2 kernel no mínimo e só fazer o teste em um
vamos ver quanto tempo eu consigo economizar com suas dicas.