-
Algún truco para acelerar el arranque en Leap15
Hola.
Me encontré el arranque de Leap15 más lento que nunca, y vi en el blog del amigo Benja https://www.diversidadyunpocodetodo....n-el-arranque/ algún truco que me ha funcionado.
Como le aporto yo mismo, desactivar Wicked me ha funcionado perfectamente y me ha acelerado bastante el arranque.
Ahora, me queda así:
Código:
leap15@linux-pbv8:~> systemd-analyze blame | head
2.219s postfix.service
1.391s firewalld.service
1.349s ca-certificates.service
980ms dev-sda5.device
944ms ModemManager.service
917ms backup-rpmdb.service
828ms apparmor.service
681ms display-manager.service
613ms polkit.service
580ms rsyslog.service
Por lo pronto, el arranque sigue siendo algo lento, pero como se ve, el cortafuegos pone lo suyo (y no pienso desactivarle nada de lo que tiene).
Lo del servicio de Modem es algo que no sé si quitarle o no.
Y de lo demás, me gustaría saber qué opinión tienen.
Saludos.
-
Hola.
Hay muchos "trucos" pero por supuesto, si no viene así por defecto igual es por algo. Puedes dejarlo en unos cuatro segundos. Hay un par de artículos en inglés al respecto y hablamos de ellos en el foro hace un montón.
Cosas a probar:
*no configurar cosas como el teclado y su teclado numérico
*quitar plymouth
*ntp
https://victorhckinthefreeworld.com/...e-en-opensuse/
Salud!!
-
Hay un tema iniciado por Krovikan donde hablamos y hacemos experimentos, igual te interesa leerlo.
Pero la mejor manera de acelerar el arranque de openSUSE es comprando un disco SSD e instalando ahi el directorio raíz /, mano de santo.
-
Post Thanks / Like - 0 Gracias, 1 Me Gusta, 0 No me Gusta
andy98 le ha gustado este mensaje
-
Hola:
Te basas en systemd, para recortar, en los pasos anteriores es mas difícil .
Por ejemplo, el 1º que tienes no te sirve de mucho y lo puedes desactivar desde administrador de servicios de yast.
Si no usas ipv6, no lo actives , idem bluethoo, no configurar nfs desde yast, dejalo en dolphin y monta en administrador de serviciós autofs (montar y conectar a demanda).
Vigila en el arranque el orden de conexión, algunas hacen 3 intentos y pueden tardae 3 minutos o mas, haciendo la conexión mas tarde, es mejor conectar primero y evitar esas esperar largas.
Un resumen de todo lo haces con systemd-analyze plot > /home/user/Imágenes/arranque.svg , eso lo ves después con firefox.idem blame, crical-chain, etc ( puedes quitar de 28 a mas de un minuto).
También las cosas programadas que estén en tiempo fuera de sesión o que no uses pc, o que se hagan en segundo plano, ejemplo cuando veas una peli o navegues (cron, mantenimiento, servicios de rotate, etc) , para ello mira sus configuraciones en yast y en /etc; también limita snapper si lo usas, limita journal, etc, eso ya no corresponde en el arrranque (pero con cpu de variós núcleos e hilos, no te das cuenta) .
Si no usas wifii desactiva las verificaciones,conexiones,wpa, en algunas de mis placas suelen tener las 3 conexiones, sin contar bluethoo.Resumiendo, puedes reducir lo que respeta al espacio de usuario y ha veces en firware
Código:
FRANK-Z87-D:~ # systemd-analyze
Startup finished in 16.471s (firmware) + 8.011s (loader) + 3.638s (kernel) + 2.258s (initrd) + 24.086s (userspace) = 54.466s
Los 8 de firw, a veces se pueden quitar.
Código:
FRANK-Z87-D:~ # systemd-analyze blame
9.108s btrfsmaintenance-refresh.service
8.166s home.mount
6.466s apparmor.service
5.576s wicked.service
2.900s dev-sdb2.device
2.594s systemd-journal-flush.service
2.184s ModemManager.service
2.103s SuSEfirewall2_init.service
1.353s lm_sensors.service
1.137s logrotate.service
1.031s display-manager.service
Como ves algunos no están y el btrfs , creo que lo puedo configurar para otros días o en otros momentos.. ( versión leap 42.3) .
firmware no siempre aparece en systemd, salvo determinadas circunstancias (creo que en /boot o en otro sitio se puede quitar, ejemplo /etc, por ahora no le di importancia y no lo mire, por lo que no lo se) .
Edito: puedes quitar el primero que aparece en tu log, en gestión de servicios de yast, inabilitalo y ponlo en no activo ( te ahorras 2,2 seg) y si usas inxi no actives lo de la temperatura del HD, esté corre en 2º plano, uses o no el comando (ahora no se si lo han cambiado) , también si tienes discos nuevos quita smartd, ya eso lo puedes activar en bios, pero algún programa, que lo usa, no podrá ver ese dato (ejemplo partition manager de kde) .
Saludos cordiales .
Última edición por mikrios; 06-jul-2018 a las 00:52
Razón: corregir
-
Con la boca abierta me quedé al ver los 54seg de @mikrios.
El mio:
Código:
systemd-analyze
Startup finished in 2.070s (kernel) + 1.729s (initrd) + 26.476s (userspace) = 30.276s
Código:
systemd-analyze blame
20.148s minidlna.service
4.892s wicked.service
2.197s bootchart2-done.service
1.592s upower.service
882ms display-manager.service
743ms apparmor.service
521ms vboxdrv.service
392ms dev-sda1.device
355ms postfix.service
355ms mnt-juegos-wine.mount
346ms systemd-journal-flush.service
235ms ModemManager.service
210ms copias.mount
192ms home.mount
139ms udisks2.service
121ms systemd-vconsole-setup.service
119ms polkit.service
97ms systemd-logind.service
86ms systemd-modules-load.service
84ms systemd-fsck@dev-disk-by\x2duuid-747c8c0e\x2dc84b\x2d44e0\x2db2bf\x2daf441b9d8698.service
80ms ntpd.service
79ms user@1000.service
72ms rc-local.service
72ms alsa-restore.service
72ms mcelog.service
72ms nscd.service
67ms systemd-udev-trigger.service
66ms systemd-fsck@dev-disk-by\x2duuid-87887b36\x2db849\x2d4373\x2d96b3\x2db8239df90378.service
65ms wickedd-auto4.service
65ms systemd-udevd.service
64ms wickedd-dhcp6.service
60ms wickedd-dhcp4.service
55ms systemd-user-sessions.service
54ms iscsi.service
53ms vboxes.service
44ms var-lib-named.mount
42ms user@481.service
42ms \x2esnapshots.mount
42ms var-lib-mysql.mount
41ms boot-grub2-x86_64\x2defi.mount
38ms avahi-daemon.service
38ms wickedd.service
34ms var-crash.mount
33ms srv.mount
31ms wickedd-nanny.service
30ms usr-local.mount
27ms var-lib-pgsql.mount
26ms dev-disk-by\x2duuid-d6572c9f\x2d8331\x2d4a6b\x2dbe2e\x2df695f347ca2a.swap
25ms var-spool.mount
24ms var-opt.mount
24ms var-lib-mariadb.mount
24ms var-lib-libvirt-images.mount
23ms opt.mount
23ms boot-grub2-i386\x2dpc.mount
23ms tmp.mount
22ms plymouth-start.service
22ms var-log.mount
22ms var-cache.mount
21ms var-lib-mailman.mount
20ms var-tmp.mount
19ms var-lib-machines.mount
19ms systemd-journald.service
18ms auditd.service
18ms bootchart2.service
16ms plymouth-read-write.service
13ms sys-kernel-debug.mount
13ms systemd-remount-fs.service
12ms dev-hugepages.mount
12ms systemd-tmpfiles-setup.service
11ms dev-mqueue.mount
10ms systemd-tmpfiles-setup-dev.service
10ms dracut-shutdown.service
9ms systemd-fsck-root.service
9ms rtkit-daemon.service
7ms systemd-tmpfiles-clean.service
6ms systemd-udev-root-symlink.service
5ms sys-fs-fuse-connections.mount
5ms systemd-update-utmp.service
4ms systemd-sysctl.service
4ms systemd-random-seed.service
3ms kmod-static-nodes.service
3ms systemd-update-utmp-runlevel.service
Saludos
-
Hola.
Os recuerdo que esto mola probarlo varias veces, para saber el promedio. En un arranque particular, puede, por la razón que sea, suceder o no algo que modifique el resultado (por ejemplo, revisar la partición, problemas con la respuesta del router al configurar la red, etc.).
Los artículos enlazados por victorhck son viejos pero aun aplican más o menos. Lógicamente, la configuración por defecto tiene su razón de ser y modificarla generalmente implicará renunciar a cosas.
Salud!!
-

