Saltar al contenido

Gnu/Linux Vagos usa cookies. Lea nuestra Política de privacidad para más información.    Acepto el uso de cookies

Foto

Optimizando el tiempo y servicios de arranque en SytemD

Systemd sysctl arranque servicios administración

  • Por favor, loguéate para poder responder
5 respuestas a este tema

#1 DESCONECTADO   Shiba87

Shiba87

    Administrador

  • Registrado: 19/07/2012
  • Mensajes: 6092
  • Galletas: 28078

Género:








Lugar:/home/shiba

Escrito 24 October 2013 - 14:11

mrjb.jpg

 
Entre las ventajas de Systemd, implantado ya en algunas distribuciones y a punto de serlo en muchas otras, es la posibilidad de analizar y optimizar el arranque mediante las propias herramientas del propio systemd.
 
Analizando el arranque
 
Las órdenes que utilizaremos para realizar los análisis son todas las relacionadas con:

systemd-analyze time

Como ven, es bastante obvia su función y es fácil de recordar. De hecho, si no especificáramos nada, por defecto se ejecutaría la orden con la misma opción un "time"

systemd-analyze

Si la ejecutamos tal cual, sin ninguna otra opción nos devolverá una estimación (muy precisa) del tiempo que emplearía el sistema en arrancar con la configuración actual, diferenciando de manera clara y por separado el tiempo correspondiente al kernel en sí y al espacio de usuario:

root@Shiba87:/home/shiba# systemd-analyze
Startup finished in 3.315s (kernel) + 13.375s (userspace) = 16.691s

 
Ahora que sabemos cuál es nuestro tiempo de arranque, podemos empezar a trabajar para optimizarlo y/o reducirlo haciendo uso del resto de opciones de systemd-analyze y, por supuesto, systemctl.
 
Empezamos por pedirle una lista detallada de todos los servicios que se inician al arrancar el sistema y su impacto en el tiempo total de arranque:

systemd-analyze blame

Ahora la respuesta será mucho más extensa y concisa

root@Shiba87:/home/shiba# systemd-analyze blame
         11.440s systemd-fsck-root.service
          1.108s keyboard-setup.service
          1.069s sys-kernel-debug.mount
          1.068s dev-mqueue.mount
          1.067s dev-hugepages.mount
           830ms systemd-udevd.service
           762ms systemd-udev-trigger.service
           684ms systemd-tmpfiles-setup-dev.service
           408ms systemd-modules-load.service
           404ms systemd-sysctl.service
           355ms vboxdrv.service
           247ms home.mount
           124ms cron.service
           111ms systemd-readahead-replay.service
            95ms systemd-update-utmp-runlevel.service
            85ms console-setup.service
            77ms systemd-tmpfiles-clean.service
            72ms systemd-remount-fs.service
            52ms networking.service
[...]

O podemos centrarnos específicamente en los más lentos:

systemd-analyze blame | head

 
Nos quedaría sólo con los tiempos de cabeza, es decir, los más lentos
 

root@Shiba87:/home/shiba# systemd-analyze blame | head
         11.440s systemd-fsck-root.service
          1.108s keyboard-setup.service
          1.069s sys-kernel-debug.mount
          1.068s dev-mqueue.mount
          1.067s dev-hugepages.mount
           830ms systemd-udevd.service
           762ms systemd-udev-trigger.service
           684ms systemd-tmpfiles-setup-dev.service
           408ms systemd-modules-load.service
           404ms systemd-sysctl.service

También podemos centrarnos en los puntos "críticos"

systemd-analyze critical-chain

Y que nos devuelva una estructura clara y en orden de todos ellos.

