acelerar/optimizar el arranque y sistema linux gentoo

COMO ACELERAR Y OPTIMIZAR NUESTRA MAQUINA
tambien conocido como "como volar con gentoo" xD

Esta guía pretende explicar los diferentes métodos que están a nuestra disposición para optimizar y acelerar linux gentoo. Algunos de ellos son completamente seguros y no pueden dañar nuestro sistema (como el punto 1), aunque siempre se recomienda hacer copias de seguridad al modificar ficheros importantes.

INDICE

[seguridad vs velocidad]
16. Scripts útiles[/list]

0. Como hacer pruebas sin correr riesgos

Para hacer pruebas con ebuilds, archivos de configuracion y demas, en su dia me hice una instalacion dentro de un chroot para no correr riesgos. Hay una guia en ESTE post para conseguir el mismo proposito, crear una instalacion de gentoo dentro de gentoo, para poder hacer las pruebas que querais sin dañar el sistema. También podeis usar vmware o uml, pero el metodo de chroot es mas sencillo. Una vez instale gentoo en el chroot, hice una imagen comprimida. Asi, cada vez que hago pruebas y algo sale mal, vuelvo a descomprimir la imagen y tengo otra instalacion limpia para seguir probando (y mi sistema no corre ningún riesgo).

1. Optimización de los ficheros de inicio y configuración

Hay algunas operaciones que se realizan al iniciar el sistema que no siempre son necesarias. Vamos a modificar los scripts para que en vez de hacer estas comprobaciones siempre, primero mire si son necesarias o no y luego las realice o no según convenga.

/etc/init.d/modules

cambiar:

Código:

ebegin "Calculating module dependencies"
/sbin/modules-update &>/dev/null
eend $? "Failed to calculate dependencies"

por:

Código:

if [ /etc/modules.d -nt /etc/modules.conf ]
then
ebegin "Calculating module dependencies"
/sbin/modules-update &>/dev/null
eend $? "Failed to calculate dependencies"
else
einfo "Module dependencies are up-to-date"
fi

Esto hará que sólo haga un "modules-update" si realmente es necesario porque ha habido cambios.

/etc/init.d/localmount

cambiar:

Código:

mount -at nocoda,nonfs,noproc,noncpfs,nosmbfs,noshm >/dev/null

por:

Código:

mount -aFt nocoda,nonfs,noproc,noncpfs,nosmbfs,noshm >/dev/null

Esto hará que inicie los mounts locales en paralelo, y no uno detras de otro.
nota: algunos han comentado que este tweak da problemas usando kernels inestables 2.6.9-rcX tipo nitro patchset o love sources.

/etc/init.d/bootmisc

cambiar:

Código:

if [ -x /sbin/env-update.sh ]
then
ebegin "Updating environment"
/sbin/env-update.sh >/dev/null
eend 0
fi

por:

Código:

if [ -x /sbin/env-update.sh ]
then
if [ /etc/env.d -nt /etc/profile.env ]
then
ebegin "Updating environment"
/sbin/env-update.sh >/dev/null
eend 0
else
einfo "Environment up-to-date"
fi
fi

Esto hará que sólo haga un "env-update" si realmente es necesario porque ha habido cambios.

/etc/conf.d/rc

cambiar:

Código:

RC_PARALLEL_STARTUP="no"

por:

Código:

RC_PARALLEL_STARTUP="yes"

Esto hará que el sistema inicie la carga de servicios en paralelo y no uno detrás de otro.

2. Usando rc-update

La gestión de los runlevels es muy facil en gentoo gracias a rc-update, que nos facilita muchísimo el trabajo:

para mirar como tenemos configurado el inicio:

Código:

# rc-update show

para quitar alguna aplicacion:

Código:

# rc-update del aplicacion runlevel

nota: sustituir runlevel por boot o default (aunque pueden crearse más), si se omite el runlevel la buscará en todos los runlevels y la quitará del runlevel en el que este la aplicación

para añadir alguna aplicación:

Código:

# rc-update add aplicacion runlevel

Yo lo tengo repartido entre boot y default, notese que algunas aplicaciones se tienen que cargar antes que otras ya que son necesarias (si editais los scripts de /etc/init.d/ podeis ver los depends de cada aplicación). Por ejemplo, para iniciar sshd, antes tendremos que iniciar los servicios basicos de red.

