Linux Mejor filesystem para....

Notable el experimento. Si llego a tener máquina haré un benchmark de bases de datos sobre distintos filesystems.

unreal4u dijo:

Por alguna razón, CentOS 7 instala XFS como FS predeterminado en vez de ext4. Sin embargo, es sabido que XFS no trabaja de forma muy rápida cuando son muchos archivos chicos, así que por esa razón me quería cambiar.

Haz clic para expandir...

eso era antes, ese problema ya esta solucionado

Ya cabros, follow-up:

A medida que ha ido incrementando la cantidad de archivos, tb se ha puesto más lento btrFS. No es tanto pero de todas formas no deja de ser (iowait ocupa cerca de un 7% en vez de un 3% en los gráficos ahora). Mañana si me queda tiempo (difícil) reviso cuántos archivos son en la actualidad, pero así como vamos, estimo en unos 5.5 millones, ya que por el momento el disco está en un 30% lleno, y estaba en 10% cuando eran ~1.8 millones de archivos.

Por lo demás, ahora ajusté el logrotate de jenkins a semanal y además le bajé el loglevel de INFO a SEVERE, ya que al parecer hace un check de archivos cada vez que reinicia, lo cual toma cerca de 4 horas. Acabo de implementar esos cambios así que mañana veo si surtieron efecto.

Saludos.

Up movil

Último follow-up:

Al final el iowait alto era por un disco malo en el RAID del host. Esta es la situación actual:


Así que... caso cerrado! Ahora por fin anda bien sin problema alguno.

El tema del respaldo todavía no lo veo, pero por lo visto simplemente enchufaremos un disco USB y lo formatearemos con btrFS tb, creo que pondremos correos y jenkins ahí.

Saludos.

Mmmmm , probaré un Server de correo con maildir para ver cómo anda

Cosme dijo:

Mmmmm , probaré un Server de correo con maildir para ver cómo anda

Haz clic para expandir...

recuerda que ahí la prueba de fuego seria tener unos cuantos usuarios sincronizando una cuenta IMAP de varios gigas, generalmente hasta con raid5 suelen sufrir cuando usan ext3

miguelwill dijo:

recuerda que ahí la prueba de fuego seria tener unos cuantos usuarios sincronizando una cuenta IMAP de varios gigas, generalmente hasta con raid5 suelen sufrir cuando usan ext3

Haz clic para expandir...

el raid 5 es el raid más lento que existe, es mucho más lento que un disco solo, no es nada recomendable cuando hay uso intensivo de discos.

lo se, sorry si sonó como que era lo mas rápido, solo que me acorde de un caso en que el server se sobrecargaba con varias sincronizaciones IMAP, el cual es poco lo que podemos cambiar por ahora

descartando un raid0, prefieres un raid5 o raid 0+1 ??

raid 5 no lo paso ni bañado en chocolate. raid 0+1 (o raid 10, que es en la práctica la mesma cosa) es lo mejorcito.

yakko dijo:

raid 5 no lo paso ni bañado en chocolate. raid 0+1 (o raid 10, que es en la práctica la mesma cosa) es lo mejorcito.

Haz clic para expandir...

vale, lástima que tenga el castigo de tamaño a la mitad, sino lo usaría mas seguido (siempre prefieren tener el intermedio del raid5 por el tamaño )

RAID 5 vale pico y punto, no lo usen.

Recuperar un arreglo de un disco malo es un cacho, es muy lento de re armar y balancear la data en los discos, es lento de escritura, no es rápido para leer, por todos lados es una mierda.

yakko dijo:

RAID 5 vale pico y punto, no lo usen.

Recuperar un arreglo de un disco malo es un cacho, es muy lento de re armar y balancear la data en los discos, es lento de escritura, no es rápido para leer, por todos lados es una mierda.

Haz clic para expandir...

RAID5 es el raid del cagao y punto.

Con lo que valen los discos ahora, nada justifica no armar un raid10 de 4 + spare

unreal4u dijo:

Último follow-up:

Al final el iowait alto era por un disco malo en el RAID del host. Esta es la situación actual:
[url]http://i.imgur.com/Bwqlicml.jpg[/url]

