| View previous topic :: View next topic |
| Author |
Message |
asph
l33t
Joined: 25 Aug 2003
Posts: 741
Location: Barcelona, Spain
|
 Posted: Wed Jul 14, 2004 9:35 pm Post subject: [GUIA] 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
0. Como hacer pruebas sin correr riesgos
1. Optimización de los ficheros de inicio y configuración
2. Usando rc-update
3. Configuración de las cflags y ldflags
4. Usando hdparm
5. Ventajas de prelink
6. Gestionando la memoria Swap
7. Ccache
8. Instalando gentoo en varios pc's, distcc
9. USE's, que son y como se usan para optimizar el sistema
10. Modificando los ebuilds e inyectando paquetes
11. Halt vs Suspend
12. Xdelta - Deltup
13. NPTL
14. GCC
15. Filesystems [seguridad vs velocidad]
16. Scripts útiles
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:
| Code: | ebegin "Calculating module dependencies"
/sbin/modules-update &>/dev/null
eend $? "Failed to calculate dependencies"
|
por:
| Code: | 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:
| Code: | | mount -at nocoda,nonfs,noproc,noncpfs,nosmbfs,noshm >/dev/null |
por:
| Code: | | 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:
| Code: | if [ -x /sbin/env-update.sh ]
then
ebegin "Updating environment"
/sbin/env-update.sh >/dev/null
eend 0
fi |
por:
| Code: | 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:
| Code: | | RC_PARALLEL_STARTUP="no" |
por:
| Code: | | 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:
para quitar alguna aplicacion:
| Code: | | # 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:
| Code: | | # 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:
| Code: | # 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:
| Code: | 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:
| Code: | | 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:
| Code: | | 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:
| Code: | | LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s" |
Algo más conservador sería
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:
| Code: | # emerge hdparm
# rc-update add hdparm default |
Ver /etc/conf.d/hdparm
ver configuración actual:
| Code: | | # hdparm -i /dev/hda |
test velocidad:
| Code: | | # 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:
| Code: | hda_args="-d1 -X69 -c1"
cdrom0_args="-d1" |
mas info sobre la configuración AQUI y:
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:
El archivo básico de configuración es /etc/prelink.conf
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
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:
| Code: | # 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.
9. USE's, que son y como se usan para optimizar el sistema
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):
| Code: | # 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:
| Code: | # 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:
| Code: | | # 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:
| Code: | | # 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:
| Code: | | =sys-kernel/development-sources-2.6.7 |
Para hacer un mask de un paquete en general:
| Code: | | =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:
| Code: | # 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.
16. Scripts útiles
Hay varios scripts que corren por los foros que son bastante útiles para gestionar nuestro sistema:
1- esearch
Este ya ha sido incluido en portage (podeis instalarlo con emerge esearch), y es una utilidad para hacer las busquedas en el arbol de portage más rápidas. Despues de cada emerge sync tendremos que actualizar la base de datos de esearch con eupdatedb (a no ser que usemos esync, que hace un emerge sync, eupdatedb y muestra una lista con los nuevos ebuilds a actualizar)
2- portagedb
Parte del mismo concepto de esearch, pero es más rápido (y tarda muchisimo menos en actualizar la base de datos). Aun es un proyecto joven y le falta trabajo, aunque promete bastante.
Más información AQUI.
3- Cruft
Este script nos generará una lista de todos los ficheros del sistema que podrían ser borrados. El eobjetivo es mantener el sistema limpio y ordenado. Hay que ir con cuidado con los falsos positivos, aunque en general funciona muy bien (muestra archivos de configuracion de paquetes que has desinstalado, logs antiguos, etc etc).
Más información AQUI.
3- Stale
Interesante script, que nos ayudara a mantener /usr/portage/distfiles con un tamaño optimo. El script hara una busqueda en ese directorio, y borrar (cuando se invoca con --nopretend) los archivos viejos, NO los actuales.
Es decir, que si tenemos libtool-1.3.5.tar.gz y libtool-1.5.2.tar.gz, borrara el archivo libtool-1.3.5.tar.gz (es muy comodo, ya que primero muestra la lista y despues los borra tras tu aceptación). Se lia un poco con ficheros tipo font-arial-iso-8859-1 y font-arial-iso-8859-2, en los que la numeración no correspone a la version (lo mismo con glib y gtk con sus respectivas versiones 1.x y 2.x).
Más información AQUI.
4- Porthole
Interfaz hecha en python (+gtk) para portage, que nos ofrece un aspecto más visual, y nos facilita la gestion del sistema. Esta incluida en portage, bastará con un emerge porthole.
4- guitoo
Otra interfaz para portage, realizada con QT (para los amantes de kde). Aun es un proyecto joven, aunque promete bastante.
Más información AQUI.
-en constante progreso y actualización 11/01/2005-
_________________
gentoo sex is updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; emerge --oneshot condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; emerge -C condom; make clean; sleep
Last edited by asph on Tue Jan 11, 2005 4:53 pm; edited 35 times in total |
|
| Back to top |
|
 |
