# [SOFTWARE]Como optimizo Gentoo para que funcione mas rapido?

## Pablo S. Barrera

Buenas!

Mis disculpas por molestar

Tengo mi Gentoo hace casi 4 añios, actualizado semanalmente aproximadamente. Note que con el tiempo comenzo a perder velocidad, ya no es el que era antes.

Se que existen varias guias pero he utilizado algunas y me trajeron problemas, digamos que no confio del todo en esas guias.

Puedo pedir den ideas? 

Me gustaria tener mas velocidad y mas espacio en / tambien.

Mi hard: Athlon 2000+, 1 gb ram, Nvidia 5200, DVD-RW, 2 HD, 1 de 40 GB y otro de 120 GB. el de 40 GB tiene boot, /  y home, el de 120 gb datos. Particiones ext2,3 y reiserfs. No tengo Swap.

GraciasLast edited by Pablo S. Barrera on Sat May 24, 2008 3:38 am; edited 1 time in total

----------

## Inodoro_Pereyra

Sabés que a mi me pasó lo mismo? Recientemente he reinstalado un viejo athlon64 (y que me está dando pelea en otro post) que ya tenía dos años de pura paliza, fué mi banco de prueba, en donde me inicié con Gentoo y le echaba la culpa de la perdida de rendimiento a que probé las mil y una en la pobre maquinita.

Para mas velocidad, antes que nada, habilitá aun que sea 512Mb de espacio para swap (A menos que tengas la swappiness en cero). 1Gb de memoria ram ya no es lo que era por mas que esto sea Gentoo. Nunca sabés cuando vas a necesitar volcar algo de información a la swap.

El otro consejo que te puedo dar, o que al menos a mi me dió resultado: Arrancá con un WM virgen. Move tu directorio de configuración a otra ubicación y volvé a empezar desde cero, como viene de serie el que sea que uses... Una lavada de cara, un baldazo de agua fría, vas a ver  :Very Happy: 

Después de reinstalado mi Gentoo en este athlon que comentaba mas arriba, como tengo /home en otra partición que no se modificó, fué reinstalar xfce4 en mi caso y tuve todo, tal cual lo tenía antes. El mismo fondo de escritorio, los mismos gadgets, el mismo conky... No notaba ninguna diferencia en rendimiento hasta que moví el .config de xfce4 y reinicié X... Sin tantas cosas que le fuí agregando con el tiempo, la pc vuela.

Para mas espacio en disco, achicar el tamaño de bloque. Reparticionar para poder alojar todos los directorios que contengan muchos archivos de texto (como /usr/portage) en particiones separadas. Borrar distfiles cada tanto. Instalar logrotate o deshacerse de los logs antiguos. Vaciar /var/tmp y /tmp al reiniciar...

Algo que siempre me ha quedado en el tintero es probar hdparm como servicio. Alguien puede comentar aprovechando este hilo, si se gana algo de rendimiento con esto? 

Salud!

*** EDITO ***

Vuelvo al foro 5 minutos después y me encuentro con la respuesta de stolz, este hilo va a ser de los que se guardan en favoritos. No conocía localepurge y no se me había ocurrido /tmp sin journaling, que tiene mucha lógica.

*** EDITO 2 ***

Pasate apenas puedas a baselayout2 / OpenRC, vas a ganar algunos segundos al encender y apagar la pc.

----------

## Stolz

Pablo, nunca pidas disculpas por preguntar en le foro   :Smile: 

Hay tantas formas de hacer que Gentoo funcione bien que no se ni por donde empezar. Un sistema 'sano', es decir, bien mantenido, siempre irá todo lo rápido que se puede. Si has notado descenso en el rendimiento con los mismos componentes hardware y casi la misma configuración del kernel seguramente sea porque tu sistema de ficheros está muy fragmentado. Como no concretes algo más en qué notas a tu sistema lento lo único que se puede hacer es dar consejos generales:

-Un buen esquema de particiones. Dividir el disco en particiones del tamaño adecuado tiene muchas ventajas, desde evitar al fragmentación, prevención de desastres y ligero aumento del rendimiento en algunos casos,...)

