He estado luchando para solucionar un problema de rendimiento con un recurso compartido SMB / CIFS al realizar pequeñas escrituras.
Primero, permítame describir mi configuración de red actual:
Servidor
- Synology DS215j (con soporte SMB3 habilitado)
Clientes (misma computadora con cable de arranque dual Gig-E)
- Ubuntu 14.04.5 LTS, Trusty Tahr
- Windows 8.1
smb.conf
[global]
printcap name=cups
winbind enum groups=yes
include=/var/tmp/nginx/smb.netbios.aliases.conf
socket options=TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
security=user
local master=no
realm=*
passdb backend=smbpasswd
printing=cups
max protocol=SMB3
winbind enum users=yes
load printers=yes
workgroup=WORKGROUP
Actualmente estoy probando el rendimiento de escritura pequeña con el siguiente programa escrito en C ++ (en GitHub aquí ):
#include <iostream>
#include <fstream>
#include <sstream>
using namespace std;
int main(int argc, char* argv[])
{
ofstream outFile(argv[1]);
for(int i = 0; i < 1000000; i++)
{
outFile << "Line #" << i << endl;
}
outFile.flush();
outFile.close();
return 0;
}
Configuración de montaje de Linux:
//192.168.1.10/nas-main on /mnt/nas-main type cifs (rw,noexec,nodev)
Programa en tiempo de ejecución en Linux (picos de salida de red a ~ 100Mbps):
$ time ./nas-write-test /mnt/nas-main/home/will/test.txt
real 0m0.965s
user 0m0.148s
sys 0m0.672s
Instantánea PCAP que muestra el agrupamiento de muchas líneas en un solo paquete TCP:
Programe el tiempo de ejecución en Windows medido por PowerShell:
> Measure-Command {start-process .\nas-write-test.exe -argumentlist "Z:\home\will\test-win.txt" -wait}
Days : 0
Hours : 0
Minutes : 9
Seconds : 29
Milliseconds : 316
Ticks : 5693166949
TotalDays : 0.00658931359837963
TotalHours : 0.158143526361111
TotalMinutes : 9.48861158166667
TotalSeconds : 569.3166949
TotalMilliseconds : 569316.6949
Instantánea de PCAP en Windows que muestra una sola línea por solicitud de escritura SMB:
Este mismo programa tarda unos 10 minutos (~ 2.3Mbps) en Windows. Obviamente, el PCAP de Windows muestra una conversación SMB muy ruidosa con una eficiencia de carga muy baja.
¿Hay alguna configuración en Windows que pueda mejorar el rendimiento de escritura pequeña? Al observar las capturas de paquetes, parece que Windows no almacena las escrituras correctamente e inmediatamente envía los datos línea por línea. Mientras que, en Linux, los datos están fuertemente almacenados y, por lo tanto, tienen un rendimiento muy superior. Avíseme si los archivos PCAP serían útiles y puedo encontrar una manera de cargarlos.
Actualización 27/10/16:
Como mencionó @sehafoc, reduje la max protocolconfiguración de los servidores Samba a SMB1 con lo siguiente:
max protocol=NT1
La configuración anterior resultó exactamente en el mismo comportamiento.
También eliminé la variable de Samba al crear un recurso compartido en otra máquina con Windows 10, y también exhibe el mismo comportamiento que el servidor Samba, por lo que estoy empezando a creer que este es un error de escritura en caché con los clientes de Windows en general.
Actualización: 10/06/17:
Captura completa de paquetes de Linux (14 MB)
Captura completa de paquetes de Windows (375 MB)
Actualización: 12/10/17:
También configuré un recurso compartido NFS y Windows también escribe sin almacenamiento en búfer para esto. Entonces, definitivamente, es un problema subyacente del cliente de Windows, por lo que puedo decir, lo cual es definitivamente desafortunado: - /
¡Cualquier ayuda sería apreciada!