[devotee]

No obstante, el journal sigue haciendo de las suyas y escribiendo mogollón en el disco, lo cuál no ocurre en un sistema ext3.

¿Has probado a cambiar el tipo de journaling a writeback y subir el intervalo de escrituras (commit)? Yo lo tengo así:

/: noatime,data=writeback,barrier=0,errors=remount-ro,commit=1800
/boot: noatime,data=writeback,barrier=0,errors=remount-ro,commit=3600
/home: noatime,data=writeback,barrier=0,errors=remount-ro,commit=1200

La opción "barrier=0" no es lo más recomendable, pero puedes probar a ver si supone un cambio drástico de rendimiento.

Si usas writeback como modo de journaling, también puedes añadir "nobh" a las opciones de montaje para ganar algo más de rendimiento. De todas formas, lo más "gordo" se consigue con noatime and data=writeback (y ajustando el intervalo del commit).

[tecneca]

Dejame adivinar: le has quitado el accounting con noatimes.

En varios servidores esto me dio muchos quebraderos de cabeza.

Bingo! Iban por ahí los tiros! Cambié el tipo a 'noatimes' y el rendimiento ha subido bastante. No obstante, el journal sigue haciendo de las suyas y escribiendo mogollón en el disco, lo cuál no ocurre en un sistema ext3.

La solución pasa por formatear el disco, pero claro, al ser un server en producción, no es una opción sencilla...

[bz2]

Para averigurarlo miré el consumo de cpu (el user, el idle, y la clave estaba en el iowait). Tras comprobar ésto, instalé la utilidad iotop, y vi que el sistema estaba escribiendo constantemente en el journal del disco. Al cambiar el tipo de montaje, ésto se ha reducido una barbaridad, y los backups ahora van como un tiro.

Dejame adivinar: le has quitado el accounting con noatimes.

En varios servidores esto me dio muchos quebraderos de cabeza.

[tecneca]

No sé si puede servirte de algo, pero tengo un nuevo server (en otra empresa, claro ) para virtualizaciones Proxmox, y a la hora de formatear, elegí ext4 en lugar de ext3, y con "defaults" como opciones de montaje, y no te puedes ni imaginar cómo bajó el rendimiento con respecto a otros servidores, y eso que la máquina es muy superior a las anteriores.

He tenido que cambiar el tipo de montaje (para no formatear particiones, claro), y ahora en rendimiento ya es bastante más correcto.

Para averigurarlo miré el consumo de cpu (el user, el idle, y la clave estaba en el iowait). Tras comprobar ésto, instalé la utilidad iotop, y vi que el sistema estaba escribiendo constantemente en el journal del disco. Al cambiar el tipo de montaje, ésto se ha reducido una barbaridad, y los backups ahora van como un tiro.

Igual no tiene mucho que ver, pero vamos, que estamos hablando de sistemas bastante complejos (hipervisores y paravirtualización), así que antes de pensar que el disco es una castaña, te recomiendo que hagas algunas averiguaciones sobre el propio rendimiento del sistema (que no del hardware...).

Un saludo

[tfwfactory]

Puedes mirar que tipo de discos tienes y sus características son SATA 2 o 3 , etc , del tema de los discos se ha hablado mucho aqui en el foro y se han detectado muchos fallos incluso de discos sólidos , saludos

[jfabaf]

Hola,

tengo un servidor dedicado SP BestOF 2011 con VMWare ESXi 4.1.
El problema que tengo es que intento hacer un backup de un disco de una máquina virtual con "/sbin/vmkfstools" y para copiar un disco duro de 150 GB se ha tirado 8 días.
Los backups los hago desde un datastore a otro, en este caso desde el datastore1 al datastore2, ambos de 2 TB, y el datastore2 está casi vacío.

He reiniciado pero no se ha arreglado nada, sigue igual.
Las máquinas virtuales no fallan y van rápidas, no entiendo por qué tarda tanto.

¿Hay alguna forma de saber qué está pasando?

Gracias.