-Los sistemas de ficheros adecuados en cada partición. (¿realmente necesitas journaling en /tmp?)

-Mantenimiento regular (--prune,revdep-rebild, emerger dependencias con --oneshot, localepurge,logrotate,glsa-check ...)

-Kernel con solo lo que necesitas y las opciones típicas (DMA, preemt,...)

-Iniciar solo los servicios que realmente usas

-USEs adecuadas, eliminando las que no necesites,...

-CFLAGs con sentido común

y se podría continuar mucho

----------

## johpunk

yo ultimamente e echo lo siguiente en consola para ganar espacio en el hd

 *Quote:*   

>  rm -r /var/tmp/portage/*
> 
> rm -r /usr/portage/distfiles/*

 

con eso puedes recuperar un espacio considerable en tu disco  :Wink:  saludos!

----------

## Coghan

 *johpunk wrote:*   

> rm -r /usr/portage/distfiles/*
> 
> con eso puedes recuperar un espacio considerable en tu disco  saludos!

 

Es cierto que liberas mucho espacio pero malgastarás un estupendo ancho de banda de las réplicas de gentoo, cuando necesites reinstalar algún paquete se descargará nuevamente. Para la labor de limpiar los distfiles se recomienda el uso del comando 

```
eclean-dist -d
```

 con esto eliminas las fuentes que ya no necesitarás.

----------

## Pablo S. Barrera

Tengo para trabajar el fin de semana.

Hdparm como servicio? Una vuelta lo use y a los dias perdi un HD, no se me da un poco de miedo. Tal vez nada que ver una cosa con otra pero bue..

Voy a empezar a realizar cambios.

----------

## i92guboj

Este tipo de hilos siempre me hacen sonreír, no puedo evitarlo   :Laughing: 

 *Pablo S. Barrera wrote:*   

> Buenas!
> 
> Mis disculpas por molestar
> 
> Tengo mi Gentoo hace casi 4 añios, actualizado semanalmente aproximadamente. Note que con el tiempo comenzo a perder velocidad, ya no es el que era antes.
> ...

 

El problema es evidente: estás usando un SO de hoy, en la misma máquina que antes usabas un SO de hace cuatro años. Tan simple como eso.

Probablemente, si cojas una distro de hace 4 años, y la instalas, la verás volar. Exáctamente igual que hace 4 años.

 *Quote:*   

> 
> 
> Se que existen varias guias pero he utilizado algunas y me trajeron problemas, digamos que no confio del todo en esas guias.
> 
> 

 

Todas esas guías con supuestas optimizaciones eran problemáticas y desaconsejables incluso cuando estaban actualizadas. Más aún hoy que no lo están, y encima habiendo cambiado a baselayout 2...

 *Quote:*   

> 
> 
> Puedo pedir den ideas? 
> 
> Me gustaria tener mas velocidad y mas espacio en / tambien.
> ...

 

No existe ninguna magia. Los GUIs son más pesados cada vez y más grandes. Como alguien dice por ahí arriba, 1gb ya no es lo que era. Yo comenzaría poniendo más ram en tu equipo y dando algo de swap (digan lo que digan, linux sigue andando mejor si tiene un poco de swap, aunque no lo use para casi nada). Tus discos duros tienen pinta de ser lentos para las especificaciones de hoy día, eso unido al incremente natural del tamaño de los programas con el tiempo, también habrá contribuído. Por lo demás, tu máquina es bastante capaz de ejecutar Gentoo, pero por supuesto: iría mejor con el Gentoo de hace 4 años  :Razz: 

Saludos.

----------

## the incredible hurd

 *Pablo S. Barrera wrote:*   

> Hdparm como servicio? Una vuelta lo use y a los dias perdi un HD, no se me da un poco de miedo. Tal vez nada que ver una cosa con otra pero bue..

 

hdparm incrementa el rendimiento en discos IDE de forma considerable. Sentido común es lo único necesario.

imagino que sdparm también realizará su cometido en discos SCSI.

Por el momento sólo unos consejos:

```

# hdparm -I /dev/hda

Capabilities:

        LBA, IORDY(can be disabled)

        Standby timer values: spec'd by Standard, no device specific minimum

        R/W multiple sector transfer: Max = 16  Current = 16

        Recommended acoustic management value: 208, current value: 0

        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4 

        Cycle time: no flow control=240ns  IORDY flow control=120ns

Commands/features:

   Enabled   Supported:

      *   SMART feature set

          Security Mode feature set

      *   Power Management feature set

      *   Write cache

      *   Look-ahead

      *   Host Protected Area feature set

      *   WRITE_BUFFER command

      *   READ_BUFFER command

      *   DOWNLOAD_MICROCODE

          SET_MAX security extension

      *   48-bit Address feature set

      *   Device Configuration Overlay feature set

      *   Mandatory FLUSH_CACHE

      *   FLUSH_CACHE_EXT

      *   SMART error logging

      *   SMART self-test

      *   General Purpose Logging feature set

```

R/W multiple sector transfer: Max = 16  Current = 16

(parámetro hdparm -m16)

*	Look-ahead

(parámetro hdparm -A1)

*	Mandatory FLUSH_CACHE

*	FLUSH_CACHE_EXT

(parámetro hdparm -f) Para más seguridad:

```
dmesg | grep flushes
```

 y habilitar la -f sólo en los que ponga supported

(parámetro -c):

Es peligrosa y puede corromper los datos del disco, pero jamás puede dañar un disco duro. Por norma general, si la BIOS permite habilitar las transferencias de 32bits para una unidad, el valor más seguro es -c3, el que mayor rendimiento proporciona es -c1 y para deshabilitarla, como están las unidades por defecto con transferencias de 16bits, es con -c0. Ten en cuenta que las unidades IDE todas transmiten datos a 16bits, es el chipset de la placa el que se encarga de apilar los datos en bloques de 32bits. Yo si la BIOS me permite activarlo y lo activo, siempre indico -c1; haz todas las pruebas necesarias después de haber hecho copias de seguridad y de haberte asegurado que las copias de seguridad son absolutamente fiables.

(parámetro -d)

Es imprescindible para indicarle que use DMA, aunque el kernel lo usa por defecto si lo detecta y lo tienes habilitado para tu chipset. La prueba para asegurarte de si tienes el soporte DMA correcto, es un simple hdparm -d1 /dev/hda. Esta opción se complementa con...

DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

(parámetro -X)

cuanto más a la derecha mejor, -Xudma5 sería el elegido en este caso.

(parámetro -u)

Peligrosa, puede dañar todos los datos de la unidad, pero no el disco... desenmascara las demás interrupciones mientras procesa una del disco duro. aumenta la rapidez de respuesta de linux, pero léete el manual de hdparm y no hagas pruebas sin copias de seguridad fiables de todos tus datos.

*	Write cache

(parámetro -W)

Si la unidad tiene caché de escrituras es conveniente usarlo con -W1. Pero recomiendo prudencia en unidades que no soporten el parámetro -f que ya he explicado. Aunque yo lo usé en una de ellas y nunca tuve pérdidas de datos, aunque quizá tuve mucha suerte también.

Para más datos el man de hdparm y [HOWTO] hdparm

 *i92guboj wrote:*   

> pero por supuesto: iría mejor con el Gentoo de hace 4 años

 Eso es como decir que un pentium3 iría mejor con un kernel 2.4, un pentium2 con un 2.0 y un 486 con cualquiera de los 1.x; lo cual es una estupidez, dado que estás ignorando todas las mejoras introducidas en el kernel, casi todas ellas introducidas precisamente para obtener más rendimiento. La revolución USB de 1998, el cambio de VM renunciando el propio Linus al suyo, y cientos de cambios realmente revolucionarios similares a estos, como la incorporación del soporte PAE, por poner un par de ejemplos fueron cambios realmente importantes que mejoraron Linux exponencialmente. Tu afirmación me parece símplemente errónea, con todos mis respetos. Aunque no puedo demostrarlo. Si hay algún voluntario que no haya actualizado su Gentoo desde hace 4 años que nos cuente la experiencia, no sin antes hacer copias de seguridad para restaurar su Gentoo que según i92guboj irá más rápida que la actualizada.

----------

## i92guboj

 *the incredible hurd wrote:*   

> 
> 
>  *i92guboj wrote:*   pero por supuesto: iría mejor con el Gentoo de hace 4 años Eso es como decir que un pentium3 iría mejor con un kernel 2.4, un pentium2 con un 2.0 y un 486 con cualquiera de los 1.x; lo cual es una estupidez

 

Suavizemos el tono un poco.

En primer lugar, estás poniendo en mi boca palabras que no son mías. Estamos hablando de una distro completa, no de un kernel, son dos cosas muy distintas. Estarás de acuerdo conmigo en que un escritorio de hace 4 años requiere mucha menos memoria que cualquier de los de hoy día. El kernel progresa día a día, y por norma general es más rápido a no ser que estés realmente limitado en ram (y en dichos casos, tampoco es una estupidez afirmar que un 2.4 puede ser no solo mejor, sino además la única alternativa).

Coincido contigo en que un kernel 2.6 es lo mejor sea cual sea tu hardware si estámos hablando de un escritorio, pero no es de eso de lo que se estaba hablando. Y aún si fuera así, un simple "disiento" habría sido preferible al ataque directo que has realizado. A mi me importa un pimiento, pero si vas con esa actitud de "esto es una estupidez" vas a tener más de un problema de comunicación.

Dicho ésto, todo depende del sofware que se elija en última instancia, aunque la misma distribución te fuerza a actualizar hasta cierto punto.

Saludos y relax para todos.   :Wink: 

EDIT: En cuanto a toda la parafernaria de hdparm, hoy en día es prácticamente innecesario el uso de hdparm excepto para testear la velocidad de los discos IDE. Si estás usando el driver correcto para tu chipset, todo se ajusta de forma automática. Puedes comprobar la información de hdparm si quieres, pero dudo mucho que tengas que cambiar nada, y aún más que vayas a ganar rendimiento de ello. Por supuesto, ésto es otra cosa que jamás se puede asegurar al 100% y hay que mirarlo caso por caso. Como todo.Last edited by i92guboj on Fri May 23, 2008 4:52 pm; edited 1 time in total

----------

## the incredible hurd

 *Quote:*   

> Eso es como decir que un pentium3 iría mejor con un kernel 2.4, un pentium2 con un 2.0 y un 486 con cualquiera de los 1.x; lo cual es una estupidez

 

 *i92guboj wrote:*   

> Y aún si fuera así, un simple "disiento" habría sido preferible al ataque directo que has realizado.

 

Date cuenta de que se trata de una expresión que hace referencia a sí misma y aunque la comparo a lo que tú has expresado; la estupidez la estoy diciendo yo mismo en una frase auto-referencial. Leyéndola de forma rápida quizá también me la hubiese tomado de igual modo que tú. Lo lamento, trataré de medir mis palabras.

Pablo S. Barrera; olvidé decir que además, en /etc/conf.d/local.start tengo un parámetro blockdev para cada unidad.

/sbin/blockdev --setfra 16384 /dev/hda

En este caso ajusto el Read-Ahead a 16384, porque esa unidad tiene un caché de 8Mb, como blockdev sólo entiende bloques de 512bytes, una medida adecuada me parece ajustarlo al tamaño de la caché.

IDEM: Saludos y relax para todos.   :Wink: 

----------

## Pablo S. Barrera

Los hermanos sean unidos por que esa es la ley primera y si entre ellos se pelean se los deboran los de afuera!.

Martin Fierro, un libro Argentino lleno de anecdotas del gran gaucho argentino. Como una biblia pero de todos los dias.

Gente voy a probar un par de cosas y les cuento. Sigan sumando ideas si quieren que viene bien para todos.

Por mas agradecido de esta comunidad como tambien de las otras que dan vueltas.

----------

## Pablo S. Barrera

Mantenimiento regular.

Empece con esto: 

-Mantenimiento regular (--prune,revdep-rebild, emerger dependencias con --oneshot, localepurge,logrotate,glsa-check ...) 

Tire el --prune ahora el revdep-rebuild.

Emerger las dependencias con --oneshot siginifica correr este comando? "emerge -D --oneshot world"?

INODORO: Seria bueno me decis recompilar KDE (en mi caso) pero desde cero. Como hago eso? No tengo muchas ganas de hacerlo, por que me seria algo asi como recompilar todo el sistema casi, por una cuestion de tiempos. De todos modos.. como lo podria hacer? Tengo que compilar luego todas las aplicaciones?

Gracias.Last edited by Pablo S. Barrera on Sat May 24, 2008 12:29 am; edited 1 time in total

----------

## Stolz

 *Pablo S. Barrera wrote:*   

> Emerger las dependencias con --oneshot siginifica correr este comando? "emerge -D --oneshot world"?

 

No. Significa que cada vez que instales un programa que sea una dependeia de otro (es decir, que no necesites directamente), lo hagas añadiendo el parámetro --oneshot .

Cuando instalas un programa con emerge éste queda guardado en el archivo "world" (/var/lib/portage/world), pero no sus dependencias. El archivo world se supone que debe contener solo los archivos que nosotros realmente queremos. Si siempre emerges programas que necesitas y nuca instalas directamente en la línea de comandos dependencias, nunca es necesario usar elparámetro --oneshot. El problema es que todos sabemos que no siempre es así. Muchas veces nos falla la compilación de un paquete o queremos cambiar algunas USE y tras hacerlo reinstalamos a mano. Veamos el siguiente escenario de ejemplo:

Supongamos que queremos instalar mplayer con soporte para theora. Una vez activada la USE theora harías algo así:

```
# emerge mplayer
```

Esto no solo instala mplayer sino unas cuantas dependencias en función de tus USE, entre ellas media-libs/libtheora. Si en algún momento durante o después de la instalación, decides que quieres activar la USE encode de media-libs/libtheora, tras añadirla en make.conf o pakage.use seguramente harías algo así:

```
# emerge -uaDN world
```

o

```
# emerge -uN media-libs/libtheora
```

En el primer caso no ocurre nada malo, pero en el segundo, estás usando emerge para instalar directamente un paquete que es una dependencia. Al indicar el nombre como un argumento de emerge, este paquete queda también añadido al fichero world. Si realizas esta práctica frecuentemente, al final el fichero world queda lleno de cosas que no necesitas directamente.

¿por qué es malo tener el fichero world lleno de cosas que no necesitas directamente? Porque cada vez que haces un 

```
# emerge --opciones_varias world
```

 se lee dicho fichero y se calcula el árbol de dependencias de todos los paquetes que contiene, haciendo que el cálculo de las aplicaciones a actualizar sea muy lento. Si una dependencia de un paquete realmente necesita actualizarse será el ebuild el encargado en forzar dicha actualización, no es necesario calcular siempre el árbol completo. Si por el motivo que sea quieres que se compruebe también las posibles actualizaciones de las dependencias no directas siempre podrás usar el parámetro -D de emerge.

Si cada vez que instales una dependencia añades el parámetro --oneshot (abreviado como -1), el paquete o paquetes indicados tras los parámetros de emerge no serán añadidos al fichero world.

Sabiendo esto, haz una limpieza de /var/lib/portage/world y deja solo los paquetes que realmente necesitas.

----------

## Pablo S. Barrera

Mil gracias.

El tema es que siempre recompilo todo asi: emerge -uND world (aunque no haga cambio en los USE, es como una costumbre)

Ya retoque el fichero mencionado y borre un par de cosas. 

INODORO te puse una pregunta mas arriba por si se pierde entre todo.

----------

## Inodoro_Pereyra

No maestro, no me refería a recompilar KDE si no a deshacerte de ~/.kde... No lo borres, pero movelo o renombralo y reiniciá KDE. 

Me refería a como se va poniendo "pesado" el entorno gráfico en la medida en que se le empiezan a agregar widgets, gadgets, screenlets, sonidos, animaciones, iconos, fondos de pantalla, transparencias, efectos, etc... No parece pero la suma de todo se hace sentir y te das cuenta cuando volvés a empezar de cero.

Salud!

----------

