¿Consejos para depurar el rendimiento de Samba?


8

Samba me da 24 MB / s de lectura y 44 MB / s de escritura, mientras que ftp da 97 y 112 MB / s en las mismas circunstancias.

La documentación dice que

En general, debería encontrar que Samba funciona de manera similar a ftp a velocidad de transferencia sin procesar.

En mi caso, claramente no.

¿Dónde puedo encontrar consejos sobre cómo depurar el rendimiento de Samba?

¿O, alternativamente, consejos para reemplazar Samba con otra cosa? (Desafortunadamente, no puedo usar ftp, ya que necesito algo que pueda usarse con rsync / rsnapshot).

Más detalles:

  • Ambas computadoras ejecutan Ubuntu 10.10 (usando Samba porque también tengo una Mac)
  • El recurso compartido Samba está en una red doméstica local, montada como

    $ mount
    ...
    //server.local/share/ on /mnt/share type cifs (rw,mand)
    
  • El rendimiento de Samba se probó copiando ( cp) un solo archivo de ~ 4 GB desde y hacia el recurso compartido, utilizando el timetiempo y el cálculo manual de la velocidad de transferencia.

  • El rendimiento de ftp son los números del cliente de ftp para obtener / colocar el mismo archivo.
  • iperf da velocidad de red ~ 900 Mbits / s
  • bonnie++ proporciona velocidades de disco> 200 MB / s en ambos lados para lecturas de bloque y escrituras de bloque
  • Intenté cambiar los parámetros sugeridos en el CÓMO de ajuste del rendimiento (lectura / escritura sin formato, tamaño de lectura, opciones de socket), la mayoría de ellos hizo poca o ninguna diferencia. (El que marcó la diferencia hizo que la velocidad de escritura cayera un 50%).

Actualización: Según la lista de correo de Samba de 2009, los problemas de rendimiento se derivan de smbfs / cifs en lugar del servidor de Samba.
jg-faustus

Respuestas:


3

En realidad, FTP tiene una tasa de rendimiento de datos bastante eficiente una vez que se pone en marcha. La sobrecarga que ralentiza las cosas es con la descarga de un archivo en primer lugar. Eso no quiere decir que no hay un problema con Samba aquí. Debería estar funcionando casi idénticamente.

Para ser honesto, no tengo ni idea de dónde deberías comenzar a tratar de arreglar esto.

Idealmente, podría colocar otra computadora allí con una instalación de referencia de Samba (por ejemplo, Windows) y probarla como cliente y servidor contra las máquinas Ubuntu. Entonces sabría qué máquina era el problema, si era solo una dirección el problema y luego sería capaz de informar errores basados ​​en esto y / o encontrar una solución para el ínterin.

Hace un tiempo vi algo sobre cierto hardware de red que fallaba bajo Samba. Eran conmutadores y adaptadores de red, pero no puedo encontrar nada al respecto. Probablemente fue un caso tan extremo que no vale la pena considerarlo.

¿Qué tal si esquivamos a Samba? FTP podría no funcionar, pero ¿qué pasa con NFS ? Probablemente tiene las velocidades de transferencia más altas del lote (en mi experiencia) y debería manejar bien rsync.

También puede ver el montaje de FUSE en el servidor FTP para que rsync pueda intimidarlo.


Gracias por sugerencias y comentarios. No tenía idea de que es posible montar FTP cifs. Veré también en NFS. Si el bajo rendimiento de Samba es algo no trivial y no está relacionado con Ubuntu, ¿tal vez pertenece a la lista de correo de Samba o algo así en lugar de aquí?
jg-faustus

La suya es probablemente la mejor respuesta que voy a obtener :) Gracias de nuevo.
jg-faustus

1
puede montar el recurso ftp: curlftpfs [usuario @] host: [dir] punto de montaje [opciones]
jet

1

¿Qué tipo de rendimiento obtienes al ejecutar rsync sobre ssh? ¿Tal vez podría hacer su rsync con ssh y luego también usar samba para cuando necesite transferir cosas entre su mac?


rsync sobre ssh proporciona 60 MB / s, aproximadamente a medio camino entre Samba y FTP. Pero acabo de ver un consejo en otro lugar que rsync en modo daemon (tener una máquina como servidor rsync) puede equipararlo con FTP, lo intentaré a continuación.
jg-faustus

1

puedes probar esto en smb.conf

socket options = SO_KEEPALIVE SO_REUSEADDR \
   SO_BROADCAST TCP_NODELAY IPTOS_LOWDELAY \
   IPTOS_THROUGHPUT SO_SNDBUF=8192 SO_RCVBUF=8192

oplocks = yes

write raw = yes
read raw = yes

He probado algunos de ellos. TCP_NODELAY: pequeña mejora. escribir en bruto y leer en bruto: no hay diferencia apreciable. SO_SNDBUF y SO_RCVBUF: rendimiento de escritura reducido con un 50%, no buscó más. Revisaré el resto cuando tenga la oportunidad.
jg-faustus
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.