luisfeser
Guru
Joined: 22 May 2004
Posts: 543
Location: /España/Toledo
|
| Posted: Wed Jul 14, 2004 11:14 pm Post subject: |
|
|
Interesante post 
Pero el truco de los mulos esta bien? me da errores y no carga algunos modulos 
Pero el del localmount se nota mucho, si  , y el del env-update, pues nos se, jeje. Pero en general si k se nota bastante. |
|
| Back to top |
|
|
asph
l33t
Joined: 25 Aug 2003
Posts: 741
Location: Barcelona, Spain
|
| Posted: Thu Jul 15, 2004 11:46 am Post subject: |
|
|
sorry, habia un pequeño error en el script 
ya lo he arreglado y he añadido tambien que cuando no es necesario hacer el update de los modulos o el del environment lo diga (up-to-date).
un saludo
_________________
gentoo sex is updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; emerge --oneshot condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; emerge -C condom; make clean; sleep |
|
| Back to top |
|
|
Soulcito
Developer
Joined: 01 Jul 2004
Posts: 48
Location: Lima - Peru
|
| Posted: Thu Jul 15, 2004 2:38 pm Post subject: |
|
|
Creo que otro *truco* o mas que todo un consejo, seria iniciar en el arranque SOLO los servicios que siempre se usan y son indispensables, los que no lo son se podrian inicializar manualmente si se diera el caso. No creo que sea poco comun tener servicios que casi nunca usamos incializados y demoran harto ... , no se como por ejemplo nessusd (bueno fue mi caso por un par de semanas :S, ke tonto no? )
_________________
"Live as if you were to die tomorrow. Learn as if you were to live forever"
http://soulse.blogspot.com |
|
| Back to top |
|
|
-RdX-
n00b
Joined: 23 Dec 2003
Posts: 60
Location: Sevilla (spain)
|
| Posted: Thu Jul 15, 2004 3:31 pm Post subject: |
|
|
hace tiempo vi un post sobre como optimizar las "FLAGS" del gcc incluso venia un script que dependiendo de cpuinfo te daba las opciones apropiadas.
En mi caso fueron estas, tengo un pentium 4 HT a 2,8:
| Code: |
CFLAGS="-O2 -march=pentium4 -mfpmath=sse -msse2 -mmmx"
|
[/code] |
|
| Back to top |
|
|
luisfeser
Guru
Joined: 22 May 2004
Posts: 543
Location: /España/Toledo
|
| Posted: Thu Jul 15, 2004 5:20 pm Post subject: |
|
|
Ya funciona bien lo de los modulos
Y se nota mucho si. A ver si encontrais alguna movida mas, jeje.
El tema de las flags con el script k comentas -RdX-, no se, pero da unas flags muy normalillas, indicadas para el procesador, pero sin optimizaciones mas allá de lo normal. |
|
| Back to top |
|
|
asph
l33t
Joined: 25 Aug 2003
Posts: 741
Location: Barcelona, Spain
|
| Posted: Fri Jul 16, 2004 2:36 pm Post subject: |
|
|
es normal, son gente conservadora
el único problema de usar tantos cflags es que tarda un poco más al compilar los paquetes, aunque luego "teoricamente" debería ir más rápido..
otra "cosilla" que puede ser interesante para recien iniciados a gentoo es la instrucción:
que os mostrará como teneis configurados los scripts del inicio, y si estan en boot o default. De esta forma podeis agregar/quitar servicios según os convenga:
añadir servicio X (en default o boot según convenga)
| Code: | | rc-update add X default |
quitar servicio X (se puede omitir "default", y buscará en todos)
| Code: | | rc-update del X default |
(un amigo mio arrancaba varios procesos que no usaba para nada, y evidentemente despues de quitarlos el arranque era un poco más rápido)
más info `man rc-update`, un saludo
_________________
gentoo sex is updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; emerge --oneshot condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; emerge -C condom; make clean; sleep |
|
| Back to top |
|
|
luisfeser
Guru
Joined: 22 May 2004
Posts: 543
Location: /España/Toledo
|
| Posted: Fri Jul 16, 2004 3:45 pm Post subject: |
|
|
A mi el tema este de los servicios siempre me ha tenido un poco despistado....
y es k hay algunos k se para k sirven, como el acpid, alsasound, cups, etc...
pero hay un grupito de ellos k ni idea, como el urandom, net.lo, serial, winbind, y algunos mas. Lo he echado un vistazo, a ver si me aclaro y nada.
El caso es k el servicio clock me da errores de vez en cuando, y me dice k ya esta corriendo, o algo similar. Asi k lo he kitado y todo sigue funcionando correctamente, y se supone k hay otros servicios a su vez k dependen de este. Pero bueno, si se queja mi gentoo ya se lo pondré, jeje.
Si sabeis de algun sitio donde expliquen para que son estos servicios y si son idispensables (como el localmount), pues comentadlo.
Saludos. |
|
| Back to top |
|
|
wel
Apprentice
Joined: 03 Sep 2003
Posts: 207
|
| Posted: Fri Jul 16, 2004 5:18 pm Post subject: |
|
|
| Que me corrijan si me equivoco, pero creo que el script net.lo inicializa la interfaz de red loopback, y el serial lo que hace es configurar los puertos serie. Winbind me suena, y urandom... ¿no será algo relacionado con el generador de números aleatorios?. No lo sé, tendría que mirar. |
|
| Back to top |
|
|
asph
l33t
Joined: 25 Aug 2003
Posts: 741
Location: Barcelona, Spain
|
| Posted: Tue Jul 20, 2004 9:54 am Post subject: |
|
|
alguien ha probado lo de arrancar el xdm en 'boot'? yo estuve haciendo pruebas en un pc e iba bastante bien, mientras arrancaba las X iba cargando los demas servicios en background
_________________
gentoo sex is updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; emerge --oneshot condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; emerge -C condom; make clean; sleep |
|
| Back to top |
|
|
flipy
Apprentice
Joined: 15 Jul 2004
Posts: 232
|
| Posted: Tue Jul 20, 2004 1:36 pm Post subject: |
|
|
genial howto, quizas deberia estar en sticky no?
muy buena la verdad! |
|
| Back to top |
|
|
asph
l33t
Joined: 25 Aug 2003
Posts: 741
Location: Barcelona, Spain
|
| Posted: Tue Jul 20, 2004 2:11 pm Post subject: |
|
|
me alegro de que sea útil para alguien, la verdad es que son detalles que ayudan bastante a acelerar el arranque, sin perder rendimiento o capacidad (simplemente "desactiva" opciones de arranque CUANDO no son necesarias).
si alguien tiene más consejos o optimizaciones que las comparta
un saludo
_________________
gentoo sex is updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; emerge --oneshot condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; emerge -C condom; make clean; sleep |
|
| Back to top |
|
|
Sertinell
Guru
Joined: 19 May 2004
Posts: 582
|
| Posted: Tue Jul 20, 2004 4:58 pm Post subject: |
|
|
| Hola yo acabo de probarlo y en ese aspecto no noto diferencia. Lo qe si no to es lo de los modulos. Mi problema esta en hotplug, qe me tarde muxo en cargar, sobre todo la parte del usb |
|
| Back to top |
|
|
quelcom
Guru
Joined: 16 Mar 2004
Posts: 306
Location: Catalonia
|
| Posted: Tue Jul 20, 2004 5:14 pm Post subject: |
|
|
| Quote: | | Hola yo acabo de probarlo y en ese aspecto no noto diferencia. Lo qe si no to es lo de los modulos. Mi problema esta en hotplug, qe me tarde muxo en cargar, sobre todo la parte del usb |
Cierto, yo en este aspecto decidí sacarlo del inicio, ya que en mi maquina no entran practicamente nunca artefactos USB y demas. En el momento que meta cualquier cosa antes hago un rc-update add hotplug default y reinicio.
Así me ahorro varios segundos mas que siempre se agradecen.
PD: genial tuto siddhartha, pa bookmarks  |
|
| Back to top |
|
|
Sertinell
Guru
Joined: 19 May 2004
Posts: 582
|
| Posted: Tue Jul 20, 2004 5:18 pm Post subject: |
|
|
Umm no seria mas facil un | Code: | | #/etc/init.d/hotplug start |
?
No me gusta reiniciar mi sistema amenudo |
|
| Back to top |
|
|
asph
l33t
Joined: 25 Aug 2003
Posts: 741
Location: Barcelona, Spain
|
| Posted: Wed Jul 21, 2004 7:11 am Post subject: |
|
|
gracias quelcom
yo como en tu caso el hotplug y los usb's no los uso mucho, por lo que tampoco lo cargo en el inicio.. eso si, como dice Sertinell puedes arrancar el servicio sin necesidad de reiniciar.
incluso puedes hacerte alias tipo:
/etc/profile
| Code: | alias hotplug-on='/etc/init.d/hotplug start'
alias hotplug-off='/etc/init.d/hotplug stop' |
puedes usarlo para los servicios que mas uses a lo largo del dia (en mi caso sería más el sshd), a mi me parece bastante comodo.
Lo mismo con unidades del disco las que no accedas siempre (como por ejemplo particiones de windows o otros sistemas), puedes poner el parametro "noauto" en el /etc/fstab y hacer el mount cuando te interese (aqui también puedes hacerte un alias! xD)
parece innecesario montarlas cada vez si quizas no vas a usarlas
un saludo
_________________
gentoo sex is updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; emerge --oneshot condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; emerge -C condom; make clean; sleep |
|
| Back to top |
|
|
quelcom
Guru
Joined: 16 Mar 2004
Posts: 306
Location: Catalonia
|
| Posted: Wed Jul 21, 2004 7:47 pm Post subject: |
|
|
Teneis razon, puedo arrancar hotplug sin tener que reiniciar. Pensaba que hotplug solo podia aparecer en el arranque y que despues no podias iniciarlo.
Respecto a acceder a unidades de disco no siempre usadas pues siempre he utilizado el noauto: en el disco de win y en una particion en el mismo disco de gentoo que la uso para backups y otras cosas.
Despues lo monto y desmonto en un plis con la utilidad que incluye gkrellm (Builtins > FIle System).
Saludos |
|
| Back to top |
|
|
L41n
Tux's lil' helper
Joined: 21 Jul 2004
Posts: 85
|
| Posted: Wed Jul 21, 2004 9:51 pm Post subject: |
|
|
He aplicado todos los cambios que has comentado y he ganado algunos segundos de arranque.
Antes de hacer los cambios, he calculado el tiempo de arranque y han sido unos 17 segundos hasta el inicio de KDM. Despues de aplicar todos los cambios, he notado que ha pasado de arrancar en 17 segundos a terminarlo en 14.
Tambien he cambiado el init de XDM al boot y aunque la carga total de todo se siga haiendo en 14 segundos, da una sensación de mas velocidad ya que se inicia antes mientras que los otros procesos de inicio se van cargando.
Gracias siddhartha, una guia estupenda
_________________
Emerge your liberty. |
|
| Back to top |
|
|
asph
l33t
Joined: 25 Aug 2003
Posts: 741
Location: Barcelona, Spain
|
| Posted: Thu Jul 22, 2004 9:44 am Post subject: |
|
|
bueno no esta nada mal, 3 segundos.. es un 18% más rápido
alguien como yo que no dejo el pc siempre encendido, igual inicio el PC unas 500-600 veces al año o más, eso serían 30 minutos que nos ahorramos
30 minutos que podemos dedicar a otras cosas, como jugar al UT xD
_________________
gentoo sex is updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; emerge --oneshot condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; emerge -C condom; make clean; sleep |
|
| Back to top |
|
|
ertomas
Apprentice
Joined: 25 Dec 2003
Posts: 270
Location: Barcelona, /home/tomascayuelas
|
| Posted: Thu Jul 22, 2004 7:04 pm Post subject: |
|
|
Excelente!!!!!! 
Se nota notablemente, y le da mayor fluidez a la hora de cargar,los modulos, particiones...etc...
Estupendo, te lo has currao!!!!
Un saludo |
|
| Back to top |
|
|
asph
l33t
Joined: 25 Aug 2003
Posts: 741
Location: Barcelona, Spain
|
| Posted: Fri Jul 23, 2004 4:58 pm Post subject: |
|
|
bueno, podría ampliarse mucho más hablando de prelink, hdparm, USE's, compilar binarios, modificar ebuilds para hacerlos más lights, etc etc.. a ver si algún dia me animo o lo voy añadiendo poco a poco
_________________
gentoo sex is updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; emerge --oneshot condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; emerge -C condom; make clean; sleep |
|
| Back to top |
|
|
L41n
Tux's lil' helper
Joined: 21 Jul 2004
Posts: 85
|
| Posted: Fri Jul 23, 2004 8:56 pm Post subject: |
|
|
Creo que todos lo estaremos esperando con impaciencia, muchas gracias de nuevo por tu trabajo
Sobre prelink, la mejor forma de llamarlo sería: prelink -Ramf, ¿no?, de esta forma es como llevo llamandolo mucho tiempo y siempre ha sido muy eficaz (más información en `man prelink').
Otra pregunta que quería hacerte. ¿A qué te refieres con ebuilds mas lights?, ¿podría ser posible incluso editarlo para optimizar alguna función en especial y hacerlo menos tardío a la hora de la compilación?, no estaría nada mal poder conseguir esto
_________________
Emerge your liberty. |
|
| Back to top |
|
|
asph
l33t
Joined: 25 Aug 2003
Posts: 741
Location: Barcelona, Spain
|
| Posted: Sat Jul 24, 2004 7:41 am Post subject: |
|
|
bueno, me referia a editar los ebuilds para quitar componentes o dependencias que jamas vamos a usar.. por ejemplo el ebuild del kde-base, puedes modificarlo para quitar kate, khelpcenter, kpager, konsole, etc etc.. ya que si usamos otros programas en su lugar no los necesitamos para nada. esto se puede aplicar tambien a otros paquetes, aunque hay que ir con cuidado xD
_________________
gentoo sex is updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; emerge --oneshot condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; emerge -C condom; make clean; sleep |
|
| Back to top |
|
|
asph
l33t
Joined: 25 Aug 2003
Posts: 741
Location: Barcelona, Spain
|
| Posted: Sun Aug 08, 2004 11:02 pm Post subject: |
|
|
alguien tiene experiencia con los procesadores centrino (pentium m) y las cflags? tengo entendido que es mejor usar pentium3 con algunos parametros antes que pentium4 (como sse2), pero el otro dia configuraba el portatil de un amigo y no estaba del todo seguro..
a ver si alguien ha estado haciendo pruebas o ha leido algo sobre el tema
salu2
_________________
gentoo sex is updatedb; locate; talk; date; cd; strip; look; touch; finger; unzip; uptime; gawk; head; emerge --oneshot condom; mount; fsck; gasp; more; yes; yes; yes; more; umount; emerge -C condom; make clean; sleep |
|
| Back to top |
|
|
Franco Gotusso
Guru
Joined: 15 Apr 2004
Posts: 313
Location: Benidorm, Alicante, Spain
|
| Posted: Mon Aug 09, 2004 10:53 am Post subject: |
|
|
Yo tengo todo el sistema compilado con estas cflags y va de maravilla.
| Code: | | CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer -ftracer -fforce-addr -frerun-cse-after-loop -maccumulate-outgoing-args -ffast-math" |
Last edited by Franco Gotusso on Sun Apr 03, 2005 7:13 pm; edited 2 times in total |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Spanish
