Tengo un servidor, de doble núcleo, 4 GB de RAM, que ejecuta Windows Server 2008 y lo uso como mi servidor de archivos principal.
De repente, el acceso a él se ha vuelto muy lento. Ya sea que tenga RDP o acceda a archivos de forma remota a través de unidades asignadas, ¡es simplemente lento!
Puedo realizar RDP en otras máquinas ubicadas en otro estado a través de la VPN y funcionan mucho más rápido.
Si estoy trabajando directamente en el servidor, es ágil. Parece que es algo entre mi(s) máquina(s) cliente y el servidor.
¿Cómo haría para verificar la velocidad de conexión de red entre las 2 máquinas? ¿O algo más que deba comprobar?
Respuesta1
He visto muchos pequeños conmutadores de red baratos "volverse locos" en el último año. El modo de falla son las transferencias y caídas de paquetes súper lentas. (Lo he visto principalmente con conmutadores LinkSys durante el último año). Sospecho eso, aunque no necesariamente como lo primero. Afortunadamente, una prueba de velocidad sencilla es bastante sencilla con "Compartir archivos e impresiones".
Puede realizar una prueba "rápida y sucia" del rendimiento del servidor de archivos creando un archivo temporal grande en su computadora cliente con el comando fsutil y luego sincronizando la transferencia a la computadora servidor:
fsutil file createnew temp-file-name 209715200
Eso crearía un archivo temporal de 200 MB. Puede hacer una copia rápida con tiempo usando la siguiente secuencia de comandos (desde el directorio donde creó el archivo temporal, y suponiendo que tiene derechos para copiar en algún recurso compartido en la computadora del servidor):
@echo off
echo.|time
copy temp-file-name \\server-computer-name\share-name
echo.|time
Reste la hora de finalización de la hora de inicio, conviértala a segundos y divida 209715200 por la cantidad de segundos transcurridos para obtener bytes por segundo.
Debería ver más de 7.000.000 de bytes por segundo (aproximadamente 56 Mbps) en una LAN 100Base-TX. Cualquier cosa por debajo de eso y comenzaría a sospechar que algo está pasando. Suponiendo que la computadora servidor sea razonablemente moderna, debería poder llenar una tubería de 100 Mbps sin problemas. Si ve velocidades de transferencia más lentas que eso, comenzaría a mirar los contadores de errores en la interfaz de administración del conmutador al que están conectados el servidor y el cliente. Podría tener un cableado defectuoso, una discrepancia en el dúplex o problemas con el controlador de la NIC. Es sólo cuestión de localizar el problema metódicamente.
Editar: La prueba de copia de archivos es una buena prueba porque puede realizarla sin ningún software de terceros. Dado que descubrió que existe un cuello de botella, el siguiente paso es identificar la causa del cuello de botella.
La utilidad WSTTCP (disponible enhttp://www.pcausa.com/Utilities/pcattcp.htm) es una prueba rápida y sucia del controlador de NIC y del hardware de la infraestructura de red. Envía datos que no salen del disco ni se escriben en el disco, por lo que los subsistemas de disco en el cliente y el servidor terminan siendo excluidos de la ecuación.
En una máquina, ejecute lo siguiente (¡después de haber descomprimido WSTTCP!) para "escuchar" una conexión:
wsttcp -r
En la otra máquina, ejecute lo siguiente para transmitir una prueba a la máquina remota:
wsttcp -t <hostname>
En Ethernet de 100 Mbps, es posible que desees modificar el comando de transmisión (volver a ejecutar el comando de recepción en el receptor antes de iniciar el transmisor nuevamente) para enviar más buffers, porque obtendrás números ligeramente más precisos con una prueba más larga:
wsttcp -t -n8192 <hostname>
Eso moverá 64 MB de tráfico. Aumente el número "8192" para enviar más tráfico.
Deberá permitir que el oyente pase por su software de firewall en la computadora que escucha (puerto TCP 5001, de forma predeterminada) o desactivar el firewall temporalmente.
Si observa buenas velocidades de transferencia con WSTTCP pero transferencias lentas con la copia del archivo, comience a observar su subsistema de disco (y considere ejecutar una prueba comparativa de la unidad de disco duro). Si las transferencias de red aún son deficientes con WSTTCP, siga investigando la infraestructura de la red, el cableado, los controladores de NIC o el hardware de NIC.
Buena caza.
Respuesta2
Una cosa que recomendaría es buscar virus, etc. Ejecute netstat para ver las conexiones abiertas y observe si hay algo dudoso o inesperado. Probablemente existan herramientas para probar el ancho de banda entre dos máquinas con Windows, pero no conozco ninguna. iperf posiblemente podría funcionar dentro de cygwin.
Respuesta3
Realice un comando tracert a la computadora de destino para ver dónde está el retraso. Esto le brindará estadísticas detalladas sobre cada salto.
sintaxis, por ejemplo: tracert 196.12.2.13
Respuesta4
¿Quizás esto también sea parte del problema?