Recientemente me he creado otro runlevel (battery) en la que he puesto todo lo que quiero tener corriendo cuando este solo en bateria. Luego con la ayuda de acpid, lo he configurado para que cuando quito el cable de corriente pasa al runlevel battery, y si lo enchufo pasa a default otra vez.
Podeis mirar en que runlevel estais y que hay iniciado del mismo con el comando rc-status:

Código:

# rc-status
Runlevel: battery
acpid started
alsasound started
domainname started
gpm started
hdparm.battery started
local started
metalog started
speedfreq.battery started
vixie-cron started
wireless.baterry started

más información sobre los RC- AQUI.

Para los que arrancan directamente a X (digo xdm ya sea con xdm, kdm o gdm..) he leido que poner el xdm en el nivel de rc boot en vez de default, hará que vaya cargando las X mientras paralelamente va cargando en background el resto de servicios ya que primero carga lo que ponemos en boot y luego el default (si surge alguna incompatibilidad porque requiere algun servicio tipo getty, ponedlo en el script de inicio de xdm como depend). Si alguien lo prueba que comente su experiencia.

3. Configuración de las cflags y ldflags

En cuanto a las CFLAGS (podeis configurarlas en /etc/make.conf) son parametros que le pasamos al GCC a la hora de compilar los paquetes con emerge. Aqui uno puede ser más o menos conservador, en ESTA página y en ESTA hay bastantes recomendaciones útiles. Personalmente, mis chost y cflags para mi PIV son las siguientes:

Código:

CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium4 -mcpu=pentium4 -O3 -pipe -fforce-addr -falign-functions=4 -fprefetch-loop-arrays -fomit-frame-pointer"

nota: los cflags cambian un poquito en las nuevas versiones de gcc (3.4.x), ya que -mcpu queda deprecated, y se usa -mtune. Ademas ya se acepta pentium-m como arquitectura. Los cflags de mi portatil con el gcc 3.4.x son los siguientes:

Código:

CFLAGS="-O3 -march=pentium-m -mtune=pentium-m -pipe -ftracer -fomit-frame-pointer"

Otra "flag" interesante es -frepo, que aunque aumenta el tiempo de compilación optimiza bastante los programas c++, y no tiene efecto sobre plain c. ATENCION, esta cflag trae problemas con bastantes problemas, asi que si te peta una compilación lo primero sera quitarla. Lo ideal es ponerla solo en CXXFLAGS, asi:

Código:

CXXFLAGS="${CFLAGS} -frepo"

El tema de las ldflags esta explicado y discutido AQUI y AQUI. Son optimizaciones para el dinamic loader (ld), asi que las optimizaciones irian por el mismo camino que prelink. Yo las hye estado probando y no me han dado ningún problema al compilar, y se nota en varios paquetes una ligera mejora (fluxbox, por ejemplo). Yo ya he añadido definitivamente a mi make.conf:

Código:

LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s"

Algo más conservador sería

Código:

LDFLAGS="-Wl,-O1"

4. Usando hdparm

Otra utilidad importante es hdparm, que sirve para configurar correctamente el disco duro para que aproveche todas las opciones que este ofrece:

Código:

# emerge hdparm
# rc-update add hdparm default

Ver /etc/conf.d/hdparm

ver configuración actual:

Código:

# hdparm -i /dev/hda

test velocidad:

Código:

# hdparm -Tt /dev/hda

En mi caso, tengo el archivo /etc/conf.d/hdparm modificado asi para sacar el maximo rendimiento de mi disco duro:

Código:

hda_args="-d1 -X69 -c1"
cdrom0_args="-d1"

mas info sobre la configuración AQUI y:

Código:

# man hdparm

5. Ventajas de prelink

Prelink es una potente herramienta, ya que nos permite pre-linkear las librerias que requiere un binario antes de utilizarlo. En cristiano, en vez de buscar cada vez que ejecutamos el binario que librerias va a necesitar, lo que hace prelink es modificar el binario, añadiendo una pequeña descripción de las librerias requeridas. Esto evita cada vez tener que hacer la busqueda de librerias requeridas (shared libraries) por si ha habido cambios, ya que el ejecutable ya sabe cuales son.
Importante: Cada vez que se actualizan librerias que son requeridas por binarios (como glibc), se deben prelinkear otra vez los ejecutables.
Esto nos ofrece una optimización en el tiempo de ejecución que notaremos en aplicaciones grandes, como por ejemplo kde (ademas, si prelinkeamos el KDE ya no necesita cargar cada vez el kdeinit, cosa que aun lo hace más rápido). Los pequeños binarios son ya muy rapidos y no apreciaremos la diferencia.
Requerimientos: es necesario haber compilado los binarios con binutils-2.13.90.0.xx y gcc-3.2 o superior, y tener instalado glibc-2.3.1-r2 o superior. Ademas tened en cuenta que el tamaño de los binarios aumentará levemente, y para hacer el proceso necesitas tener suficiente espacio libre en el disco.
Procedimiento:

