Copias lentas al NAS: los ajustes SMB que realmente importan

Qué hace realmente lentas las copias SMB

SMB (Server Message Block) no es una sola cosa. Es una familia de protocolos con versiones, negociación de dialecto, integridad opcional, cifrado opcional, multichannel opcional y muchos comportamientos “útiles” del cliente. La velocidad de copia es la propiedad emergente de:

• Latencia del almacenamiento (especialmente escrituras aleatorias pequeñas para “muchos archivos diminutos”).
• Ancho de banda de la red (obvio), más pérdida, retransmisiones y bufferbloat (menos obvio).
• Ciclos de CPU en cliente y servidor para firmar/cifrar y para cualquier antivirus/drivers de filtrado.
• Control de flujo SMB: créditos, I/O pendientes y cuántas solicitudes pueden estar en vuelo.
• Agitación de metadatos: creaciones, cierres, lecturas de atributos, comprobaciones de ACL, manejos durables, enumeración de directorios.
• Comportamiento de la aplicación: copia desde Explorer vs robocopy vs una app que hace copias estilo sincronización.

Dos trabajos de copia pueden ser “del mismo tamaño” y comportarse como planetas distintos:

• Un ISO de 50 GB es principalmente I/O secuencial. Quiere ancho de banda y buffers grandes.
• Dos millones de archivos de 16 KB son metadatos y I/O aleatorio. Quieren baja latencia, operaciones de directorio rápidas y políticas de antivirus sensatas.

El ajuste de rendimiento SMB, bien hecho, consiste principalmente en no pelear con tu cuello de botella. Hecho mal, es culto cargo: MTU más grande, más hilos, más caché, más “optimización”. Así es como terminas con un NAS “optimizado” convertido en un calefactor muy caro.

Broma #1: Ajustar SMB es como sazonar una sopa—añade sal despacio, porque “echar todo el salero” es como recibir un llamado a las 2 a.m.

Guía rápida de diagnóstico (primero/segundo/tercero)

Si solo recuerdas una cosa, recuerda esto: separa disco, red y características SMB. No empieces cambiando configuraciones. Empieza demostrando dónde está el techo.

Primero: clasifica la carga de trabajo

• ¿Archivo grande único? Espera velocidad de línea si los discos están bien y SMB no está aplicando características de seguridad costosas.
• ¿Muchos archivos pequeños? Espera más lentitud. Entonces pregunta: “¿Es irrazonablemente más lento que el mes pasado?”
• ¿Lectura vs escritura? Las escrituras suelen ser más lentas por comportamiento síncrono, snapshots, paridad RAID o ausencia de SLOG (en ZFS).

Segundo: demuestra la capacidad bruta de red (sin SMB)

• Usa iperf3 entre cliente y NAS (o NAS y un host de prueba en la misma VLAN).
• Si no te acercas al ancho de banda esperado aquí, SMB no te va a salvar.

Tercero: demuestra la capacidad de almacenamiento del NAS (sin SMB)

• Mide rendimiento y latencia de disco en el NAS mismo (fio es ideal; herramientas básicas también funcionan).
• Si el NAS ya está al 80–100% de CPU, tus ajustes SMB son cosméticos.

Cuarto: valida dialecto SMB y características costosas

• Revisa la versión SMB, estado de firmado, estado de cifrado, multichannel y RSS.
• Busca antivirus, DLP, filtrado de archivos o sobrecarga de cuotas.

Quinto: captura una prueba “limpia” y una copia “real”

• Un archivo grande generado en el cliente (para que no esté limitado por lecturas del disco cliente).
• Una carpeta representativa del “problema”.
• Compara comportamientos. Si solo falla la carga de archivos pequeños, ajusta para metadatos/latencia, no para ancho de banda.

Hechos e historia que explican las rarezas actuales

Los problemas de rendimiento SMB a menudo parecen misterios hasta que recuerdas de dónde viene SMB y qué está tratando de garantizar el protocolo.

