El lun, 23-01-2012 a las 10:24 +0100, Angel Docampo escribió: > No era mi intención compararlo como si fueran smartphones, hablo según > lo experimentado. Es por todos sabido que el talón de aquiles de > GlusterFS son los ficheros pequeños. Tanto que en todos los lados > desaconsejan que los ficheros de los servidores web se residan en un > glustefs.
En realidad la limitacion de los ficheros pequeños no es algo exclusivo de Gluster, sino de la implementacion de tcp. En otros sistemas de almacenamiento que se basan en tcp y no contemplan serializacion alguna, estas en las mismas y las velocidades son bajas, pero por el overhead normal de copiar 200000 ficheros de 2k y los tiempos que esto implica Cuando pruebas libib, te das cuenta que tcp para estas cosas , es el mal. > Es muy difícil conseguir una velocidad óptima de transferencia en un > entorno con todo tipo de archivos. Se pueden configurar muchos > parámetros, y probar con los FS sobre los que los volumenes de gluster > residen, así como el protocolo de red para transferirlos, pero toma > mucho tiempo dar con el setting adecuado. > > En casa de clientes, a menudo me encuentro montando volumenes con > bricks formateados en reiserfs para ficheros pequeños, o ext3 para > ficheros grandes. Últimamente he hecho pruebas con btrfs (con muy > gratos resultados, por cierto) para entornos mixtos. > > En el caso de MySQL (no he probado con otras DB) éste maneja su propio > locking y caching con lo que suele dar problemas con el locking y > caching de glusterfs. Creo que por eso no recomiendan usar la > replicación a través de gluster. Slds! -- _______________________________________________ Comandob mailing list Comandob@badopi.org http://lists.badopi.org/mailman/listinfo/comandob