Código:

# emerge prelink

El archivo básico de configuración es /etc/prelink.conf

Código:

# prelink -afmR

Este es el uso típico y más común, que prelinkeará TODOS los binarios y mirará si ya estaban prelinkeados y los actualizará.
Seguramente os dará algunos errores al hacer el prelink, ya que hay algunos binarios con los que no funciona (los comprimidos con upx, por ejemplo).
Más información AQUI, y/o man prelink.

6. Gestionando la memoria swap

En este apartado solo quería indicar un par de cosillas que nos pueden ayudar.
En primer lugar, si se dispone de dos discos es mucho mejor poner la partición de swap en el segundo disco (teniendo la partición raíz en el primero) ya que mejorará enormemente los tiempos de lectura y escritura.

También desaconsejar usar un archivo en vez de una partición swap. Yo lo probé en un ordenador, eliminé la partición de swap y cree un archivo llamado ./swap de 256 M, e indique a /etc/fstab que usase ese archivo como swap. Evidentemente este procedimiento hace el sistema más lento.

Otro concepto a tener en cuenta es el de "swappiness" (kernel 2.6+). Cuando un programa necesita memoria y la RAM esta llena, hay dos opciones: o bien se vacía la RAM un poco eliminando los datos más antiguos, o bien se tira de memoria swap (más lenta que la ram). En los nuevos kernels (en los 2.4 decide el kernel) 2.6, su puede añadir una variable para ayudar al kernel a decidir si debe vaciar una parte de la ram o usar la memoria de disco (swap):

/etc/sysctl.conf

Código:

vm.swappiness = 40

El valor puede estar entre 0 y 100, cuanto más cerca de 0 más tenderá el sistema a vaciar la ram, mientras que si lo ponemos cerca de 100 optará más frecuentemente por usar la memoria swap. Por defecto tiene un valor de 60. Yo en mi portatil lo tengo puesto a 25 (no quiero calentar más el disco!). Podeis usar ´free -m´ para ver las estadísticas de vuestra memoria en un momento dado.

7. Ccache

ccache es una aplicación (incluida en portage) que hace de cache para el compilador. Con este pequeño programa (no necesita configuración, simplemente se tiene que hacer un emerge), ganaremos tiempo al compilar los paquetes, sobretodo con los make's grandes (aunque usar cache al compilar paquetes pueda parecer que no tiene lógica ya que cada paquete es diferente, acelera sobretodo las instrucciones que siempre son las mismas, como make clean).
Una vez hecho el emerge se activa solo, podeis comprobarlo haciendo:

Código:

# emerge info | grep ccache
ccache version 2.3 [enabled]

8. Instalando gentoo en varios pc's, distcc

distcc es una herramienta que nos facilita mucho la vida si tenemos que instalar gentoo en varios ordenadores en la misma red. Puede combinarse con ccache, optimizando asi el tiempo de compilación. No voy a hablar mucho de esta herramienta ya que son pocos los que tienen que instalar linux en varios ordenadores. Simplemente decir que es mucho más rápido que el sistema convencional (cada uno compilando sus paquetes), y usando cross compiling no es necesario que los ordenadores sean iguales, o tengan el mismo procesador.. simplemente compartiran las tareas de compilación.
Más información AQUI.

[size=18]9. USE's, que son y como se usan para optimizar el sistema[/size]

Las variables USE son una herramienta más que nos ofrece gentoo para configurar nuestra sistema a nuestro gusto. Por ejemplo, imaginemos que vamos a compilar apache (codigo simplificadopara facilitar la lectura):

Código:

# emerge -pv apache
[ebuild N ] net-www/apache-2.0.50 -debug -doc -ipv6 +ssl 6,197 kB

