Solución de problemas de velocidades de red: la investigación antigua


18

Estoy buscando ayuda con lo que estoy seguro es una pregunta antigua. Me he encontrado en una situación de anhelo de comprender el rendimiento de la red más claramente, pero parece que no puedo encontrar información que lo haga "hacer clic"

Tenemos algunos servidores distribuidos geográficamente, ejecutando varias versiones de Windows. Suponiendo que siempre usemos un host (un escritorio) como fuente, al copiar datos de ese host a otros servidores en todo el país, vemos una gran variación en la velocidad. En algunos casos, podemos copiar datos a 12 MB / s de manera consistente, en otros, estamos viendo 0.8 MB / s. Cabe señalar que, después de probar 8 destinos, siempre parecemos estar a 0.6-0.8MB / so 11-12 MB / s. En el edificio que nos interesa principalmente, tenemos una conexión OC-3 a nuestro ISP.

Sé que hay muchas variables en juego, pero supongo que esperaba que los expertos aquí pudieran ayudarme a responder algunas preguntas básicas para ayudar a reforzar mi comprensión.

1.) Para máquinas más antiguas, que ejecutan Windows XP, servidor 2003, etc., con una tarjeta Ethernet de 100 Mbps y una latencia típica de 72 ms, ¿suena razonable 0,8 MB / s? ¿O crees que es lo suficientemente lento como para indicar un problema?

2.) La clásica "velocidad matemática más rápida" de "rendimiento = ventana TCP / latencia" se calcula, en nuestro caso, a 0,8 MB / s (64 Kb / 72 ms). Entiendo que es un límite superior; que nunca esperarías alcanzar (debido a la sobrecarga) y mucho menos superar esa velocidad. Sin embargo, en algunos casos, estamos viendo velocidades de 12.3 MB / s. Hay aceleradores Steelhead dispersos por la red, ¿podrían explicar una tasa de transferencia tan alta?

3.) Se ha sugerido que el uso de SMB vs. SMB2 podría explicar las diferencias de velocidad. De hecho, como era de esperar, las capturas de paquetes muestran que ambas se utilizan según las versiones del sistema operativo en juego, como era de esperar. Entiendo lo que determina que SMB2 se use o no, pero tengo curiosidad por saber qué tipo de ganancia de rendimiento puede esperar con SMB2.

Mi problema simplemente parece ser la falta de experiencia y, lo que es más importante, la perspectiva, en términos de lo que son y no son velocidades de red razonables. ¿Alguien podría ayudar a impartir contexto / perspectiva?


las diferencias en velocidad no son solo SMB vs SMB 2. recuerde que en vista y superior, la pila de red ya no es un complemento basado en * nix y está integrado en el sistema operativo, lo que permite una latencia y una sobrecarga mucho más bajas.
Jim B

Gracias Jim, es bueno saberlo. Sí, sé que hay mil millones de variables en sentido ascendente y descendente, dependiendo de dónde se encuentre en la pila OSI. Un compañero de trabajo ha ofrecido que quizás la diferencia de velocidad podría ser simplemente una cuestión de "SMB vs. SMB2". Supongo que soy escéptico de que SMB2 (.1) nos dé un aumento de velocidad de 10x, pero nuevamente, no estoy lo suficientemente versado en las artes de aracne para saber;)
Univ426

Gran pregunta! ¿Alguna actualización sobre esto? Y fwiw, un cuadro de Windows XP que comparte pero no está "conectado" transfiere archivos más rápido que uno con un usuario conectado.
Chris K

Respuestas:


4

La fórmula matemática a la que se refiere es en realidad la forma de determinar la configuración de tamaño de ventana de transmisión más eficiente para TCP, no el ancho de banda real disponible. TCP utiliza un mecanismo llamado ventanas deslizantes que permite el ajuste de las velocidades de transmisión en función de las condiciones de la red. La idea es que un transmisor TCP envíe más y más datos sin requerir un acuse de recibo del receptor. Si hay una pérdida de datos, la cantidad de datos enviados entre confirmaciones disminuye, lo que también disminuye el ancho de banda efectivo.

La fórmula en cuestión en realidad determina el tamaño ideal de esa ventana de transmisión TCP en función de la latencia y la latencia de ida y vuelta entre un par determinado de hosts. La idea es tener un tamaño de ventana tal que la cantidad de datos 'en vuelo' corresponda a lo que se conoce como el producto de retraso de ancho de banda. Por ejemplo, si tiene 50 megabits por segundo (6.25 megaBYTES) y una latencia promedio de ida y vuelta de 100 ms, entonces tendría 6.25 * 0.1 = 625 kilobytes de datos. Este sería el valor que negociaría TCP (si está configurado correctamente). Como las características de latencia y ancho de banda de sus enlaces varían, también lo hace el tamaño de la ventana.

Lo que necesita es una herramienta de administración de ancho de banda como iperf (gratuita) que se ejecute tanto en el origen como en sus diversos destinos. Esto debería darle una idea de la cantidad real de rendimiento posible (independiente de otras aplicaciones) al tiempo que proporciona una idea de la latencia. Ejecutar un ping extendido entre hosts también proporcionará una idea general de las características de latencia. Cuando tenga estos datos, tendrá una mejor idea de lo que debería ver en lo que respecta al rendimiento.

