Hola. Tengo instalado el OpenSuSE 10.0 en dos máquinas HP Proliant, con 2 Gb de RAM y 150 Gb de HD RAID5 con dos CPU Intel(R) Xeon(TM) CPU 2.40GHz El kernel es Linux version 2.6.13-15.8-smp (geeko@buildhost) (gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)) #1 SMP En cualquiera de esta máquinas, la carga sube una barbaridad, al tratar con copiar de seguridad. Ejemplo, al hacer un tar xvzf backup.tar.gz de un fichero de 2.8 Gb, la carga de CPU sube a 36 ¡! Y el servidor se queda frito durante unos segundos, ni se puede acceder por ssh en ese tiempo. Esta subida de carga es muy rápida, igualmente como la bajada de carga, pero hay un intervalo que se queda tonta la máquina. La carga normal de la máquina va de 1 a 2, normalmente Alguna sugerencia para hacer comprobaciones del porqué de estas lentitudes de acceso a disco ¿? Gracias
Hola :) El Miércoles, 26 de Abril de 2006 13:40, Paco Martinez escribió:
Hola.
Tengo instalado el OpenSuSE 10.0 en dos m�quinas HP Proliant, con 2 Gb de RAM y 150 Gb de HD RAID5 con dos CPU Intel(R) Xeon(TM) CPU 2.40GHz
El kernel es �Linux version 2.6.13-15.8-smp (geeko@buildhost) (gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)) #1 SMP�
En cualquiera de esta m�quinas, la carga sube una barbaridad, al tratar con copiar de seguridad.
Ejemplo, al hacer un �tar xvzf backup.tar.gz� de un fichero de 2.8 Gb, la carga de CPU sube a 36 �! Y el servidor se queda frito durante unos segundos, ni se puede acceder por ssh en ese tiempo.
Instálate saidar o gkrellm que te da unas medidas muy buenas por separado de CPU, disco duro, red, ... Así puedes ver dónde tienes el cuello de botella. Personalmente creo que es el disco duro el cuello de botella.
Esta subida de carga es muy r�pida, igualmente como la bajada de carga, pero hay un intervalo que se queda tonta la m�quina.
La carga normal de la m�quina va de 1 a 2, normalmente
Alguna sugerencia para hacer comprobaciones del porqu� de estas lentitudes de acceso a disco �?
Lo primero: - ¿qué servicios tienes corriendo? X, servidores, ... - deshabilita esos servicios y haz la prueba de nuevo - instálate stress y prueba por separado CPU, disco, ... HTH Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-04-26 a las 13:55 +0200, Rafa Grimán escribió:
Instálate saidar o gkrellm que te da unas medidas muy buenas por separado de CPU, disco duro, red, ... Así puedes ver dónde tienes el cuello de botella.
Personalmente creo que es el disco duro el cuello de botella.
Hay una medida que no hace el gkrellm (que por cierto, no lo he visto en la 10.1) y que si hace el applet "System Monitor" del Gnome: IOwait. Una medida del tiempo que la CPU está esperando a entrada salida de datos, o sea, en espera por el disco. A veces observo que la CPU está al 5%, pero IOwait está a tope, y la máquina lentísima, no responde.
Alguna sugerencia para hacer comprobaciones del porqu[e9] de estas lentitudes de acceso a disco [bf]?
Por cierto, hay un ajuste por ahí según quieras la máquina para servidor o sobremesa. Afecta al tiempo de respuesta. De todas maneras que se quede lento con un tar de 2 gigas... me parece normal. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFET2hAtTMYHG2NR9URAp/NAJ9kft5Qoq1qBepM4MWyvQJGhQuV3ACfT7IK MFCijncuPpUZ24njBHYs7Ts= =7ETD -----END PGP SIGNATURE-----
Hola :) El Miércoles, 26 de Abril de 2006 14:31, Carlos E. R. escribió:
El 2006-04-26 a las 13:55 +0200, Rafa Grim�n escribi�:
Inst�late saidar o gkrellm que te da unas medidas muy buenas por separado de CPU, disco duro, red, ... As� puedes ver d�nde tienes el cuello de botella.
Personalmente creo que es el disco duro el cuello de botella.
Hay una medida que no hace el gkrellm (que por cierto, no lo he visto en la 10.1) y que si hace el applet "System Monitor" del Gnome: IOwait. Una medida del tiempo que la CPU est� esperando a entrada salida de datos, o sea, en espera por el disco. A veces observo que la CPU est� al 5%, pero IOwait est� a tope, y la m�quina lent�sima, no responde.
Esta medida está bien :) Es más, es un dato a tener muy en cuenta. Por ejemplo, esto es muy típico en redes GigE si no modificas el MTU. Por defecto el MTU está a 1500, el problema es que en redes GigE, si dejas este MTU, provocas que la CPU trabaje mucho porque tiene que solicitar una interrupción por paquete. En cambio si usas un MTU de 9000, disminuyes el número de interrupciones ya que disminuyes el número de paquetes que entran por la red. En el caso de los discos duros ocurre lo mismo, pero es más grave ya que hablamos de dispositivos mecánicos ... más latencia :(
Alguna sugerencia para hacer comprobaciones del porqu[e9] de estas lentitudes de acceso a disco [bf]?
Por cierto, hay un ajuste por ah� seg�n quieras la m�quina para servidor o sobremesa. Afecta al tiempo de respuesta.
Si, la opción "elevator=as|cfq|deadline|noop" Si no me equivoco, para escritorio recomiendan cfq, as para servidores de ficheros y deadline para BBDD. En todo caso la info está en: /usr/src/linux/Documentation/block/ si la memoria no me falla. HTH Rafa
De todas maneras que se quede lento con un tar de 2 gigas... me parece normal.
Sí, el acceso a disco siempre es lento. De todas maneras, influye si usa ficheros pequeños o grandes. Pero sí, es lento. Además, estaba comprimiendo ... HTH Rafa -- "Even paranoids have enemies." Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman
participants (3)
-
Carlos E. R.
-
Paco Martinez
-
Rafa Grimán