1. SMB se originó en los años 80 (raíces en IBM, luego adoptado y ampliado por Microsoft). Mucho del comportamiento “charlatán” es equipaje histórico.
2. SMB1 fue diseñado para LANs con suposiciones diferentes; sus ineficiencias (y problemas de seguridad) son la razón por la que los entornos modernos deben tratar SMB1 como “no”.
3. SMB2 (era Vista/Server 2008) redujo drásticamente la charla y mejoró el pipelining—esta es una razón por la que SMB2/3 puede ser mucho más rápido en enlaces de alta latencia.
4. SMB3 introdujo cifrado y multichannel (era Windows 8/Server 2012). Excelentes características, pero pueden exigir CPU o exponer rarezas de controladora/NIC.
5. El firmado SMB existía mucho antes de que “zero trust” fuera una consigna; protege la integridad, pero tiene un coste de rendimiento medible—especialmente en CPUs débiles o cuando no hay offloads.
6. La copia desde Explorer ha cambiado su comportamiento entre versiones de Windows (tamaños de buffer, reintentos, UI “amigable”). Robocopy suele ser más predecible para pruebas.
7. Los opportunistic locks (oplocks) y leasing se introdujeron para reducir viajes de ida y vuelta en la red mediante caché—hasta que una app o un escáner invalida cachés y fuerza rupturas constantes.
8. Los créditos SMB son control de flujo; en conexiones anchas con RTT alto (o servidores ocupados), el comportamiento inadecuado de créditos puede limitar I/O pendiente.
9. Los jumbo frames se pusieron de moda con 10GbE, pero SMB no los requiere mágicamente; los jumbo reducen principalmente CPU y overhead de interrupciones cuando todo está correctamente configurado de extremo a extremo.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las tareas que realmente ejecuto cuando alguien dice “SMB está lento”. Cada una incluye: el comando, cómo se ve “bien” y la decisión que tomas.