Iniciado por
karlggest
Hola.
Os recuerdo que esto mola probarlo varias veces, para saber el promedio. En un arranque particular, puede, por la razón que sea, suceder o no algo que modifique el resultado (por ejemplo, revisar la partición, problemas con la respuesta del router al configurar la red, etc.).
Salud!!
...de acuerdo con @karlggest, por ejemplo este no seria buena referencia debido a que hubo una actualización del "kernel". ...por cierto no se si esto lo hace cada vez que se actualiza el "kernel".
Código:
systemd-analyze blame
58.501s purge-kernels.service
20.259s wicked.service
12.511s backup-rpmdb.service
9.150s apparmor.service
8.256s systemd-journal-flush.service
6.834s btrfsmaintenance-refresh.service
6.760s ca-certificates.service
5.568s ModemManager.service
5.290s lvm2-monitor.service
4.317s display-manager.service
4.152s polkit.service
3.587s wickedd-auto4.service
3.540s plymouth-quit-wait.service
3.526s wickedd-dhcp4.service
2.937s initrd-switch-root.service
2.862s wickedd-dhcp6.service
2.697s rsyslog.service
2.663s avahi-daemon.service
2.516s nscd.service
2.235s home.mount
2.059s chronyd.service
1.982s kbdsettings.service
1.813s plymouth-start.service
1.478s postfix.service
1.242s mcelog.service
Salud.
The box said: 'Requires Windows 95 or better' ...SO I INSTALLED LINUX!
Kernel: 5.3.18-lp152.20.7-default x86_64
Distro: openSUSE Leap 15.2 / TW
KDE Plasma 5.18.5
Mobo: ASUSTeK ROG STRIX B350-F GAMING
CPU: AMD Ryzen 7 1700X 8-Core
RAM-16.0 GiB
Video-Radeon RX 460/560D
-
..por cierto no se si esto lo hace cada vez que se actualiza el "kernel".
Tú, por lo pronto, procura no estar trabajando con discos externos si el kernel se está actualizando, elige hacer una cosa u otra, no te vayas a llevar alguna sorpresita como yo 