Las opciones (+/-) que aparecen detras del nombre del programa que vamos a instalar (gracias a usar emerge -v) son los USE's que podemos usar para configurar la instalación de apache. Si, por ejemplo, no vamos a querer usar ssl con nuestro apache, podemos hacer:

Código:

# USE="-ssl" emerge -pv apache
[ebuild N ] net-www/apache-2.0.50 -debug -doc -ipv6 -ssl 6,197 kB

Como vemos, ssl ya sale desactivado y se compilará apache sin soporte para ssl.

En este ejemplo, hemos usado una variable USE directamente al hacer el emerge, aunque puedes fijar las variables que quieras para todas las compilaciones en /etc/make.conf

Este método de poner el ACCEPT_KEYWORDS en la command line al hacer un emerge no esta recomendado, si no quieres tener el ~x86 en tu make.conf y por alguna razón necesitas algun paquete en su versión más novedosa (como drivers y cosas asi), hazlo asi:

Código:

# echo "app-editors/nano ~x86" >> /etc/portage/package.keywords

Es importante que a medida que vayamos instalando paquetes, miremos las variables USE del mismo para no compilar cosas que no vamos a usar. A veces modificando las variables USE, ya no serán necesarias algunas dependencias, ahorrando tiempo y espacio de disco. Por ejemplo, al hacer un emerge del bitchx nos quiere instalar X, xmms, y otras dependencias un poco absurdas para un cliente IRC de consola. Usando USE="-X -xmms" al hacer el emerge del bitchx nos ahorramos esas dependencias.

Como veis, las variables USE son una poderosa herramienta para usar con emerge, nos permite tener un mayor control sobre como se van a compilar los paquetes que hemos seleccionado.

Teneis una lista de las variables USE en /usr/portage/profiles/use.desc

10. Modificando los ebuilds e inyectando paquetes

Este método es muy útil, pero también tiene su peligro ya que implica modificar ebuilds. Mantened siempre una copia de seguridad de los mismos antes de hacer modificaciones.

¿Que es inyectar un paquete y de que me sirve?
Nunca te ha pasado que vas a instalar un paquete, y como dependencias te requiere otro que no quieres instalar? Por ejemplo, muchos usuarios gestionan el kernel directamente (descargando las sources en /usr/src), y no usan portage para gestionar el kernel. Entonces, al emerger paquetes que necesitan los sources del kernel instalados (o que varia su funcionamiento en los kernels 2.4 y los 2.6, como alsa) intentarán instalar los development-sources (o gentoo-sources para 2.4). Vas a permitirlo, malgastando ancho de banda descargando 30 mb's, y luego instalando el paquete?? No... sobretodo porque sabes que no necesitas ese paquete.
Para hacer un inject, tienes que poner el nombre del ebuild concreto, no simplemente el nombre del paquete:

Código:

# emerge inject sys-kernel/development-sources-2.6.8.1

Lo único que hace inject es "engañar a portage", simulando que ese paquete ya está instalado.
En este caso concreto del alsa, también tendríamos que editar /var/cache/edb/virtuals y añadir "virtual/alsa sys-kernel/development-sources", para que ya no lo requiera (conste como instalado en el virtuals).
Esta opción de inject es, desde mi punto de vista, mucho más interesante que la de mask. La diferencia es que si masqueamos un paquete, y es dependecia directa de otro no nos dejará instalarlo, dejándonos colgados sin el programa que queríamos. La opción de masquear paquetes es más bien para evitar ciertas versiones de programas, y cosas asi. Para masquear paquetes simplemente los teneis que añadir en /etc/portage/package.mask
Para hacer un mask de una versión concreta:

Código:

=sys-kernel/development-sources-2.6.7

Para hacer un mask de un paquete en general:

Código:

=sys-kernel/development-sources

Tambien puedes usar los parametros <=> para hacer masks de versiones concretas, versiones anteriores, etc.

11. Halt vs Suspend

Nunca te has preguntado porque apagas el ordenador, si puedes suspenderlo a memoria o disco? Suspender el ordenador a memoria tiene el inconveniente de que gastará batería, y perderemos los datos en cuanto se agote la misma. Pero una opción más interesante es suspender a disco, con lo que el ordenador se "apaga", pero no perdemos la sesión.