Task 1: Confirmar dialecto SMB, cifrado, firmado (cliente Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,Encrypted,Signed,NumOpens | Format-Table -Auto"
ServerName ShareName Dialect Encrypted Signed NumOpens
--------- --------- ------- --------- ------ --------
nas01     data      3.1.1   False     True   12

Qué significa: Estás en SMB 3.1.1, el cifrado está apagado, el firmado está activado. Ese “Signed=True” puede estar impuesto por política.

Decisión: Si el rendimiento es bajo y la CPU alta, verifica si el firmado es obligatorio. Si la política lo exige, deja de discutir y optimiza en otro lado (RSS, multichannel, CPU, drivers de NIC).

Task 2: Medir capacidad bruta de red con iperf3

cr0x@server:~$ iperf3 -c nas01 -P 4 -t 10
Connecting to host nas01, port 5201
[SUM]   0.00-10.00  sec  4.65 GBytes  3.99 Gbits/sec  0             sender
[SUM]   0.00-10.00  sec  4.64 GBytes  3.99 Gbits/sec                  receiver

Qué significa: Tu camino de red puede hacer ~4 Gbps con cuatro flujos. Bien.

Decisión: Si iperf3 es bajo, arregla velocidad/duplex de NIC, cableado, configuración de switch, VLAN, QoS o Wi‑Fi antes de tocar SMB.

Task 3: Comprobar velocidad de enlace y errores de NIC (Linux NAS)

cr0x@server:~$ sudo ethtool eno1
Settings for eno1:
	Speed: 10000Mb/s
	Duplex: Full
	Auto-negotiation: on
Link detected: yes

Qué significa: El enlace está arriba a 10GbE full duplex. Esa es la línea de salida.

Decisión: Si dice 1000Mb/s cuando esperas 10GbE, para. Busca cable malo, SFP equivocado o configuración de puerto en el switch.

Task 4: Revisar contadores de interfaz para pistas de drops/retransmisiones (Linux)

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
    987654321  1234567      0      12       0    1234
    TX:  bytes packets errors dropped carrier collsns
    123456789  2345678      0       8       0       0

Qué significa: Drops no nulos. Unos pocos pueden ser ruido; crecimiento persistente durante pruebas es una señal roja.

Decisión: Si los drops aumentan con la copia, estás ante congestión, problemas de buffer o problemas de offload/driver. Arregla eso antes de afinar Samba.

Task 5: Confirmar MTU de extremo a extremo (Linux)

cr0x@server:~$ ping -M do -s 8972 nas01 -c 2
PING nas01 (10.20.0.10) 8972(9000) bytes of data.
8972 bytes from 10.20.0.10: icmp_seq=1 ttl=64 time=0.321 ms
8972 bytes from 10.20.0.10: icmp_seq=2 ttl=64 time=0.299 ms

--- nas01 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Qué significa: Los jumbo frames (MTU 9000) probablemente funcionan en este camino.

Decisión: Si esto falla, no actives jumbo frames “porque es más rápido”. El jumbo parcial es peor que no tener jumbo; produce fragmentación o agujeros negros según el equipo.

Task 6: Verificar estado de SMB multichannel (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbMultichannelConnection | Format-Table -Auto"
Server Name Client IP   Server IP   Client Interface Index Server Interface Index RSS Capable RDMA Capable
----------- ---------   ---------   ---------------------- --------------------- ----------- ------------
nas01       10.20.0.21  10.20.0.10  14                     12                    True        False

Qué significa: Multichannel existe y RSS es capaz. Si hubiera múltiples interfaces, verías múltiples filas.

Decisión: Si se esperaba multichannel pero está ausente, comprueba soporte en el servidor SMB (versión/config de Samba), ajustes RSS de NIC o si solo hay un camino viable.

Task 7: Comprobar postura RSS / offload del cliente (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterRss | Select-Object Name,Enabled,NumberOfReceiveQueues,Profile | Format-Table -Auto"
Name        Enabled NumberOfReceiveQueues Profile
----        ------- --------------------- -------
Ethernet0   True    8                     ClosestProcessor

Qué significa: RSS está activado. Bien: SMB puede repartir el procesamiento.

Decisión: Si RSS está desactivado en una NIC 10GbE en cliente/servidor, a menudo vas a saturar un solo núcleo. Arregla RSS antes de tocar Samba.

Task 8: Verificar saturación de CPU en el servidor (Linux NAS)

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.6.0 (nas01)  02/05/2026  _x86_64_  (16 CPU)

03:11:01 PM  CPU   %usr %nice %sys %iowait %irq %soft %idle
03:11:02 PM  all   22.10  0.00  8.33   1.50 0.00  2.10 66.0
03:11:02 PM    7   91.00  0.00  6.00   0.00 0.00  0.00  3.0

Qué significa: Un núcleo está al ~91% mientras la CPU global está bien. Es un signo clásico de afinidad/interrupción/RSS o trabajo mono-hilo (cripto, cola única).

Decisión: Si un núcleo está al máximo durante la copia SMB, investiga RSS, interrupciones de NIC y si el firmado/cifrado consume un solo hilo.

Task 9: Observar latencia de disco durante la copia (Linux NAS)

cr0x@server:~$ iostat -x 1 5
avg-cpu:  %user %nice %system %iowait  %idle
          18.12  0.00   6.44    4.10  71.34

Device            r/s   w/s  rkB/s  wkB/s  await  svctm  %util
nvme0n1          2.0  450.0   64.0 51200.0  2.10  0.20   9.5
md0              0.0  820.0    0.0 52000.0 18.50  0.00  98.0

Qué significa: El array subyacente (md0) está cerca del 100% de utilización con ~18 ms de await. Ese es tu limitador para escrituras.

Decisión: Deja de “afinar SMB” y arregla el almacenamiento: caché de escritura, nivel RAID, recordsize de ZFS, SLOG, número de discos, o mueve la carga a SSD.

Task 10: Confirmar que Samba usa aio y opciones de socket sensatas (Linux NAS)

cr0x@server:~$ testparm -s | egrep -i "aio|socket|smb2 leases|server multi channel|server signing|smb encrypt"
	aio read size = 1
	aio write size = 1
	server multi channel support = yes
	server signing = mandatory
	smb encrypt = disabled
	socket options =
	smb2 leases = yes

Qué significa: AIO está activado (umbral 1 significa prácticamente siempre), multichannel está soportado, firmado es obligatorio.

Decisión: Si el firmado es obligatorio y la CPU es tu cuello de botella, considera “signing desired” (si la política lo permite) o mejora CPU / activa aceleración criptográfica. Si multichannel está apagado, actívalo solo después de verificar estabilidad de NIC y switch.

Task 11: Comprobar si SMB cae a SMB1 o NT1 en algún lado (logs del servidor Linux)

cr0x@server:~$ sudo journalctl -u smbd --since "1 hour ago" | egrep -i "SMB1|NT1|deprecated|protocol"
Feb 05 14:22:18 nas01 smbd[2143]: protocol negotiation failed: client requested NT1

Qué significa: Algún cliente está intentando SMB1 (NT1). Esto puede causar un rendimiento horrible y exposición de seguridad.

Decisión: Encuentra el cliente, desactiva SMB1 y aplica como mínimo SMB2_02 o superior.

Task 12: Probar una escritura controlada de archivo grande desde un cliente Windows (robocopy)

cr0x@server:~$ powershell -NoProfile -Command "robocopy C:\temp \\nas01\data\perf-test bigfile.bin /np /r:0 /w:0 /mt:8"
-------------------------------------------------------------------------------
   ROBOCOPY     ::     Robust File Copy for Windows
-------------------------------------------------------------------------------

  Source : C:\temp\
    Dest : \\nas01\data\perf-test\

    Files : bigfile.bin

  Options : *.* /MT:8 /R:0 /W:0 /NP

------------------------------------------------------------------------------
               Total    Copied   Skipped  Mismatch    FAILED    Extras
    Dirs :         1         0         1         0         0         0
   Files :         1         1         0         0         0         0
   Bytes : 50.000 g  50.000 g         0         0         0         0
   Times :   0:02:10   0:02:10                       0:00:00   0:00:00
   Speed :           410.123 MegaBytes/min
   Speed :            6.835 MegaBytes/sec

Qué significa: 6.8 MB/s a un NAS es catastróficamente bajo para un solo stream. Ahora sabes que no son “solo archivos pequeños”. Algo limita fundamentalmente las escrituras.

Decisión: Correlaciona esto con iostat (almacenamiento), iperf3 (red) y CPU. No persigas oplocks; persigue el limitador.

Task 13: Confirmar que Windows no está escribiendo con comportamiento de buffering patológico (contadores de rendimiento)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\SMB Client Shares(*)\Avg. Write Queue Length' -SampleInterval 1 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue"
Path                                                     CookedValue
\\SMB Client Shares(\\nas01\data)\Avg. Write Queue Length 15

Qué significa: Una cola de escritura cliente SMB alta sugiere que el cliente está esperando confirmaciones del servidor (el servidor es lento o está controlando el flujo).

Decisión: Si la longitud de la cola se mantiene alta mientras la red está subutilizada, investiga latencia de disco en el servidor, créditos SMB o firmado/cifrado que consumen CPU.

Task 14: Revisar retransmisiones TCP en Linux (servidor o cliente)

cr0x@server:~$ netstat -s | egrep -i "retransm|segments retransm"
    184 segments retransmitted

Qué significa: Existen retransmisiones. El número absoluto no es el punto; la tendencia durante pruebas sí lo es.

Decisión: Si las retransmisiones suben rápido durante copias, arregla problemas de capa 1/2/3, offloads o congestión. El tuning SMB no compensará pérdida de paquetes.

Task 15: Validar opciones por share en Samba que afectan caché y durabilidad

cr0x@server:~$ testparm -s --section=data | egrep -i "strict sync|sync always|durable handles|kernel oplocks|oplocks|vfs objects"
	strict sync = yes
	sync always = yes
	kernel oplocks = yes
	oplocks = yes
	durable handles = yes
	vfs objects = acl_xattr

Qué significa: sync always = yes fuerza escrituras síncronas. Eso mata el rendimiento a menos que realmente lo necesites.

Decisión: Si este es un share de uso general, apaga sync always. Si es para una base de datos que exige semántica síncrona, entonces necesitas almacenamiento adecuado (SLOG, BBWC, etc.), no configuración optimista.

Los ajustes SMB que realmente importan

La mayoría de los “ajustes SMB” en internet están obsoletos, son placebo o peligrosos en producción. Estos son los que repetidamente mueven la aguja—porque se alinean con cuellos de botella reales.

1) Arregla lo aburrido primero: velocidad/duplex, cableado y simetría de ruta

Si tu NAS negocia 1GbE en un lado y 10GbE en el otro, SMB entregará rendimiento de 1GbE. Igual si tienes un bond LACP “útil” que hace hashing y todas las sesiones van por un enlace físico porque es una sesión TCP. No necesitas una guía de tuning; deja de adivinar.

2) SMB Multichannel: una ganancia real, pero solo cuando tus NIC se comportan

SMB Multichannel puede usar múltiples conexiones TCP a través de NICs (o a través de múltiples colas en una NIC con RSS). Esto ayuda tanto al rendimiento como a la resiliencia. También añade complejidad: más flujos, más posibilidades de encontrar un driver defectuoso y más sensibilidad a la asimetría.

• Hazlo cuando tengas 10/25/40GbE y clientes Windows modernos, y puedas validar comportamiento estable de multi‑cola.
• Evita “medio-multichannel” donde el servidor lo soporta pero el cliente tiene RSS deshabilitado (o viceversa). Así es como fijas un solo núcleo y te preguntas por qué el enlace está inactivo.

3) RSS y distribución de interrupciones: la tapa silenciosa del rendimiento