root@Shiba87:/home/shiba# systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @13.279s
└─multi-user.target @13.278s
  └─vboxweb-service.service @13.275s +2ms
    └─vboxdrv.service @12.918s +355ms
      └─basic.target @12.916s
        └─sockets.target @12.916s
          └─dbus.socket @12.915s
            └─sysinit.target @12.914s
              └─console-setup.service @12.828s +85ms
                └─kbd.service @12.818s +8ms
                  └─remote-fs.target @12.817s
                    └─local-fs.target @12.816s
                      └─home.mount @12.568s +247ms
                        └─local-fs-pre.target @12.270s
                          └─systemd-remount-fs.service @12.197s +72ms
                            └─keyboard-setup.service @2.165s +1.108s
                              └─systemd-udevd.service @1.334s +830ms
                                └─systemd-tmpfiles-setup-dev.service @648ms +684ms
                                  └─systemd-journald.socket @645ms
                                    └─-.mount @630ms

 
Otras opciones interesantes son plot y dot, que nos permiten realizar gráficos con toda la información anterior para que nos sea más sencillo procesarla de una manera más "visual".
El gráfico será devuelto en forma de imagen svg, así que a menos que queramos ver una enorme lista de puntos uno tras otros, tendremos que indicar también el archivo de destino donde irán a parar los datos:

systemd-analyze plot >> archivo-grafico.svg

El resultado es una imagen gigantesca con todos los servicios, sus tiempos y una serie de indicaciones que nos serán muy útiles para analizar los datos de systemd Analyze
 
q1f7.png
 
Para el diagrama de puntos tendremos que ser incluso más específicos a la hora de crear el archivo svg y necesitaremos hacer uso de las herramientas del paquete  graphviz

systemd-analyze dot | dot -Tsvg > Archivo-diagrama.svg

El resultado es... bueno, difícil de describir con palabras :happy:
 
Como ven tenemos un diagrama muy complejo de todos los servicios y las dependencias entre ellos, el orden que ocupan... en fin, una maraña de información muy muy completa
 
6iar.png
 
Para quienes quieran profundizar más en las herramientas de análisis, toda la información se encuentra en las Wikis oficiales y en las de muchas distribuciones
http://www.freedeskt...md-analyze.html
 
 
 
Optimizando el Arranque

Una vez que tengamos una idea clara de cómo es la secuencia de arranque de nuestro sistema, podemos ponernos manos a la obra para optimizarla.
 
Habilitando/deshabilitando servicios
Aunque no era mi intención en cuanto a métodos de optimización empezaré por lo más obvio y que seguramente todos tenemos ahora mismo rondando por nuestra cabeza, que viene siendo deshabilitar directamente algunos servicios que no necesitamos.
Esto es bastante sencillo, simplemente elegiremos aquellos demonios de la lista que nos ha devuelto el systemd-analyze que no queremos que sean cargados y, mediante el uso de systemctl, nos desharemos de ellos

systemctl disable demonio.service 

O, si por el contrario quisiéramos realizar el proceso inverso, es decir, habilitar un servicio

systemctl enable demonio.service 

Así con cada uno de los demonios con los que trabajemos.
 
 
Readahead
 
Pero no es eso de lo que venía a hablar aquí, sino de otras formas de optimizar el arranque, como puede ser readahead.
 
Algo tan sencillo como

systemctl enable systemd-readahead-collect systemd-readahead-replay

nos permitirá optimizar de manera sensible el arranque de nuestro sistema.
 
 
Preload
 
Incluido en los repositorios de algunas distribuciones, nos permitirá realizar una análisis de las funciones y demonios más utilizados en el sistema para cargarlos antes de necesitarlos, lo que redundará en una mejor respuesta del sistema y esto a su vez, en un arranque más agilizado.
 
Para los que no podemos instalar preload desde repositorios, el proceso para activarlo sería el siguiente:

wget http://optimate.dl.sourceforge.net/project/preload/preload/0.6.4/preload-0.6.4.tar.gz
tar -xfvz preload*.tar.gz
cd preload*
./configure
make
make install

Tras la instalación, habilitamos el servicio y lo ponemos en marcha:

systemctl start preload.service
systemctl enable preload.service

 
 
