Hola :) On Monday 26 October 2009 11:32:59 Camaleón wrote:
El 2009-10-26 a las 09:06 +0100, Rafa Grimán escribió:
On Sunday 25 October 2009 21:32:38 Camaleón wrote:
En mi red va pasable.
¿Samba lento? Eso es que la red y/o el servidor no están bien dimensionados ;)
Bueno, no todos tenemos "Octanes2" en casa >:-P
Eh! Que ya vamos por la Octane III :) Un poco de "Spam":
¡Menudos monstruitos! :-)
Hum... curioso que el modelo de una vía utilice el chipset 945GC (¿lakeport?) :-?
No te sé decir el por qué y aque no soy el Product Manager 0:) De todas maneras, son clusters para tener debajo de la mesa (deskside clusters) que empiezan con 8 cores (Xeon) o bien 2 cores (Atom).
Yo lo noto muy lento, cuando copio archivos "grandes" (>4 GiB.) en una red 10/100 y con equipos normalitos. El fish:// o sftp:// funciona mucho mejor.
Es que 10/100 es poco ;) Samba consume bastante CPU y RAM (1 proceso por cliente). ssh consume menos RAM.
Otra cosa, transfiriendo ficheros grandes y con redes 1 Gbps es recomendable usar jumbo frames (con 100 Mbps no valen los jumbo frames). Ahora, eso sí, tienes que activar jumbo frames en TODOS los equipos conectados al switch.
Lo de que el fish o el sftp funciona mejor ... ¿números/tiempos? Sólo curiosidad por saber cuánto mejor funciona.
Números rápidos... archivo de 175 MB (red 10/100, cliente: 3 GB de ram, pentium core 2 quad - servidor: 3 GB de ram, Pentium D):
Cliente suse -> servidor suse (samba): tasa 7,1 MB/s Cliente suse -> servidor suse (sftp): tasa 6,8 MB/s
Grrr... ¡Pero el sftp no se atranca! :-)
ROFL. No pretendía que fuera esto una "demostración". Era sólo curiosidad 0:) De todas maneras, no se van mucho los números, sólo hay una diferencia de 0.3 MB/s.
Copiando mediante samba (archivos más grandes) se para, va a saltos (aunque no es constante, sí hace "parones").
En cambio, usando sftp o fish la copia es más... ¿fluida?. No sé, quizá tengo que revisar las opciones del samba, no lo he tuneado mucho (más bien "nada").
Curioso, se me ocurre que con ssh (fish, scp, sftp) el cliente tiene que cifrar los datos por lo que los envía más despacio (los paquetes). En cambio, con Samba el envío es inmediato (no hay que cifrar y "descifrar") por lo que llenas los buffers (RAM) más deprisa y no da tiempo a escribir a disco. Obviamente esto son ideas que se me ocurren de buenas a primeras sin ningún tipo de demostración científica. Habría que monitorizar el cliente y el servidor (IOPS, RAM, red y CPU). Hacer muchas mediciones y luego sacar estadísticas. Vamos que no merece la pena ;) Claro que si tienes tiempo libre ... ;)
No sé, quizá es kde, opensuse o alguna otra configuración que se me escapa (¿netbios activado?) pero desde luego samba no es el más rápido del oeste.
NFS da mejor rendimiento con el mismo hardware.
Ese no lo he probado... ¿es complicado de configurar, como samba? :-?
Nop, es bastante sencillo (IMHO).
Creo que windows tiene una utilidad dentro del paquete de herramientas de servicios para unix que permite trabajar con unidades nfs.
Sí, creo que se llama SFU o algo así. Nunca lo he probado así que no sé qué rendimiento dará Windows NFS.
ssh si que es lento como para morirse :))
Claro, por eso es uno de los protocolos de red "menos" utilizados ¿ein?
:-)
SSH es "lento" si no tenemos una CPU potente, recordemos que cifra y es donde se "pierde tiempo".
Eso, y encima ssh te añade el cifrado "gratis" :-P
Ná, es que samba no me gusta nada... ¿se nota mucho? O:-)
Noooooo ;)
O:-P
Reconozco que samba es útil, pero si sólo hay transferencia de archivos de por medio y no es necesario compartir impresoras o pertenencer a dominio, pues me lo pensaba dos veces.
Samba es muy pesado de configurar (especialemnte si tienes un AD o servidores PDC) y encima, no hace reconexiones si pierdes el servidor. Es decir, si tienes dos Samba en HA y uno cae, el otro no retoma la conexión del cliente sino que el cliente tiene que reconectar (volver a hacer doble click). En el caso de NFS, se balancea esa conexión abierta por lo que el cliente no se entera que se ha caido el servidor. Hasta donde yo sé, esto es una limitación del protocolo/estándar SMB/CIFS. Smaba no es la panacea, pero si tienes clientes Windows por en medio ... casi no te queda más remedio :( Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.1 :) -- 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