Si un núcleo de CPU está al máximo durante transferencias SMB, te estancarás en un número sospechosamente consistente (a menudo unos pocos Gbps o menos) mientras el resto del sistema duerme. RSS es cómo repartes el procesamiento de recepción. La moderación de interrupciones y el número de colas también importan.

Qué hacer:

• Activa RSS en NICs Windows; verifica múltiples colas de recepción.
• En Linux, asegúrate de que multiqueue esté activado y que las interrupciones se distribuyan sensatamente.
• Actualiza firmware/drivers de NIC. Sí, es aburrido. Sí, importa.

4) Firmado y cifrado: conoce por lo que estás pagando

El firmado SMB asegura integridad: evita manipulaciones. El cifrado SMB protege confidencialidad. Ambos son controles de seguridad buenos. Ambos cuestan CPU y pueden reducir el rendimiento.

Reglas que uso en producción:

• Si estás en una LAN de confianza y la política lo permite: no exijas firmado para cada share. Ponlo en “desired”, no en “mandatory”.
• Si debes cifrar: asegúrate de que la CPU del NAS tenga AES‑NI (o equivalente) y que no estés fijando la carga criptográfica a un solo núcleo.
• No cifres doblemente (cifrado SMB más cifrado VPN) a menos que hayas presupuestado CPU para ello.

