El 27/10/09, Rafa Griman escribió:
On Monday 26 October 2009 16:16:22 Camaleón wrote:
Activa jumbo frames en servidor y cliente. Comprueba que el switch soporta jumbo. Las ventajas de jumbo es que el MTU es de 9000 y sin ellos es de 1500. Es decir, hay que gestionar menor # de paquetes por lo que la CPU tiene que trabajar menos y mejoras el rendimiento.
En los switches no veo ninguna opción para activar los "jumbo frames" (el campo de velocidad está en "auto", las opciones son:
100m full, 100m half, 10mb full, 10mb half, auto, disable
Parece que el switch no es gigabit ethernet.
Juvar... que sí lo son >:-) Los puertos que están en "auto" se conectan a 1 GB (los que son enlaces de 1 GB.) y a 100 MB los que son enlaces a 100 MB. Lo que no veo por ningún lado es la configuración de los jumbo frames.
En cuanto a potencia de CPU. Gbit consume lo suyo (especialmente si no son jumbo frames) y recuerda que Samba lanza un proceso hijo por cada cliente conectado más el proceso padre -> mucha CPU y mucha RAM.
Bueno, aquí no creo que tenga problemas. Los servidores montan dos xeones físicos (4 núcleos), que aunque son antiguos (inicio del año 2.006) aún pueden llevar bien la carga de trabajo. Tienen 8 GB. de ram.
Va bien cargado ;)
¿Sólo tienes 1 t. red en el servidor? Dependiendo del # de clientes, puede ser interesante tener channel bonding. Teóricamente 1 cliente con 1 puerto Gbit te satura el 1 Gbit del servidor. Si quieres una red balanceada, necesitas el mismo número de puertos de entrada que de salida y que el backplane del switch lo soporte, de lo contrario tienes una interconexión de tipo blocking y el rendimiento no es el máximo (óptimo).
Tengo los dos adaptadores de red configurados en bonding (failover).
Failover es como tener 1 solo puerto, no vas a conseguir mejor rendimiento.
En este caso me interesa una configuración de seguridad más que de rendimiento. No se puede tener todo ¿o sí? O:-)
Luego el almacenamiento también influye. Si no tienes discos rápidos, ... El cuello de botella lo tienes allí.
Esto sí puede ser un pelín "handicap". Porque no sólo el volumen compartido está en raid5 (controladora raid) sino que los discos son sata 150 :-/
Mal rollo ...
Sí, eso sí :-( Y la controladora raid no es para tirar cohetes, que digamos :-((
Sinceramente, si no es una cosa desesperante, yo lo que cambiaría/miraría es lo de los jumbo. Pero recuerda que con que un equipo no lo soporte, se te va todo al garete.
En esta red las copias funcionan mucho mejor. El cableado gigabit se nota y los servidores que hay detrás, también :-)
Es que el hardware importa más de lo que la gente se piensa ... y más hoy en día que no se depura ;)
Sip :-)
En la red B tengo clientes suse y windows. Los windows mantienen el mismo esquema que la red A, pero las copias se eternizan (la red es 10/100 y el servidor donde tengo samba no es tan potente). Aquí los clientes suse usan mediante fish:// (gráfico) o ssh (línea de comandos) para transferir las copias en "tar.gz", muy sencillo.
Red lenta y servidor pequeñajo ... mal rollo :(
Por eso comentaba que samba es "lento".
Pero el que el hardware sea pequeño no es culpa de Samba ;)
Cierto :-P Pero es lo que hay en gran parte de las oficinas. Y en casa, pues peor :-(
Si se tiene una red bien puesta o un enlace directo (equipo a equipo) y son equipos medianamente potentes, pase. Pero no siempre es así y cuando tienes que hacer una copia de archivos grandes (imagen iso 4.7 GB o copias de seguridad), se nota :-(
Si a eso le añades la configuración de los usuarios y los permisos para los recursos en samba, pues se hace un poco "pesado".
Sip.
Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org