De esta manera nos ahorramos iniciar todo el sistema y los servicios cada vez que vamos a usar el ordenador.
Yo he usado swsusp2 en mi portatil y funciona muy bien, aunque para instalarlo tienes que parchear el kernel. En ESTE post se explica (en ingles) como hacerlo, por lo que no voy a explicarlo aqui. Simplemente si alguien tiene algún problema o no puede instalarlo podeis postear en este hilo.

12. Xdelta - Deltup

En ESTE post se anunciaba la reaparición de deltup en una nueva versión "mejorada", que se basa en cuando se tiene que descargar un paquete nuevo, si se tiene alguna version vieja bajarse solo la diferencia entre los dos archivos. Por ejemplo, si tenemos bajado el gcc3.3 y sale el gcc3.4, al hacer el emerge del nuevo gcc deltup se conectaria al servidor y miraria si existe algun archivo DTU. En el caso de haberlo para la version que tienes bajada, se bajaria solo el DTU y formaria el archivo final en tu disco duro. Esto puede suponer una reducción muy considerable a la hora de descargar paquetes, que sobretodo apreciarán los usuarios con conexiones bajas tipo 56k o adsl compartidas. Siguiendo el procedimiento que se explica en el post lo tendreis funcionando en 5 minutos! Yo lo he estado probando y funciona bastante bien, aunque actualmente no lo uso porque tengo conexión de sobra. Eso si, lo recomiendo para usuarios que les duela en el corazon cuando emerge -u les muestra una lista muy grande.
El incoveniente seria que no se debe hacer demasiada limpieza de /usr/portage/distfiles, aunque si pueden borrarse los paquetes de versiones ya actualizadas.

13. Native POSIX Thread Library

Esta libreria (conocida como NPTL) puede mejorar mucho el rendimiento del sistema, ya que es hasta 4 veces más rápida que la estandar de linux (LinuxThreads) al crear nuevos threads. Lo ideal si se quiere usar nptl es instalar los linux26-headers y una version reciente de glibc y gcc. Para usar nptl simplemente teneis que recompilar glibc con el flag USE "nptl" activado.

nota: para usar nptl hace falta una version de gcc 3.x o superior!

AQUI teneis un enlace a una web en el que se habla de nptl y se postea el resultado de algunos benchmarkings.

14. GCC

GCC es sumamente importante, especialmente en una distribución como gentoo en la que los usuarios buscan optimizar su sistema. Usar una versión actual de gcc tiene varias ventajas ya que todo el codigo que generemos estará mejor optimizado, sobretodo porque las versiones nuevas de GCC trabajan bastante este aspecto (a partir de gc 3.4.X ya se puede usar -march=pentium-m para los procesadores centrino)

Instalar una version novedosa de gcc es fácil, simplemente haced un emerge de gcc con ~x86:

Código:

# echo "sys-devel/gcc ~x86" >> /etc/portage/package.keywords
# emerge -u gcc

15. Filesystems [seguridad vs velocidad]

Despues de probar varios filesystems, actualmente uso reiser4 por ser el más rápido. Creo que, a no ser que estemos hablando de servidores, es muy útil usar un sistema de archivos que sea rápido, y mantener nuestras copias de seguridad actualizadas. De todas formas, habiendo pasado por ext2, ext3, reiserfs, xfs, reiser4 y algunos otros de encriptación, NUNCA he tenido ningún problema de corrupción de archivos, y han habido varios cortes de luz. Entre un "emerge sync" en un sistema con ext3 y un un "emerge sync" en un sistema con reiser4 pueden haber varios segundos de diferencia (al hacer el primer emerge sync del sistema, que actualiza casi todos los paquetes del arbol se nota muchisimo la diferencia, quizas 1 o 2 minutos). Reiser4 aun no esta incluido en el kernel porque hace muy poco que ha salido la versión final, aunque existen parches que se incluyen en los kernels CK, nitro, love, etc.

Para convertir la partición / a reiser4, tendreis que haceros con un livecd que soporte reiser4 como ESTE, e instalar un kernel que lo soporte (ck-sources por ejemplo). Hay varias guias en el foro.

NOTA: Mucha gente se queja de que no encuentra Reiser4 en el menu de FileSystems del kernel, aseguraos de que en "kernel hacking" teneis desactivada la opción "use 4kb for kernel stacks instead of 8kb", que no es compatible con reiser4 por el momento, y ya os aparecerá la opción de reiser4 justo encima la opción de reiserfs.

Extraido de Gentoo Forums

Salu2