Una idea parafraseada de un referente en confiabilidad: “La esperanza no es una estrategia”.

5) No fuerces escrituras síncronas salvo que lo necesites

Configuraciones como sync always (Samba) o comportamientos de almacenamiento “siempre síncrono” pueden convertir un NAS en una máquina de latencia de escritura. Puede ser correcto para algunas cargas transaccionales. Para shares de usuario, suele ser autolesión.

Si tu organización exige “pérdida cero de datos ante fallo de energía”, compra hardware que lo soporte (caché con batería, journaling apropiado o diseño de intent log en ZFS) y pruébalo. No pongas “sync always” sobre un pool de SSD de consumo y lo llames empresarial.

6) Ajusta para la carga: archivos grandes vs archivos pequeños

Para transferencias secuenciales grandes, céntrate en:

• Ancho de banda, RSS, multichannel, margen de CPU y evitar características de seguridad caras cuando la política lo permita.

Para millones de archivos pequeños, céntrate en:

• Rendimiento de metadatos en el NAS (SSDs para metadatos, RAM suficiente, operaciones de directorio rápidas).
• Exclusiones de antivirus en cliente y servidor (con alcance controlado).
• Reducir búsquedas/lecturas de atributos y ACL innecesarias cuando sea posible.

7) Samba AIO y sendfile: buenos por defecto, pero valida

El I/O asíncrono de Samba y el soporte sendfile de cero-copia pueden ayudar. En kernels modernos, Samba generalmente hace un trabajo decente. Pero debes verificar que tu NAS no esté constreñido en otro sitio.

• AIO ayuda cuando hay beneficio en I/O paralelo y el sistema de ficheros subyacente lo soporta bien.
• sendfile puede reducir CPU para lecturas. No arreglará escrituras lentas.

Sospecha de “socket options” aleatorias pegadas desde 2009. Si ves a alguien recomendando TCP_NODELAY y buffers enormes como solución universal, estás leyendo folclore.

8) Desactiva SMB1. Aún. Siempre.

Si un dispositivo antiguo fuerza SMB1, aíslalo en su propia VLAN/share, restringe acceso y planifica su retirada. SMB1 no es “compatibilidad legada”; es “compatibilidad con ataques”. También es lento, charlatán y desagradable bajo latencia.

Broma #2: Si aún ejecutas SMB1, no estás “soportando legado”; tienes una pieza de museo que ocasionalmente recibe ransomware.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana desplegó un nuevo NAS para reemplazar un servidor de archivos Windows envejecido. La compra se justificó por “throughput bruto”—muchos discos, uplinks 10GbE y un panel que mostraba baja CPU en inactividad. El fin de semana de migración fue bien. El lunes no.

Los usuarios se quejaron de que abrir carpetas de proyecto tardaba una eternidad. Las copias “se quedaban atascadas” al azar. Soporte escaló como “problemas de red” porque el ping se veía bien y las aplicaciones web eran rápidas. Mientras tanto, el equipo de almacenamiento insistía en que el NAS “casi no hacía nada” porque los gráficos de throughput no estaban al máximo.

