Parte del trabajo del administrador del sistema es analizar el rendimiento de los sistemas y encontrar y resolver problemas que provocan un rendimiento deficiente y largos tiempos de inicio. Los administradores de sistemas también deben verificar otros aspectos de la configuración y el uso de systemd.
El sistema systemd init proporciona el systemd-analyze herramienta que puede ayudar a descubrir problemas de rendimiento y otra información importante del sistema. En un artículo anterior, Análisis del calendario y los intervalos de tiempo de systemd , usé systemd-analyze para analizar las marcas de tiempo y los intervalos de tiempo en los temporizadores de systemd, pero esta herramienta tiene muchos otros usos, algunos de los cuales exploraré en este artículo.
Resumen de inicio
La secuencia de inicio de Linux es un buen lugar para comenzar a explorar porque muchos systemd-analyze Las funciones de la herramienta están dirigidas al inicio. Pero primero, es importante entender la diferencia entre boot y startup. La secuencia de inicio comienza con la autoprueba de encendido (POST) del BIOS y finaliza cuando el kernel termina de cargarse y toma el control del sistema host, que es el comienzo del inicio y el punto en el que comienza el diario systemd.
En el segundo artículo de esta serie, Comprender systemd al inicio en Linux , analizo el inicio con un poco más de detalle con respecto a lo que sucede y en qué secuencia. En este artículo, quiero examinar la secuencia de inicio para ver la cantidad de tiempo que lleva pasar por el inicio y qué tareas toman más tiempo.
Los resultados que mostraré a continuación son de mi estación de trabajo principal, que es mucho más interesante que los resultados de una máquina virtual. Esta estación de trabajo consta de una placa base ASUS TUF X299 Mark 2, una CPU Intel i9-7960X con 16 núcleos y 32 CPU (hilos) y 64 GB de RAM. Algunos de los comandos a continuación pueden ser ejecutados por un usuario que no sea root, pero usaré root en este artículo para evitar tener que cambiar entre usuarios.
Hay varias opciones para examinar la secuencia de inicio. La forma más simple de systemd-analyze El comando muestra una descripción general de la cantidad de tiempo dedicado a cada una de las secciones principales del inicio, el inicio del kernel, la carga y la ejecución de initrd (es decir, ramdisk inicial, una imagen de sistema temporal que se utiliza para inicializar algún hardware y montar el / sistema de archivos [raíz]) y el espacio de usuario (donde se cargan todos los programas y demonios necesarios para llevar el host a un estado utilizable). Si no se pasa ningún subcomando al comando, systemd-analyze time está implícito:
[root@david ~]$ systemd-analyze
Startup finished in 53.921s (firmware) + 2.643s (loader) + 2.236s (kernel) + 4.348s (initrd) + 10.082s (userspace) = 1min 13.233s
graphical.target reached after 10.071s in userspace
[root@david ~]#
El dato más destacable de esta salida es el tiempo de permanencia en el firmware (BIOS):casi 54 segundos. Esta es una cantidad de tiempo extraordinaria, y ninguno de mis otros sistemas físicos tarda tanto en pasar por el BIOS.
Mi computadora portátil System76 Oryx Pro pasa solo 8,506 segundos en el BIOS, y todos mis sistemas caseros tardan un poco menos de 10 segundos. Después de algunas búsquedas en línea, descubrí que esta placa base es conocida por su tiempo de arranque del BIOS excesivamente largo. Mi placa base nunca "simplemente arranca". Siempre se cuelga, y necesito hacer un ciclo de apagado/encendido, y luego el BIOS comienza con un error, y necesito presionar F1 para ingresar a la configuración del BIOS, desde donde puedo seleccionar la unidad de arranque y finalizar el arranque. De ahí viene el tiempo extra.
No todos los hosts muestran datos de firmware. Mis experimentos no científicos me llevan a creer que estos datos se muestran solo para los procesadores Intel de generación 9 o superior. Pero eso podría ser incorrecto.
Esta descripción general del proceso de arranque es interesante y proporciona buena (aunque limitada) información, pero hay mucha más información disponible sobre el arranque, como describiré a continuación.
Asignación de culpas
Puede usar systemd-analyze blame para descubrir qué unidades systemd tardan más en inicializarse. Los resultados se muestran ordenados por la cantidad de tiempo que tardan en inicializarse, de mayor a menor:
[root@david ~]$ systemd-analyze blame
5.417s NetworkManager-wait-online.service
3.423s dracut-initqueue.service
2.715s systemd-udev-settle.service
2.519s fstrim.service
1.275s udisks2.service
1.271s smartd.service
996ms upower.service
637ms lvm2-monitor.service
533ms lvm2-pvscan@8:17.service
520ms dmraid-activation.service
460ms vboxdrv.service
396ms initrd-switch-root.service
<SNIP – removed lots of entries with increasingly small times>
Debido a que muchos de estos servicios comienzan en paralelo, los números pueden sumar mucho más que el total proporcionado por systemd-analyze time para todo después de la BIOS. Todos estos son números pequeños, por lo que no puedo encontrar ningún ahorro significativo aquí.
Los datos de este comando pueden proporcionar indicaciones sobre qué servicios podría considerar para mejorar los tiempos de arranque. Los servicios que no se utilizan se pueden desactivar. No parece haber ningún servicio que esté tardando demasiado durante esta secuencia de inicio. Es posible que vea resultados diferentes para cada arranque y puesta en marcha.
Cadenas críticas
Al igual que la ruta crítica en la gestión de proyectos, una cadena crítica muestra la cadena de eventos de tiempo crítico que tienen lugar durante el inicio. Estas son las unidades de systemd que desea ver si el inicio es lento, ya que son las que causarían retrasos. Esta herramienta no muestra todas las unidades que comienzan, solo aquellas en esta cadena crítica de eventos:
[root@david ~]# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @10.071s
└─lxdm.service @10.071s
└─plymouth-quit.service @10.047s +22ms
└─systemd-user-sessions.service @10.031s +7ms
└─remote-fs.target @10.026s
└─remote-fs-pre.target @10.025s
└─nfs-client.target @4.636s
└─gssproxy.service @4.607s +28ms
└─network.target @4.604s
└─NetworkManager.service @4.383s +219ms
└─dbus-broker.service @4.434s +136ms
└─dbus.socket @4.369s
└─sysinit.target @4.354s
└─systemd-update-utmp.service @4.345s +9ms
└─auditd.service @4.301s +42ms
└─systemd-tmpfiles-setup.service @4.254s +42ms
└─import-state.service @4.233s +19ms
└─local-fs.target @4.229s
└─Virtual.mount @4.019s +209ms
└─systemd-fsck@dev-mapper-vg_david2\x2dVirtual.service @3.742s +274ms
└─local-fs-pre.target @3.726s
└─lvm2-monitor.service @356ms +637ms
└─dm-event.socket @319ms
└─-.mount
└─system.slice
└─-.slice
[root@david ~]#
Los números precedidos por @ muestra el número absoluto de segundos desde que comenzó el arranque cuando la unidad se vuelve activa. Los números precedidos por + muestra la cantidad de tiempo que tarda la unidad en iniciarse.
Estado del sistema
A veces es necesario determinar el estado actual del sistema. El systemd-analyze dump comando vuelca un masivo cantidad de datos sobre el estado actual del sistema. Comienza con una lista de las marcas de tiempo de arranque principales, una lista de cada unidad systemd y una descripción completa del estado de cada una:
[root@david ~]# systemd-analyze dump
Timestamp firmware: 1min 7.983523s
Timestamp loader: 3.872325s
Timestamp kernel: Wed 2020-08-26 12:33:35 EDT
Timestamp initrd: Wed 2020-08-26 12:33:38 EDT
Timestamp userspace: Wed 2020-08-26 12:33:42 EDT
Timestamp finish: Wed 2020-08-26 16:33:56 EDT
Timestamp security-start: Wed 2020-08-26 12:33:42 EDT
Timestamp security-finish: Wed 2020-08-26 12:33:42 EDT
Timestamp generators-start: Wed 2020-08-26 16:33:42 EDT
Timestamp generators-finish: Wed 2020-08-26 16:33:43 EDT
Timestamp units-load-start: Wed 2020-08-26 16:33:43 EDT
Timestamp units-load-finish: Wed 2020-08-26 16:33:43 EDT
Timestamp initrd-security-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-security-finish: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-generators-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-generators-finish: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-units-load-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-units-load-finish: Wed 2020-08-26 12:33:38 EDT
-> Unit system.slice:
Description: System Slice
Instance: n/a
Unit Load State: loaded
Unit Active State: active
State Change Timestamp: Wed 2020-08-26 12:33:38 EDT
Inactive Exit Timestamp: Wed 2020-08-26 12:33:38 EDT
Active Enter Timestamp: Wed 2020-08-26 12:33:38 EDT
Active Exit Timestamp: n/a
Inactive Enter Timestamp: n/a
May GC: no
<SNIP – Deleted a bazillion lines of output>
En mi estación de trabajo principal, este comando generó un flujo de 49.680 líneas y alrededor de 1,66 MB. Este comando es muy rápido, por lo que no necesita esperar los resultados.
Más recursos de Linux
- Hoja de trucos de los comandos de Linux
- Hoja de trucos de comandos avanzados de Linux
- Curso en línea gratuito:Descripción general técnica de RHEL
- Hoja de trucos de red de Linux
- Hoja de trucos de SELinux
- Hoja de trucos de los comandos comunes de Linux
- ¿Qué son los contenedores de Linux?
- Nuestros últimos artículos sobre Linux
Me gusta la gran cantidad de detalles proporcionados para los diversos dispositivos conectados, como el almacenamiento. Cada unidad systemd tiene una sección con detalles como modos para varios tiempos de ejecución, caché y directorios de registro, la línea de comando utilizada para iniciar la unidad, el ID del proceso (PID), la marca de tiempo de inicio, así como los límites de memoria y archivo. /P>
La página man para systemd-analyze muestra el systemd-analyze --user dump opción, que está destinada a mostrar información sobre el estado interno del administrador de usuarios. Esto me falla, y las búsquedas en Internet indican que puede haber un problema con él. En systemd, --user Las instancias se utilizan para gestionar y controlar los recursos de la jerarquía de procesos pertenecientes a cada usuario. Los procesos de cada usuario forman parte de un grupo de control, que trataré en un artículo futuro.
Gráficos analíticos
La mayoría de los jefes de pelo puntiagudo (PHB) y muchos buenos gerentes encuentran que los gráficos bonitos son más fáciles de leer y comprender que los datos de rendimiento del sistema basados en texto que normalmente prefiero. A veces, sin embargo, incluso me gusta un buen gráfico y systemd-analyze proporciona la capacidad de mostrar datos de arranque/inicio en un gráfico de gráficos vectoriales SVG.
El siguiente comando genera un archivo de gráficos vectoriales que muestra los eventos que tienen lugar durante el arranque y el inicio. Solo lleva unos segundos generar este archivo:
[root@david ~]# systemd-analyze plot > /tmp/bootup.svgEste comando crea un SVG, que es un archivo de texto que define una serie de vectores gráficos que las aplicaciones, incluidas Image Viewer, Ristretto, Okular, Eye of Mate, LibreOffice Draw y otras, utilizan para generar un gráfico. Estas aplicaciones procesan archivos SVG para crear una imagen.
Usé LibreOffice Draw para representar un gráfico. El gráfico es enorme y es necesario ampliarlo considerablemente para distinguir cualquier detalle. Aquí hay una pequeña parte de ella:
La secuencia de inicio está a la izquierda del cero (0) en la línea de tiempo del gráfico, y la secuencia de inicio está a la derecha del cero. Esta pequeña porción muestra el kernel, initrd , y los procesos initrd comenzó.
Este gráfico muestra de un vistazo qué comenzó, cuándo, cuánto tiempo se tardó en iniciarse y las principales dependencias. La ruta crítica está resaltada en rojo.
Otro comando que genera resultados gráficos es systemd-analyze plot . Genera descripciones de gráficos de dependencia textuales en formato DOT. El flujo de datos resultante luego se canaliza a través del dot utilidad, que forma parte de una familia de programas que se pueden utilizar para generar archivos gráficos vectoriales a partir de varios tipos de datos. Estos archivos SVG también se pueden procesar con las herramientas mencionadas anteriormente.
Primero, genere el archivo. Esto tomó casi nueve minutos en mi estación de trabajo principal:
[root@david ~]# time systemd-analyze dot | dot -Tsvg > /tmp/test.svg
Color legend: black = Requires
dark blue = Requisite
dark grey = Wants
red = Conflicts
green = After
real 8m37.544s
user 8m35.375s
sys 0m0.070s
[root@david ~]#
No reproduciré la salida aquí porque el gráfico resultante es bastante espagueti. Pero deberías probarlo y ver el resultado para ver a qué me refiero.
Condicionales
Una de las capacidades más interesantes, aunque algo genéricas, que descubrí mientras leía systemd-analyze(1) la página man es la condition subcomando (Sí, leo las páginas de manual, ¡y es increíble lo que he aprendido de esta manera!) Esta condition El subcomando se puede usar para probar las condiciones y las afirmaciones que se pueden usar en los archivos de unidad systemd.
También se puede usar en secuencias de comandos para evaluar una o más condiciones; devuelve un cero (0) si se cumplen todas o un uno (1) si no se cumple alguna condición. En cualquier caso, también arroja texto sobre sus hallazgos.
El siguiente ejemplo, de la página del manual, es un poco complejo. Comprueba una versión del kernel entre 4.0 y 5.1, que el host se ejecuta con alimentación de CA, que la arquitectura del sistema es todo menos ARM y que el directorio /etc/os-release existe Agregué el echo $? instrucción para imprimir el código de retorno.
[root@david ~]# systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
'ConditionKernelVersion = >=5.1' \
'ConditionACPower=|false' \
'ConditionArchitecture=|!arm' \
'AssertPathExists=/etc/os-release' ; \
echo $?
test.service: AssertPathExists=/etc/os-release succeeded.
Asserts succeeded.
test.service: ConditionArchitecture=|!arm succeeded.
test.service: ConditionACPower=|false failed.
test.service: ConditionKernelVersion=>=5.1 succeeded.
test.service: ConditionKernelVersion=!<4.0 succeeded.
Conditions succeeded.
0
[root@david ~]#
La lista de condiciones y afirmaciones comienza alrededor de la línea 600 en systemd.unit(5) página man.
Listado de archivos de configuración
El systemd-analyze La herramienta proporciona una forma de enviar el contenido de varios archivos de configuración a STDOUT , como se muestra aquí. El directorio base es /etc/ :
[root@david ~]# systemd-analyze cat-config systemd/system/display-manager.service
# /etc/systemd/system/display-manager.service
[Unit]
Description=LXDM (Lightweight X11 Display Manager)
#Documentation=man:lxdm(8)
[email protected]
After=systemd-user-sessions.service [email protected] plymouth-quit.service livesys-late.service
#Conflicts=plymouth-quit.service
[Service]
ExecStart=/usr/sbin/lxdm
Restart=always
IgnoreSIGPIPE=no
#BusName=org.freedesktop.lxdm
[Install]
Alias=display-manager.service
[root@david ~]#
Esto es mucho escribir para hacer nada más que un cat estándar el comando lo hace. El siguiente comando me parece un poco útil. Puede buscar archivos con el patrón especificado dentro de las ubicaciones estándar de systemd:
[root@david ~]# systemctl cat backup*
# /etc/systemd/system/backup.timer
# This timer unit runs the local backup program
# (C) David Both
# Licensed under GPL V2
#
[Unit]
Description=Perform system backups
Requires=backup.service
[Timer]
Unit=backup.service
OnCalendar=*-*-* 00:15:30
[Install]
WantedBy=timers.target
# /etc/systemd/system/backup.service
# This service unit runs the rsbu backup program
# By David Both
# Licensed under GPL V2
#
[Unit]
Description=Backup services using rsbu
Wants=backup.timer
[Service]
Type=oneshot
Environment="HOME=/root"
ExecStart=/usr/local/bin/rsbu -bvd1
ExecStart=/usr/local/bin/rsbu -buvd2
[Install]
WantedBy=multi-user.target
[root@david ~]#
Ambos comandos preceden el contenido de cada archivo con una línea de comentario que contiene la ruta y el nombre completos del archivo.
Verificación de archivo de unidad
Después de crear un nuevo archivo de unidad, puede ser útil verificar que su sintaxis sea correcta. Esto es lo que verify el subcomando lo hace. Puede enumerar las directivas que están mal escritas y señalar las unidades de servicio que faltan:
[root@david ~]# systemd-analyze verify /etc/systemd/system/backup.serviceSiguiendo la filosofía de Unix/Linux de que "el silencio es oro", la falta de mensajes de salida significa que no hay errores en el archivo escaneado.
Seguridad
La security El subcomando comprueba el nivel de seguridad de los servicios especificados. Solo funciona en unidades de servicio y no en otro tipo de archivos de unidades:
[root@david ~]# systemd-analyze security display-manager
NAME DESCRIPTION >
✗ PrivateNetwork= Service has access to the host's network >
✗ User=/DynamicUser= Service runs as root user >
✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities >
✗ CapabilityBoundingSet=~CAP_SYS_ADMIN Service has administrator privileges >
✗ CapabilityBoundingSet=~CAP_SYS_PTRACE Service has ptrace() debugging abilities >
✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets >
✗ RestrictNamespaces=~CLONE_NEWUSER Service may create user namespaces >
✗ RestrictAddressFamilies=~… Service may allocate exotic sockets >
✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP) Service may change file ownership/access mode/capabilities unres>
✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may override UNIX file/IPC permission checks >
✗ CapabilityBoundingSet=~CAP_NET_ADMIN Service has network configuration privileges >
✗ CapabilityBoundingSet=~CAP_SYS_MODULE Service may load kernel modules
<SNIP>
✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG Service may issue vhangup() >
✗ CapabilityBoundingSet=~CAP_WAKE_ALARM Service may program timers that wake up the system >
✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets >
→ Overall exposure level for backup.service: 9.6 UNSAFE ?
lines 34-81/81 (END)
Sí, el emoji es parte de la salida. Pero, por supuesto, muchos servicios necesitan un acceso bastante completo a todo para poder hacer su trabajo. Ejecuté este programa en varios servicios, incluido mi propio servicio de copia de seguridad; los resultados pueden diferir, pero el resultado final parece ser prácticamente el mismo.
Esta herramienta sería muy útil para verificar y reparar las unidades de servicio del espacio de usuario en entornos críticos para la seguridad. No creo que tenga mucho que ofrecer para la mayoría de nosotros.
Pensamientos finales
Esta poderosa herramienta ofrece algunas opciones interesantes y sorprendentemente útiles. Mucho de lo que explora este artículo es sobre el uso de systemd-analyze para proporcionar información sobre el rendimiento de inicio de Linux mediante systemd. También puede analizar otros aspectos de systemd.
Algunas de estas herramientas son de uso limitado, y un par deben olvidarse por completo. Pero la mayoría se puede utilizar con buenos resultados al resolver problemas con el inicio y otras funciones de systemd.
Recursos
Hay una gran cantidad de información sobre systemd disponible en Internet, pero mucha es concisa, obtusa o incluso engañosa. Además de los recursos mencionados en este artículo, las siguientes páginas web ofrecen información más detallada y confiable sobre el inicio de systemd. Esta lista ha crecido desde que comencé esta serie de artículos para reflejar la investigación que he realizado.
- La página del manual systemd.unit(5) contiene una buena lista de secciones de archivos de unidades y sus opciones de configuración junto con descripciones concisas de cada una.
- El Proyecto Fedora tiene una buena guía práctica para systemd. Tiene prácticamente todo lo que necesita saber para configurar, administrar y mantener una computadora Fedora usando systemd.
- El Proyecto Fedora también tiene una buena hoja de trucos que hace una referencia cruzada de los comandos antiguos de SystemV con los de systemd comparables.
- La documentación de Red Hat contiene una buena descripción de la estructura de archivos de la unidad, así como otra información importante.
- Para obtener información técnica detallada sobre systemd y las razones para crearlo, consulte la descripción de systemd de Freedesktop.org.
- "More systemd fun" de Linux.com ofrece información y consejos más avanzados sobre systemd.
También hay una serie de artículos profundamente técnicos para administradores de sistemas Linux escritos por Lennart Poettering, el diseñador y desarrollador principal de systemd. Estos artículos fueron escritos entre abril de 2010 y septiembre de 2011, pero son tan relevantes ahora como lo fueron entonces. Gran parte de todo lo bueno que se ha escrito sobre systemd y su ecosistema se basa en estos documentos.
- Repensar el PID 1
- systemd para administradores, Parte I
- systemd para administradores, Parte II
- systemd para administradores, Parte III
- systemd para administradores, Parte IV
- systemd para administradores, Parte V
- systemd para administradores, Parte VI
- systemd para administradores, Parte VII
- systemd para administradores, Parte VIII
- systemd para administradores, Parte IX
- systemd para administradores, Parte X
- systemd para administradores, Parte XI