Tengo un problema extraño que parece haber comenzado recientemente.
Cuando copio un archivo grande (aproximadamente 6 GB) desde mi computadora portátil a uno de nuestros servidores de archivos más antiguos, el servidor se queda sin memoria después de unos segundos.
Esto comenzó recientemente, tal vez desde el martes del parche, aunque no puedo estar seguro.
Este servidor es una máquina con Windows 2000 sp4, es una Dell 2950 con 1 GB de RAM (Nota: ¡estoy seguro de que este servidor tenía más de 1 GB! No puedo comprobarlo físicamente hasta el final del día, cuando pueda apagarlo). Procesador Xeon de 3 GHz, 4 unidades SATA de 250 Gb y 7,5 k RPM en raid 10 y una NIC de 1 Gigabit conectada a un puerto de 1 GB en un conmutador administrado por Intel.
(Aparentemente no puedo publicar imágenes, por lo que será suficiente con un enlace)
Gráfico de uso de memoria + información durante la copia
Tan pronto como detengo la copia, la memoria se libera instantáneamente:
Gráfico de uso de memoria + información justo después de detener la copia
Eliminé el antivirus que no tuvo ningún impacto. Cambié las opciones de "Compartir archivos e impresoras para redes Microsoft" a equilibradas.
Tenemos otro servidor, Windows 2000 SP4 con 2GB Ram, Intel Quad Core 2.8Ghz, 6 x 300Gb 15k SAS en raid 10.
Cuando copio el mismo archivo de 6 GB aquí, la cantidad de memoria disponible no cambia.
¿Hay algo más que pueda mirar mientras el servidor se está ejecutando? Como está en uso y no se ve realmente afectado por copias de archivos pequeños, no puedo reiniciarlo todavía.
Aquí hay una captura de pantalla de algunos contadores de rendimiento que abrí justo cuando el servidor se queda sin memoria.
Contadores de rendimiento durante la copia
gracias
gareth
Respuesta1
Me encuentro con el mismo problema.
Intentando realizar una conversión P2V en un servidor de 64 bits que ejecuta Windows Server 2008. Cualquiera de los métodos normales de transferencia de archivos para el archivo VMDK (que es de 44 GB) hace que Windows en el servidor de destino se quede sin sus 14 GB de RAM después de unos minutos. debido al almacenamiento en caché del sistema de archivos.
Ejecutar la conversión P2V o la copia de archivos en un servidor de 32 bits no tiene este problema y el uso de memoria sigue siendo razonable.
Luego, intentar copiar el archivo VMDK al servidor VMWare de destino tiene el mismo problema.
Esta página describe exactamente lo que estoy viendo:
http://blogs.technet.com/askperf/archive/2007/05/08/slow-large-file-copy-issues.aspx
Según mi trabajo, este AM ESEUtil parece ser el camino a seguir. No fue tan rápido como esperaba, pero tampoco asustó a Windows.
El cliente FTP de Windows utiliza un archivo temporal en C:\ antes de mover el archivo al destino de destino. ¡Tener cuidado! :-)
Esto esmuyfrustrante.
Respuesta2
Sé que esto es un poco molesto, pero ¿has probado una utilidad de copia de archivos de terceros? Windows tiende a ser un poco tonto/lento con respecto a las copias de archivos a veces. Lifehacker hizo una lista de las 5 principales utilidades, prueba una de ellas y comprueba si sigues teniendo el mismo problema.
http://lifehacker.com/5280976/five-best-alternative-file-copiers
Además, como dijeron dos, verifique la configuración de su memoria virtual. La mejor práctica es que su archivo de paginación debe tener x1,5 su memoria (es decir, 1 GB de memoria = 1024 MB; 1024*1,5 = archivo de página de 1536 MB)
Respuesta3
Existen problemas conocidos con los procesos de copia de archivos de red en W2K: si el sistema remoto no puede vaciar el caché de escritura más rápido que la velocidad a la que llegan los datos del archivo a través de la red, consumirá constantemente toda la memoria física en el servidor si el El archivo es lo suficientemente grande. Mark Russinovich tiene algunos detalles sobre las formas en que esto podría sucederen este articulosobre los cambios realizados en los mecanismos de copia de archivos de Windows Vista. El gráfico de rendimiento que publicó se parece a este problema y he visto exactamente este tipo de comportamiento en el pasado cuando tenía un sistema de destino con discos muy lentos y una red rápida.
Sin embargo, aunque el sistema operativo de destino es un poco antiguo, el hardware no es tan débil y una configuración RAID 10 con unidades SATA de 4 x 7,2 K debería ser buena para una velocidad de escritura de entre 60 y 120 MB/s, que es significativamente mayor que la de 39 MB/s. sec Vista está solicitando su copia. Lo extraño aquí es que si se trata de un enlace GigE sólido y bien configurado, entonces podría alcanzar velocidades de transferencia de red que alcancen los 70 megas/s (y tal vez un poco más) para una copia sostenida de un archivo grande como este. Dicho esto, 38Meg/seg tampoco es anormal si hay otro tráfico que entra o sale del cliente o del servidor o (como es más probable) esa velocidad está limitada principalmente por la velocidad del disco duro de su computadora portátil local.
En cualquier caso, comprobaría que su RAID 10 estuviera realmente en buen estado; los síntomas aquí me harían sospechar que no pudo escribir tan rápido como debería.
Respuesta4
Tal vez necesite reforzar la memoria virtual en el disco duro de su sistema, donde el poco espacio en el disco duro podría haber causado dicho problema.
Además, desde un punto de vista lógico, el servidor en realidad no necesita almacenar un archivo en la memoria al copiar de un sistema de archivos a otro; simplemente asigna un búfer en la memoria por el que pasa el archivo. Sin embargo, dependiendo de cómo copie los archivos, algunas aplicaciones primero almacenarán el archivo completamente en la memoria y luego lo escribirán en el disco.
Intente utilizar un protocolo como FTP; si aún así sucede, probablemente debería investigar algunos problemas de red.
La pregunta interesante aquí sería cómo el servidor realmente almacena los archivos; como puede ver, la carga de E/S está muy baja, lo que significa que en realidad no está escribiendo el archivo en ninguna parte, solo lo almacena en la memoria.