La suposición equivocada fue creer que throughput bajo significaba que el sistema no estaba ocupado. En realidad, la carga había cambiado de “archivos CAD grandes” a “miles de artefactos de build pequeños” con los años. Explorer hacía lecturas de atributos, comprobaciones de ACL y operaciones de metadatos relacionadas con miniaturas. En el NAS, el RAID subyacente era bueno para throughput secuencial pero tenía latencia mediocre bajo agitación de metadatos, y el share tenía strict sync habilitado “por seguridad”.

Cuando alguien graficó la latencia del disco (await) y no solo MB/s, todo encajó. El array pasaba el tiempo con alta utilización en pequeñas escrituras y flushes. La solución no fue una bandera mágica SMB. Movieron los shares pesados en metadatos a almacenamiento con SSD para metadatos, quitaron sync always de los shares generales y añadieron una exclusión de antivirus para directorios de build. La velocidad de copia subió y el tiempo de abrir carpetas dejó de generar tickets.

Micro-historia 2: La optimización que salió mal

Otra organización tenía escrituras SMB lentas hacia un NAS basado en Samba. Alguien leyó un blog de tuning y decidió que los jumbo frames “desbloquearían rendimiento”. Pusieron MTU 9000 en el NAS, el switch core y un puñado de servidores. Los escritorios y algunos switches de acceso quedaron en 1500 porque “probablemente negocia”. No lo hizo.

Durante un día, el rendimiento fue raro: a veces veloz, a veces lento, a veces colgado por segundos. Capturas de paquetes mostraron retransmisiones y patrones de fragmentación que no tenían sentido para una LAN. Soporte veía popups intermitentes de “unidad de red desconectada”. El equipo de almacenamiento no veía errores en discos. Todos se culpaban entre sí, que es el círculo de la vida.

El problema raíz fue MTU jumbo parcial y ruta MTU inconsistente. Algunos flujos sucedían dentro de un dominio MTU limpio; otros cruzaban equipos que no pasaban jumbo, lo que generó drops y reintentos. SMB, siendo un protocolo confiable sobre TCP, reintentó diligentemente—y el throughput colapsó.

La solución fue brutalmente simple: revertir a MTU 1500 en todas partes, luego reintroducir jumbo solo después de auditar cada salto (incluyendo vSwitches de virtualización e interfaces de firewall). El rendimiento se volvió primero estable y luego rápido. La “optimización” no falló porque los jumbo frames sean malos. Falló porque la red se trató como un anillo humorístico.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una gran empresa tenía quejas recurrentes: “SMB está lento” después de cada ciclo trimestral de parches. El equipo de almacenamiento estaba cansado de apagar incendios reactivos, así que implementaron una práctica de sonido: una prueba repetible de rendimiento SMB, ejecutada semanalmente y almacenada con métricas del sistema.

La base incluía tres pruebas: iperf3, una escritura de archivo grande con robocopy y una copia pesada en metadatos con robocopy. Registraban versiones de drivers NIC, dialecto SMB, estado de firmado/cifrado y CPU/latencia de disco del NAS durante cada ejecución.

Una semana, la prueba de archivo grande cayó a la mitad mientras iperf3 se mantenía normal. La latencia de disco estaba bien. La CPU mostraba un núcleo subiendo. Gracias a las baselines históricas, correlacionaron rápidamente la regresión con un driver NIC nuevo en un subconjunto de clientes Windows que deshabilitó RSS por una opción de “compatibilidad”. Nadie lo habría notado en el monitoreo normal porque la CPU promedio estaba bien y los gráficos de red parecían normales.

Revirtieron el driver, reactivaron RSS y el rendimiento volvió. La victoria no fue un ajuste sofisticado. Fue tener una baseline y tratar el rendimiento SMB como un SLO monitoreado, no como un rumor.

Errores comunes: síntoma → causa raíz → solución

1) “La red es rápida, pero las copias SMB son lentas”

Síntoma: iperf3 se ve bien, pero las copias de archivos se estancan en baja velocidad.

Causa raíz: Sobrecarga de CPU por firmado/cifrado, o latencia de disco en el NAS, o cuello de botella por núcleo único debido a RSS/offload.

Solución: Revisa estado de firmado/cifrado SMB, mide CPU por núcleo, confirma RSS/multichannel y mide await del disco durante la copia.

2) “Un solo archivo grande es rápido, pero carpetas con muchos archivos pequeños son terriblemente lentas”

Síntoma: Las ISOs vuelan; los árboles de código se arrastran.

Causa raíz: Sobrecarga de metadatos (creaciones/cierres/comprobaciones ACL), escaneo antivirus, snapshots o operaciones de directorio lentas.

