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 ONLINE   Shiba87

Shiba87

    Administrador

  • Administrador
  • Rango
  • 5820 Mensajes
  • Distribución :

  • Entorno gráfico:

  • Navegador Web:

  • 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
 
 
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

#2 DESCONECTADO   UbayGD

UbayGD

    Linuxero

  • Moderadores
  • Rango
  • 223 Mensajes
  • Distribución :

  • Entorno gráfico:

  • Navegador Web:

  • 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 ONLINE   Shiba87

Shiba87

    Administrador

  • Administrador
  • Rango
  • 5820 Mensajes
  • Distribución :

  • Entorno gráfico:

  • Navegador Web:

  • 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

#4 DESCONECTADO   UbayGD

UbayGD

    Linuxero

  • Moderadores
  • Rango
  • 223 Mensajes
  • Distribución :

  • Entorno gráfico:

  • Navegador Web:

  • 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

  • Miembros
  • Rango
  • 73 Mensajes
  • Distribución :

  • 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

  • Miembros
  • Rango
  • 33 Mensajes
  • Distribución :

  • 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