Prelink
 
Sólo nos queda hablar de prelink, igualmente en respositorios de muchas distribuciones y que nos permitirá agilizar no sólo el arranque sino la ejecución de muchas aplicaciones al realizar enlaces entre binarios y librerías o más bien "pre-enlaces", acelerando la ejecución de las mismas.
 
una vez instalado el paquete, la primera vez ejecutaremos directamente

prelink -afmR

Y le dejaremos obrar su magia.
 
En ocasiones posteriores, como las librerías y aplicaciones cambian, se actualizan, se instalan nuevas, se desinstalan antiguas, etc, configuraremos Prelink para que busque cambios y se ejecute de forma periódica.
 
Editamos el archivo /etc/default/prelink cambiando la línea:

PRELINKING=no

por

PRELINKING=yes

 
más abajo tendremos las opciones de chequeo:

PRELINK_FULL_TIME_INTERVAL=

Y de ejecución forzada en caso de no haberse encontrado ningún cambio en las librerías del sistema

PRELINK_NONRPM_CHECK_INTERVAL=

El número que acompaña a dichas opciones representa los días que pasarán entre un chequeo/ejecución y la siguiente
 

 

 

UPower

 

UPower es un demonio, un API, y un conjunto de herramientas de línea de comandos. Cada fuente de poder del sistema es representada como un dispositivo, sin importar que sea o no un dispositivo físico.

La administración realizada por este servicio consigue que durante el arranque las unidades se inicien y sincronicen con DBus de manera más eficiente, redundando en un arranque más rápido.

 
Aunque se puede configurar de multitud de maneras diferentes según lo que necesitemos, en principio la configuración básica es más que suficiente, basta con instalar el paquete upower y habilitar el servicio

systemctl enable upower

 

 

Montar/chequear particiones "secundarias" tras el arranque

 

Una de las cosas que más puede demorar el arranque son las tareas llevadas a cabo por fsck y mount.

Con el objetivo de aligerar estos procesos podemos indicar como opción en nuestro fstab que aquellas particiones que no están estrictamente necesarias para el arranque sean montadas/montada después de éste, al acceder por primera vez a ellas. Particiones como /home o algunas que hemos creado para temas concretos, discos secundarios, etc. Especialmente aquellas que no es seguro que vayamos a utilizar y, por tanto, no vale la pena estar cargándolas y revisándolas continuamente cada vez que arrancamos el equipo.

 

En el caso concreto de /home, permitirá que otros servicios no dependientes de éste sean cargados durante el arranque antes y durante el montaje/checkeo del propio home

 

Las opciones a las que nos referimos son:

 

noauto, que es la opción habitual para indicar que no se monte dicha partición de manera automática

x-systemd.automount, que indica que no va a ser montada ni chequeada durante el
arranque sino cuando se demande.

 

Ejemplo

/dev/sda2  /home           ext4    discard,noatime,nodiratime,noauto,x-systemd.automount 0       2

 

 
Bootchart
 
Por último, a modo de curiosidad, otro proceso que antes realizamos de manera manual, pero que también podemos realizar de manera automática.
 
Gracias al servicio bootchart lograremos crear un gráfico de nuestra secuencia de arranque. Para eso, a la línea del kernel de nuestro grub habrá que añadir las siguientes opciones

initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart

Y habilitar el servicio bootchart, por su puesto.

systemctl enable bootchart

  • granjero, Jaska, Eduardo y 7 mas les gusta esto

Hvp5ebV.png


#2 DESCONECTADO   UbayGD

UbayGD

    Linuxero

  • Registrado: 26/11/2012
  • Mensajes: 226
  • Galletas: 961

Género:








Lugar:Tenerife

Escrito 24 October 2013 - 17:33

Interesante, interesante. Por fin pude quitar el bluetooth jajaja

 