(Que fue cuando se trabó el inicio y tuve que medio reinstalar para que me reconociera los discos)
-
Hola :
Lo de 54seg. está dentro de lo normal.
Lo mencionado por @gvcastellon, es eventual, lo mismo que una ejecución de dracut, actualización de grub2, y algún mantenimiento programado en cron.
Si se sale de ahí, o si tienes un servicio programado y lo tienes apagado (nfs si lo has programado por yast, si lo tienes solo en dolphin no afecta mucho o nada,pero mejor eso que se quede colgado el pc, o tener que entrar con vim y editar fstab, etc )eso es normal , systemd hace uno o varios reintentos, pasado estos, no bloquea el sistema, si no que continúa ( pueden ser de 1,30 seg, o mas, incluso ejecuta la espera y mas tarde ejecuta el servicio, ¿falta de sincronización? ) .
Incluyo en esto el tiempo negativo del firmware , anterior a el loader y también se me olvidaba en el espacio de usuario el mantenimiento de btrfs .
Es algo por lo que hay que pasar, seguridad, ante rapidez.
En un log anterior fueron 20 segundos, pero claro en una M2 pcie, cuando en ext4, con la 13.1 arranco en 6 segundos (estando el tiempo de espera del grub2, que eran otros 6 segundos, el total arranca en 12 segundos) .
Con decir que la M2 lee a 1.5TeraBites/por segundo (1 byte= 8 bits) y escribe a 600MB/s, eso no es normal.
También lo de firmware es eventual, a veces sale y otras no (desconozco la causa) :
Código:
FRANK-Z87-D:~ # systemd-analyze
Startup finished in 30.593s (firmware) + 3.806s (loader) + 2.242s (kernel) + 2.343s (initrd) + 24.019s (userspace) = 1min 3.004s
Y lo raro en tiempo negativo, debería salir o contar desde 0 ( en algunas versiones de systemd, lo arreglan, pero en la siguiente, vuelve a estar igual ( lo mas seguro es systemd-analyze, plot, blame--> descarto critical-chain y otros, a veces no se ajustan a la realidad, tardan mas de lo que ponen) .
http://paste.opensuse.org/523613
Y no te extrañe, pruebo arquitecturas de intel con placas asus, y las mas nuevas,son para tomarme una merienda y no haber acabado, incluso las pruebas con Phoronix Test Suite , duran toda la madrugada.
En cambio coges una portátil o un equipo de hace varios años, y van como una bala ( este z87 D con 32Gb, ha estado parado 2 años, porque no rendía, y el x99 deluxe2 con 64Gb y M2, no se está comiendo un rosco, el mejor por ahora es el x79-pro, que es el mas viejo con 64Gb de ram, y otro que vendí ese era el que tardaba 6 segundos en arrancar con ssd de intel) .
Ojo las pruebas se hacen o se suelen hacer iso por iso (muchas de ellas de openQA) , también en todo tipo de raid, y con varios tipos de hardware (menos hacer ov, pruebo varias marcas ssd, wd, etc, fallo rotundo con los híbridos seagate, bueno uno defectuoso y los otros mas o menos dentro de lo normal, 197MB/s lo considero bueno, 1 de 3 teras, nuevo, fallo y se averió en la prueba )
Y si vas a usb 3.0, hay sorpresas tremendas, velocidades grandes, a los pocos segundos y después tasas de 14Kb/s como para hacer una copia en 7 días.
Actualmente, le dedico un poco de tiempo a analizar archivos y sus asociaciones, enlaces simbólicos, iconos, themas, etc y pienso o bien están de broma o falta de coordinación; arregle unos, pero otros hay que hacer un croquis y normalizarlos o ponerse de acuerdo (edite algunos y están asociados a cosas no existentes, por eso no aparecen en el lanzador, puede que sea por lo del idioma, o algún bug, otros los asocian, a temas que no tienen nada que ver, creo que hace falta una depuración y que se normalice un acuerdo, para que cada uno ponga lo mismo, no que pase por openQA, factory y lo dejen pasar así ) .
KDE4 era muy rápido, pero a la larga, podría quedar corto o falta de potencia (perdemos cosas, pero ganaremos algo en el futuro) , plasma, como tal, que lo digan los que ejecutaron las primeras isos, parecía un mac, muy rápidas (pero claro solo con aplicaciones de plasma, he probado las que hacen en suse estudio, sobre todo las de Javier y eran muy rápidas ( ademas no se si estarían usando como base, las escalables o svgz, por que la calidad de los iconos impresionaban ) .
Quien quiera saber mas sobre el tema, que se estudie un poco systemd, vamos que incluso en determinadas circunstancias, el que tarde 5 minutos puede ser normal (dependiendo de lo que lo provoque, 2 minutos y menos es lo mas corriente ) .
Edito: Lo que falle algunas de esas cosas, me refiero a temas y asociaciones, lo veo algo lógico y creo que algunos, se habrán dado cuenta que cuando cambia de tema, algunas cosas, dejan de funcionar, también puede observar en /usr/share ---> aplicaciones, como algunas, usan los mismos iconos, etc ; creo que son cosas que puedan fallar en las aplicaciones, pero no en el resultado de openQA o bien factory, o sean producto de la traducción ) .
Saludos cordiales.
Última edición por mikrios; 07-jul-2018 a las 21:21
Razón: corregir
-

Iniciado por
gvcastellon
...de acuerdo con @karlggest, por ejemplo este no seria buena referencia debido a que hubo una actualización del "kernel". ...por cierto no se si esto lo hace cada vez que se actualiza el "kernel".
Código:
systemd-analyze blame
58.501s purge-kernels.service
20.259s wicked.service
12.511s backup-rpmdb.service
9.150s apparmor.service
8.256s systemd-journal-flush.service
6.834s btrfsmaintenance-refresh.service
6.760s ca-certificates.service
5.568s ModemManager.service
5.290s lvm2-monitor.service
4.317s display-manager.service
4.152s polkit.service
3.587s wickedd-auto4.service
3.540s plymouth-quit-wait.service
3.526s wickedd-dhcp4.service
2.937s initrd-switch-root.service
2.862s wickedd-dhcp6.service
2.697s rsyslog.service
2.663s avahi-daemon.service
2.516s nscd.service
2.235s home.mount
2.059s chronyd.service
1.982s kbdsettings.service
1.813s plymouth-start.service
1.478s postfix.service
1.242s mcelog.service
Salud.
Observo que wicked-service ocupa 20 segundos. A mi me ocurría algo parecido, me ocupaba 30 segundos y alguna vez se hacía interminable en el ordenador de sobremesa con ethernet. Observé que el portátil inicia como un rayo y no aparece el wicked-sevice en el arranque, sino el network-manager. Todo ello a pesar de haber instalado leap 15 en ambos de la misma forma. Decidí eliminar el wicked-service de este modo.
sudo systemctl disable wicked
sudo systemctl enable NetworkManager
Después reinicié y ahora arranca como un rayo. Con una sola vez que se lancen los dos comandos que cito, systemd ya no vuelve a usar wicked-service nunca más. Cuando el instalador, por defecto, no instala wicked en el portatil con wifi, supongo que no es necesario. Por si acaso, he consultado si otras distros, como Debian, usan wicked y ni siquiera aparece en sus repositorios. Todo ello prueba que es completamente prescindible.
Saludos.
Última edición por Facior; 16-jul-2018 a las 09:56
Marcadores