Solución: Usa robocopy con y sin multihilo; revisa exclusiones de antivirus; coloca shares con muchos metadatos en SSD; reduce ajustes síncronos patológicos.

3) “Ayer era rápido; hoy es lento”

Síntoma: Regresión súbita, supuestamente sin cambios en topología.

Causa raíz: Actualización de drivers/firmware, cambio de política SMB (firmado obligatorio), cambios en path MTU o un nuevo producto de seguridad inline.

Solución: Compara propiedades de conexión SMB y ajustes NIC; revisa logs de cambios; valida MTU extremo a extremo; confirma que no haya nuevos drivers de filtrado o actualizaciones del NAS.

4) “La copia SMB se pausa cada pocos segundos”

Síntoma: Throughput por ráfagas; la barra de progreso se detiene.

Causa raíz: Bufferbloat/congestión, pérdida de paquetes y retransmisiones, o comportamiento de flush de almacenamiento (escrituras síncronas, tormentas de cache flush).

Solución: Revisa drops/retransmisiones en interfaces; verifica colas/QoS en switches; mide latencia y ajustes de caché del NAS; elimina sync forzado donde no sea necesario.

5) “Solo algunos clientes son lentos”

Síntoma: Un departamento se queja; otros están bien.

Causa raíz: Drivers NIC diferentes, Wi‑Fi vs cableado, GPOs de seguridad distintas (firmado), o diferencias de path (otro stack de switches).

Solución: Compara salidas de Get-SmbConnection; ejecuta iperf3 desde clientes lentos y rápidos; comprueba velocidad de enlace, RSS y contadores de errores.

6) “Activar jumbo frames lo empeoró”

Síntoma: Congelamientos intermitentes, retransmisiones, desconexiones.

Causa raíz: Configuración parcial de jumbo o dispositivo intermedio que no pasa jumbo.

Solución: Revierte a MTU 1500; prueba jumbo con pings DF en cada salto; luego re-habilita consistentemente o no lo hagas.

7) “Habilitamos cifrado SMB y ahora todo está lento”

Síntoma: Throughput cae, CPU sube.

Causa raíz: Cripto ligado a CPU, sin aceleración hardware, o ruta de cifrado mono-hilo en esa plataforma.

Solución: Asegura aceleración AES y uso de la misma; escala CPU; considera cifrar solo shares sensibles; valida multichannel/RSS para repartir la carga.

8) “Añadimos LACP, así que debería ser más rápido”

Síntoma: Aún limitado cerca de la velocidad de un enlace.

Causa raíz: Un flujo TCP único se hashéa a un miembro físico; SMB sin multichannel no dividirá un solo archivo entre enlaces.

Solución: Usa SMB multichannel para paralelismo; o prueba múltiples flujos concurrentes; ajusta política de hashing cuando corresponda; no vendas LACP como magia por flujo.

Listas de verificación / plan paso a paso

Paso a paso: estabiliza primero, luego acelera

1. Elige dos pruebas: un archivo grande (10–50 GB) y una carpeta representativa de “archivos pequeños”.
2. Ejecuta iperf3 para validar capacidad bruta de red y comportamiento de retransmisiones.
3. Verifica velocidad de enlace en cliente y NAS, y revisa contadores por drops.
4. Confirma dialecto SMB y si firmado/cifrado están activados/obligatorios.
5. Mide CPU por núcleo del NAS durante la copia; observa si algún núcleo se queda pegado.
6. Mide latencia de disco del NAS (await/%util) durante la copia.
7. Si está limitado por la red: arregla consistencia MTU, congestión en switches, cableado, drivers NIC.
8. Si está limitado por CPU: activa RSS, valida multichannel, considera reducir firmado/cifrado si la política lo permite, o mejora CPU.
9. Si está limitado por disco: mueve la carga a almacenamiento más rápido, añade SSD, ajusta RAID/ZFS, elimina sync forzado en shares generales.
10. Solo ahora: ajusta configuraciones Samba/SMB que correspondan al cuello de botella probado.
11. Vuelve a probar con el mismo dataset y método. Guarda los resultados.
12. Operacionaliza: crea una tarea semanal de baseline para detectar regresiones antes que los usuarios.

Checklist rápida de “hacer / no hacer”

