Improving performance (Español)/Boot process (Español) - ArchWiki

Jump to content
From ArchWiki
< Improving performance (Español)
Esta traducción de Improving performance/Boot process fue revisada el 2021-02-14. Si existen cambios puede actualizarla o avisar al equipo de traducción.

Artículos relacionados

- Mejorar el rendimiento
- Arranque silencioso
- Daemon
- e4rat
- Kexec

Mejorar el rendimiento de arranque de un sistema puede proporcionar que los tiempos de espera de arranque sean reducidos, para aprender más acerca de cómo ciertos archivos y scripts del sistema interactúan entre sí. En este artículo se intentará agregar métodos sobre cómo mejorar el rendimiento de arranque de un sistema Arch Linux.

## Analizando los procesos de inicio

### Usando systemd-analyze

systemd (Español) proporciona una herramienta llamada `systemd-analyze` que se puede utilizar para mostrar los detalles de temporización sobre los procesos de arranque, incluyendo un diagrama que muestra en SVG, las unidades en espera de sus dependencias. También podemos ver qué archivos de unidades están causando el proceso de arranque para reducir la velocidad. A continuación, puede optimizar su sistema en consecuencia.

Para ver la cantidad de tiempo que hay en el espacio del núcleo y el espacio de usuario en el arranque, basta con utilizar:

    $ systemd-analyze

Sugerencia: Si se inicia vía Unified Extensible Firmware Interface (Español) (UEFI) y utiliza un gestor de arranque que implementa systemd Boot Loader Interface (que actualmente Systemd-boot (Español) y GRUB (Español) do), systemd-analyze puede mostrar cuán rápido inició el firmware EFI y el porpio gestor de arranque.

Para listar los archivos en las unidades iniciadas, ordenadas por el tiempo que les tomó iniciar a cada uno:

    $ systemd-analyze blame

En algunos puntos del proceso de arranque, las cosas no pueden continuar hasta que una determinada unidad tiene éxito. Para ver qué unidades se encuentran en éstos puntos críticos en la cadena de inicio, usamos:

    $ systemd-analyze critical-chain

También podemos crear un archivo SVG que describe el proceso de arranque de forma gráfica simila a Bootchart:

    $ systemd-analyze plot > plot.svg

Véase systemd-analyze(1) para más detalles.

### Usando bootchart2

También es posible usar una versión de bootchart para visualizar la secuencia de arranque. Puesto que no es capaz de poner un segundo inicio en la línea de comandos del kernel que no será capaz de utilizar cualquiera de las configuraciones estándar de Bootchart. Sin embargo el paquete bootchart2AUR desde AUR viene con servicio systemd deshabilitado. Luego de haber instalado bootchart2 hacemos:

    # systemctl enable bootchart2

Puede visualizar los resultados por apertura `/var/log/bootchart.png`, o si desea más detalles de la ejecución:

    $ pybootchartgui -i

Lea la bootchart2 documentacion para más detalles sobre el uso de ésta versión de bootchart.

## Compilando un custom kernel

Compilar un kernel personalizado puede reducir el tiempo de arranque y el uso de memoria. A pesar de la normalización de la arquitectura de 64 bits y la naturaleza modular del núcleo de Linux, estos beneficios pueden no ser tan grande como se esperaba. Read more about compiling a kernel

## Initramfs

Parecido a #Compilando un custom kernel, el initramfs puede ser más ligero. Una forma sencilla es incluir el mkinitcpio (Español) `autodetect` hook. Si querés ir más allá de éso puedes ver Minimal initramfs.

## Cominezo rápido de los serivicios

Una característica central de systemd es D-Bus (Español) y la activación de socket. Esto hace que los servicios sean arrancados cuando se accede a la primera y en general ésto es positivo. Sin embargo, si se sabe que un servicio (como ser upower) siempre se pondrá en marcha durante el arranque, el tiempo total de arranque podría reducirse si la comienza tan pronto como sea posible. Esto se puede lograr (si el archivo de servicio está configurado para ello, que en la mayoría de los casos es) de la siguiente manera:

    # systemctl enable upower

Esto hará que systemd inicie UPower tan pronto como sea posible sin causar ningún percance con los sockets o la activación de D-Bus.

## Escalonar spin-up

Algunos equipos implementan staggered spin-up, que hace que el sistema operativo a la sonda interfaces de ATA en serie, que se puede girar hasta las unidades de una en una y reducir el uso de energía de pico. Esto ralentiza la velocidad de arranque, y en la mayoría de los consumidores de hardware no proporciona ningún beneficio en absoluto ya que las unidades serán ya volver a acelerarse inmediatamente cuando la alimentación está activada. Para comprobar si se está utilizando SSS:

    # dmesg | grep SSS

Si no se utiliza durante el arranque, no habrá salida.

Para desactivarlo, añada `libahci.ignore_sss=1` como parámetro del kernel.

## Montaje de sistemas de archivos

Gracias a mkinitcpio (Español)'s `fsck` hook, se puede evitar que se monte de difícil manera cambiando `ro` a `rw` en la línea del kernel y sacarlo de `/etc/fstab`. Las opciones que se pueden setear con `rootflags=mount options...` en nuestro kernel. Recuerda que debes eliminar la entrada de tu archivo `/etc/fstab` de lo contrario `systemd-remount-fs.service` seguirá trabajando. Alternativamente se podría de enmascarar ésa unidad.

Si btrfs está en uso para el sistema de ficheros raíz, no hay necesidad de un fsck en cada arranque al igual que otros sistemas de ficheros. Si este es el caso, mkinitcpio (Español)'s `fsck` hook puede ser eliminado. También es posible que desee enmascarar el `systemd-fsck-root.service`, o decirle que no realice el fsck en nuestro sistema usando la línea `fsck.mode=skip`. Sin mkinitcpio (Español)'s `fsck` hook, systemd seguirá usando fsckk sin ningún inconveniente con `systemd-fsck@.service`

También puede eliminar la API desde el sistema desde `/etc/fstab`, como systemd los monta (ver `pacman -Ql systemd | grep '\.mount$'` para un listado). No es raro que los usuarios que tienen un /tmp viniendo de sysvinit, pero en el comando anterior puedes ver que systemd se encargó de éso. Ergo, puede ser removido de manera segura.

Otros sistemas de archivos como `/home` se pueden montar con unidadesd e montaje personalizados. Agregando `noauto,x-systemd.automount` para montar opciones amortiguar todos los accesos a la partición y se fsck y montarlo en el primer acceso, lo que reduce el número de sistemas de archivos que debe fsck / montaje durante el proceso de arranque.

Nota:

- Ésto hará que su `/home` use el sistema de archivos con `autofs`, el cual se ignora con mlocate por defecto. The speedup of automounting `/home` may not be more than a second or two, depending on your system, so this trick may not be worth it.
- Si el sistema está instalado dentro de un Btrfs (Especialmente: el directorio root `/` éste sería un volumen secundario) y `/home` se encuentra separado del sistema, aunque también es posible que desee evitar la creación de `/home` subvolume. Protegemos el `home.conf` tmpfile: `ln -s /dev/null /etc/tmpfiles.d/home.conf`.

## Menos salida durante el arranque

Para algunos sistemas, particularmente aquellos con SSD, el rendimiento lento del TTY es en realidad un cuello de botella, por lo que menos salida significa un arranque más rápido. Véase el artículo Arranque silencioso para algunas sugerencias.

## Suspender a RAM

La mejor manera de reducir el tiempo de arranque es que no inicie totalmente. Considere a su vez suspender su sistema a RAM.

Category:

- Boot process (Español)