Así que... caso cerrado! Ahora por fin anda bien sin problema alguno.

El tema del respaldo todavía no lo veo, pero por lo visto simplemente enchufaremos un disco USB y lo formatearemos con btrFS tb, creo que pondremos correos y jenkins ahí.

Saludos.

Haz clic para expandir...

Se ve que tienes mucho tiempo de CPU libre, por lo que para respaldar podrías probar una herramienta de compresión, idealmente tar + rar|nanozip|xz (cualquiera de esos tres), y subirlo a "la nube", Dropbox, Google Drive u otra solución de almacenamiento en línea. Lo del disco USB lo veo poco seguro, sirve como para cumplir, pero no me fiaría únicamente de él.

A servicios externos nica, mucha información confidencial. Por el otro lado, discos USB son baratos, viene un disco duro adentro así que no le veo mayor diferencia y si se echa a perder, bueno, se compra otro, lo que voi a respaldar acá no es de vida o muerte tampoco, sólo sirve como archivo. Si es que lo necesitamos alguna vez, va a ser para consultas muy específicas, a lo sumo el desde cuándo ocurre alguna condición, lo cual tb se puede ver en el código fuente de la aplicación (blame).
Correos tenemos en principio 3 años en IMAP, es muy raro que se quieran ver correos de más de 3 años atrás. Tampoco sería la graaaan pérdida si se echa a perder el respaldo.

En compresión te faltó lzop, es uno de los más rápidos. Lástima que no viene pre-instalado, pero AFAIK sí está en los repos.
lzop file compressor (oberhumer.com OpenSource)

Saludos.

unreal4u dijo:

A servicios externos nica, mucha información confidencial. Por el otro lado, discos USB son baratos, viene un disco duro adentro así que no le veo mayor diferencia y si se echa a perder, bueno, se compra otro, lo que voi a respaldar acá no es de vida o muerte tampoco, sólo sirve como archivo. Si es que lo necesitamos alguna vez, va a ser para consultas muy específicas, a lo sumo el desde cuándo ocurre alguna condición, lo cual tb se puede ver en el código fuente de la aplicación (blame).
Correos tenemos en principio 3 años en IMAP, es muy raro que se quieran ver correos de más de 3 años atrás. Tampoco sería la graaaan pérdida si se echa a perder el respaldo.

En compresión te faltó lzop, es uno de los más rápidos. Lástima que no viene pre-instalado, pero AFAIK sí está en los repos.
lzop file compressor (oberhumer.com OpenSource)

Saludos.

Haz clic para expandir...

p7zip

Otra historia de éxito para btrFS!

Problema: necesitamos un año de datos detallados en Munin. Normalmente Munin lo que hace es después de 2 días empieza a comprimir datos haciendo que los gráficos detallados se vean como el hoyo, nada mejor que una imagen que dice más que mil palabras: la primera imagen es un Munin común y corriente, con configuración predeterminada:


Y el segundo es la misma fecha, la misma máquina, los mismos datos, pero ahora con gráficos manteniendo historial de un año (en realidad 400 días pero es casi lo mismo):


Lo único "malo" es que descubrimos que si queremos tener hartos datos en Munin, la escritura en disco tb se incrementa... mucho (El disco constantemente con 50% de escritura)! Así que como ya habíamos cambiado una máquina exitosamente a btrFS sin que hasta hoy en día haya dado problema alguno, decidimos lanzarnos a la aventura con esta nueva máquina.

El resultado? Bajamos de un ~50% de uso constante de disco a un .... 0.50%!!! Arriba está el disco formateado con XFS y abajo el disco formateado con btrFS:


Justo dp de la migración hay un pequeño pique ya que Munin tenía que ponerse al día (son unas 12 máquinas con muchísimos plugins, muchas escritas por nosotros), pero de ahí en adelante anduvo más relajado que wn urgido porque se viene marzo.

btrFS FTW!

Saludos.

Pense que era el unico que usaba munin

BTRFS y punto, deja Obsoleto Todo lo conocido hasta los Raid.