Ahora, con el tema del prelink, el archivo de configuración en OpenSUSE se encuentra en "/etc/prelink.conf" pero no aparece la entra de PRELINKING ni las otras. ¿Son el mismo archivo o hay algún otro por ahí escondido? Utilizando el buscador no he encontrado ningún otro archivo de configuración



#3 DESCONECTADO   Shiba87

Shiba87

    Administrador

  • Registrado: 19/07/2012
  • Mensajes: 6092
  • Galletas: 28078

Género:








Lugar:/home/shiba

Escrito 24 October 2013 - 20:49

Si es el mismo que acabo de ver es muy curioso, parece un lista de librerías sin más ¿Qué gracia tiene que sea tan estático? :lol:

 

 

Por lo que veo, según la wiki de Arch, toca hacerlo a mano creando un script /etc/cron.daily/prelink.cron

#!/bin/bash
[[ -x /usr/sbin/prelink ]] && /usr/sbin/prelink -amR &>/dev/null

darle permisos y dejar que cron se encargue

chmod 755 /etc/cron.daily/prelink.cron

  • UbayGD le gusta esto

Hvp5ebV.png


#4 DESCONECTADO   UbayGD

UbayGD

    Linuxero

  • Registrado: 26/11/2012
  • Mensajes: 226
  • Galletas: 961

Género:








Lugar:Tenerife

Escrito 24 October 2013 - 20:54

Voy a probar a ver que tal. Muchas gracias señor :sombrero:



#5 DESCONECTADO   josspark

josspark

    Iniciado

  • Registrado: 07/08/2013
  • Mensajes: 73
  • Galletas: 220

Género:

Escrito 18 April 2014 - 15:38

a mi me dice lo siguiente:

Failed to issue method call: Launch helper exited with unknown return code 1


#6 DESCONECTADO   Kaleb

Kaleb

    Recién llegado

  • Registrado: 12/01/2014
  • Mensajes: 34
  • Galletas: 119

Género:


Escrito 14 June 2014 - 18:22

Hola, a mi me tarda la vida en arrancar (aunque en la otra distribucion me va rápido)

systemd-analyze time
Startup finished in 2920ms (kernel) + 92883ms (userspace) = 95804ms

y éste es el listado completo:

systemd-analyze blame
  3342ms keyboard-setup.service
  2376ms build-dkms.service
  1512ms udev.service
  1105ms sys-kernel-security.mount
  1105ms dev-mqueue.mount
  1105ms dev-hugepages.mount
  1105ms sys-kernel-debug.mount
  1104ms run-user.mount
  1104ms run-lock.mount
   605ms udev-trigger.service
   561ms hdparm.service
   537ms home.mount
   523ms systemd-modules-load.service
   522ms bootlogs.service
   479ms kbd.service
   433ms alsa-utils.service
   374ms systemd-tmpfiles-setup.service
   339ms systemd-remount-api-vfs.service
   258ms rpcbind.service
   255ms console-setup.service
   240ms nfs-common.service
   229ms exim4.service
   209ms systemd-readahead-replay.service
   203ms systemd-sysctl.service
   124ms remount-rootfs.service
   107ms console-kit-daemon.service
    94ms polkitd.service
    72ms networking.service
    46ms systemd-readahead-collect.service
    44ms console-kit-log-system-start.service
    40ms atd.service
    37ms cron.service
    34ms loadcpufreq.service
    20ms udisks.service
    18ms ntp.service
    13ms nvidia-kernel.service
    12ms motd.service
    11ms rc.local.service
    10ms cpufrequtils.service
     7ms preload.service
     5ms upower.service
     3ms systemd-logind.service
     3ms lightdm.service
     1ms saned.service
     1ms systemd-user-sessions.service

Este es el kernel, por si el problema esta ahí:

uname -r
3.10-3-amd64

podeis echarme una mano? por que si no me habia planteado volver a sysvinit :confused:


Editado por Kaleb, 14 June 2014 - 18:31 .






También etiquetado con una o más de estas palabras: Systemd, sysctl, arranque, servicios, administración