Por cierto, el uso de cualquier tipo de optimizador de LAN a menudo incorporará compresión de datos, optimización de TCP, almacenamiento en caché, etc. Aunque es útil, puede ocultar la naturaleza de los enlaces subyacentes. Una vez que tenga una idea del ancho de banda / retraso sin procesar (y la pérdida de paquetes, potencialmente), puede mirar más de cerca para asegurarse de que sus diversos hosts estén configurados para aprovechar adecuadamente el ancho de banda disponible.


Gracias por la gran información rnxrx. Las ventanas deslizantes utilizadas en TCP tienen mucho sentido. En nuestro caso, dado que el único tráfico que nos preocupa es sobre TCP, creo que mi pregunta está muy centrada en TCP. Hemos utilizado otros métodos de transferencia de datos (como repliweb) y hemos logrado un rendimiento mucho mayor (hasta 11 MB / s). Sin embargo, no estaba al tanto del producto de retraso de ancho de banda, ¡es genial saberlo!
Univ426

2

Intente "ping -l 8092" o FTP o HTTP para verificar si es un problema SMB.

En primer lugar: ¿qué medios utilizas para conectar computadoras? ¿Qué somos "100mpbs"? Ethernet? No se puede usar para computadoras "distribuidas geográficamente", ¿verdad?

En el caso de "vpn a través de Internet", los enrutadores entre sus computadoras pueden usar diferentes enlaces: uno es rápido y el otro no. Pueden elegir enlaces basados ​​en muchos parámetros.

Por favor describa su red.

Eso también podría ser un problema de MTU: varios enlaces pueden tener MTU diferentes.


Gracias llya Actualicé la pregunta para responder la tuya. Esta es una red Ethernet normal, con una tarjeta de red de 100 Mbps en el host de origen.
Univ426

Josh, todavía no puedo entender: ((¿Conecta su PC con el servidor usando 100BASE Ethernet? Incluso si usa 100BASE-LX10 (Ethernet sobre dos fibras ópticas) no puede conectar dos computadoras "en todo el país": tiene límite de distancia de aproximadamente 10 kilómetros. Y en el caso de Ethernet, ¿utiliza el conmutador (¿cuál?) o conecta las computadoras directamente? Y por favor dígame acerca de la latencia: ¿cómo obtuvo "72 ms"? ¿Cómo lo calculó? Gracias
Ilya

Vamos a través de una LAN local al interenet público, a un centro de datos y luego al servidor a través de una intranet corporativa. La latencia se determinó mediante ping. Pasamos por varios interruptores como se esperaría. El interruptor más cercano tiene una velocidad de negociación automática confirmada con el host de 100Mbps. Espero que eso ayude.
Univ426

1
Nota: el ancho de banda que realmente le preocupa no es el 100M de su conexión LAN sino el enlace más lento entre los puntos finales. Este podría ser su enlace WAN o algún enlace intermedio más lento.
rnxrx

Ese es un gran punto, actualizaré la pregunta, pero sé que estamos conectados a nuestro ISP a través de un OC-3. Tengo que imaginar que todo lo que está corriente arriba es de al menos 100Mbps, y sé que la infraestructura en el edificio es de 100M o 1G hasta esa conexión.
Univ426

2

Muchos comentarios y usuarios han ofrecido excelentes consejos aquí. Algunos de ellos se acercaron bastante a lo que estaba buscando, pero también tuve la suerte de reunirme con un veterano de la red de nuestra compañía que me ayudó a aclarar las cosas. Pensé que publicaría mis hallazgos / entendimientos aquí para el beneficio de los demás. Por favor, siéntase libre de corregirme si algo de esto parece fuera de lugar:

1.) El rendimiento máximo de una sola sesión TCP con latencia de 72 ms y una ventana de 64K es de alrededor de 0.8 MB / s, lo que hace que esa velocidad sea razonable para copias de sesión única, de un solo hilo, como las que realizamos con robocopy.

2.) Esta diferencia de velocidad parece reducirse a la efectividad del método de transferencia. En nuestro caso, estábamos usando Robocopy y Repliweb. Descubrí que robocopy utiliza una única sesión TCP, mientras que Repliweb puede abrir varias sesiones para enviar datos.

3.) La investigación del sitio web de Microsoft muestra que SMB2 tiene una ganancia de rendimiento considerable sobre SMB1. Sin embargo, ha habido problemas en algunos casos en la forma en que el sistema operativo negocia qué protocolo usar, por lo que uno debe saber tanto a.) Qué casos se pueden usar SMB2 como b.) Si SMB2 se está utilizando realmente o no en capturas de red.

Actualmente, parece que Wire-shark puede determinar el uso del protocolo SMB2.

Espero que esto ayude. Nuevamente, mi comprensión es bastante rudimentaria aquí, siéntase libre de expandirse.


1
Además de los cálculos de retraso de ancho de banda, tenga en cuenta que SMB2 mejora enormemente el rendimiento sobre un enlace de mayor latencia, ya que no espera a que el servidor reconozca una escritura antes de transferir más datos. De hecho, vemos ganancias de rendimiento 10 veces mayores con SMBv2 sobre nuestras conexiones WAN usando ROBOCOPY. También considere el hilo / MT con robocopy si está copiando muchos archivos, de manera predeterminada, puede hacer hasta 8 en paralelo.
rmalayter
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.