• Haz tratar el rendimiento SMB como un sistema: cliente + servidor + red + almacenamiento.
• Haz medir latencia, no solo throughput.
• Haz mantener SMB1 deshabilitado y aplicar SMB2+ como mínimo.
• No habilites jumbo frames a menos que pruebes soporte MTU extremo a extremo.
• No fuerces escrituras síncronas en shares de propósito general.
• No pegues opciones antiguas de socket de Samba esperando milagros.
• No confundas ancho de banda agregado de LACP con throughput de un flujo único.

Preguntas frecuentes

1) ¿Por qué la copia desde Windows Explorer se siente más lenta que robocopy?

Explorer está optimizado para experiencia de usuario: mostrar progreso, vistas previas y a veces comportamiento de buffering distinto. Robocopy es más determinista para pruebas y puede paralelizar con /mt.

2) ¿Debo habilitar SMB Multichannel en Samba?

Si tus clientes son Windows modernos y tu stack NIC/driver es estable, sí—multichannel puede aumentar throughput y reducir cuellos por núcleo único. Valida con Get-SmbMultichannelConnection y observa comportamiento de CPU/interrupciones.

3) ¿Los jumbo frames ayudan al rendimiento SMB?

A veces. Reducen overhead por paquete y pueden mejorar eficiencia CPU en 10GbE+. Pero solo si cada salto soporta la MTU. El jumbo parcial es una trampa de rendimiento.

4) ¿Por qué los archivos pequeños se copian tan lento incluso en un NAS SSD rápido?

Las copias de archivos pequeños están dominadas por operaciones de metadatos, comprobaciones ACL y abrir/cerrar, no por throughput bruto. El antivirus y los snapshots pueden amplificar el problema. Mide latencia de operaciones de directorio y CPU del servidor, no solo MB/s.

5) ¿Vale la pena el firmado SMB pese al impacto en rendimiento?

El firmado protege frente a manipulación y ciertas clases de ataques. Si “vale la pena” es una decisión de seguridad. Operativamente: si debes firmar, planifica CPU en consecuencia y asegúrate de RSS/multichannel correctos para no saturar un núcleo.

6) ¿Debo desactivar el cifrado SMB para acelerar?

Sólo si la política lo permite y la red es de confianza. Un mejor primer paso es asegurar aceleración criptográfica hardware y cifrar sólo shares sensibles cuando sea factible.

7) ¿Por qué el rendimiento SMB se queda en ~110 MB/s incluso en un NAS “10GbE”?

110 MB/s está sospechosamente cercano a la tasa línea de 1GbE. Revisa negociación de velocidad de enlace, cables malos, un switch 1GbE en el camino o un dock del cliente que solo soporte gigabit.

8) ¿Cuál es la forma más simple de saber si los discos del NAS son el cuello de botella?

Observa iostat -x durante la copia. Si %util está cerca de 100% y await se dispara, los discos te están limitando. Si los discos se ven bien pero CPU o contadores de red se disparan, revisa ahí.

9) ¿LACP (bonding) puede duplicar la velocidad de mi copia SMB?

No para un solo flujo TCP en la mayoría de los casos. LACP aumenta ancho de banda agregado para muchos flujos. SMB Multichannel es la característica que puede usar múltiples conexiones para una sesión.

10) ¿Qué ajustes de Samba suelen ser “accidentalmente dañinos”?

sync always y perillas de “durabilidad” agresivas aplicadas a shares equivocados. También firmado/cifrado obligatorio sin planificación de CPU. Y opciones de socket aleatorias copiadas de posts antiguos de tuning.

Conclusión: próximos pasos prácticos

Si las copias SMB a tu NAS son lentas, no necesitas un curandero. Necesitas un bucle de medición corto y la disciplina de cambiar una cosa a la vez.

1. Ejecuta iperf3 y valida velocidad de enlace y errores. Demuestra la red.
2. Ejecuta una prueba de archivo grande con robocopy y observa CPU por núcleo del NAS y latencia de disco. Demuestra si estás limitado por CPU o por disco.
3. Revisa características SMB: dialecto, firmado, cifrado, multichannel, RSS. Identifica opciones costosas que estés pagando.
4. Arregla el cuello de botella raíz, no el síntoma: problemas de latencia de almacenamiento requieren soluciones de almacenamiento; pérdida de paquetes requiere arreglos de red; núcleos pegados requieren RSS/drivers.
5. Establece una baseline para detectar regresiones tras parches, no cuando la asistente del CFO intenta abrir “Q4 Budget FINAL v7.xlsx”.

Haz eso, y “SMB está lento” deja de ser una queja vaga y se convierte en un problema resuelto con recibos.