최근에 시작된 것으로 보이는 이상한 문제가 있습니다.
내 노트북에서 이전 파일 서버 중 하나로 대용량 파일(약 6GB)을 복사하면 몇 초 후에 서버의 메모리가 부족해집니다.
이것은 최근에 시작되었습니다. 아마도 화요일 패치 이후였을 것입니다. 확실하지는 않지만요.
이 서버는 Windows 2000 sp4 시스템이며 1GB RAM을 갖춘 Dell 2950입니다(참고: 이 서버의 용량이 1GB 이상인 것으로 확신합니다. 하루가 끝날 때까지 전원을 끌 수 있는지 물리적으로 확인할 수는 없습니다). 3GHz Xeon 프로세스, RAID 10의 250Gb 7.5k RPM SATA 드라이브 4개 및 인텔 관리형 스위치의 1GB 포트에 연결된 1기가비트 NIC.
(분명히 이미지를 게시할 수 없으므로 링크가 필요합니다)
복사를 중지하자마자 메모리가 즉시 해제됩니다.
아무런 영향을 미치지 않는 바이러스 백신을 제거했습니다. "Microsoft 네트워크용 파일 및 인쇄 공유" 옵션을 균형 조정으로 변경했습니다.
또 다른 서버인 Windows 2000 SP4(2GB RAM, 2.8Ghz Intel 쿼드 코어, 6 x 300Gb 15k SAS)가 RAID 10에 있습니다.
여기에 동일한 6GB 파일을 복사해도 사용 가능한 메모리 양은 변경되지 않습니다.
서버가 실행되는 동안 확인할 수 있는 다른 항목이 있나요? 사용 중이고 작은 파일 복사본의 영향을 받지 않기 때문에 아직 재부팅할 수 없습니다.
다음은 서버에 메모리가 부족할 때 열어두었던 일부 성능 카운터의 스크린샷입니다.
감사합니다
가레스
답변1
나는 같은 문제에 봉착하고 있습니다.
Windows Server 2008을 실행하는 64비트 서버에서 P2V 변환을 시도합니다. VMDK 파일(44GB)에 대한 일반적인 파일 전송 방법을 사용하면 몇 분 후에 대상 서버의 Windows에서 14GB RAM이 부족해집니다. 파일 시스템 캐싱으로 인해.
32비트 서버에서 P2V 변환이나 파일 복사를 실행하면 이 문제가 발생하지 않으며 메모리 사용량이 적절하게 유지됩니다.
그런 다음 VMDK 파일을 대상 VMWare 서버에 복사하려고 하면 동일한 문제가 발생합니다.
이 페이지는 내가 보고 있는 내용을 정확하게 설명합니다.
http://blogs.technet.com/askperf/archive/2007/05/08/slow-large-file-copy-issues.aspx
내 작업에 따르면 AM ESEUtil이 갈 길인 것 같습니다. 예상했던 것만큼 빠르지는 않았지만 Windows도 놀라지 않았습니다.
Windows FTP 클라이언트는 파일을 대상 대상으로 이동하기 전에 C:\에 있는 임시 파일을 사용합니다. 조심하세요! :-)
이것은매우불만스러운.
답변2
이것이 약간 고통스럽다는 것을 알고 있지만 타사 파일 복사 유틸리티를 사용해 보셨나요? Windows는 때때로 파일 복사에 대해 멍청하거나 느린 경향이 있습니다. Lifehacker는 이러한 유틸리티 중 상위 5개 목록을 작성했으며 그 중 하나를 사용해 보고 여전히 동일한 문제가 있는지 확인하십시오.
http://lifehacker.com/5280976/five-best-alternative-file-copiers
또한 두 사람이 말했듯이 가상 메모리 설정을 확인하십시오. 모범 사례는 페이지 파일이 메모리의 1.5배가 되어야 한다는 것입니다(예: 1GB 메모리 = 1024MB, 1024*1.5 = 1536MB 페이지 파일).
답변3
W2K의 네트워크 파일 복사 프로세스에는 알려진 문제가 있습니다. 원격 시스템이 네트워크를 통해 파일 데이터가 도착하는 속도보다 더 빠르게 쓰기 캐시를 비울 수 없는 경우 서버의 모든 물리적 메모리를 꾸준히 소비하게 됩니다. 파일이 충분히 큽니다. Mark Russinovich는 이러한 일이 발생할 수 있는 방식에 대해 몇 가지 세부 정보를 제공합니다.이 기사에서Windows Vista의 파일 복사 메커니즘에 대한 변경 사항. 귀하가 게시한 성능 그래프는 이 문제와 유사하며 과거에 매우 느린 디스크와 빠른 네트워크를 갖춘 대상 시스템이 있었던 곳에서 정확히 이런 종류의 동작을 본 적이 있습니다.
그러나 대상 OS가 약간 오래되었더라도 하드웨어가 그다지 약한 것은 아니며 4x7.2K SATA 드라이브를 사용한 RAID 10 설정은 39Meg/초보다 훨씬 높은 60~120Meg/초 쓰기 속도에 적합해야 합니다. 초 Vista가 귀하의 사본을 보고하고 있습니다. 여기서 이상한 점은 이것이 견고하고 잘 구성된 GigE 링크라면 이와 같은 대용량 파일의 지속적인 복사본에 대해 70Meg/sec(약간 더 높을 수도 있음)에 도달하는 네트워크 전송 속도를 달성할 수 있다는 것입니다. 즉, 클라이언트나 서버에 들어오고 나가는 다른 트래픽이 있거나 (가능성이 더 높음) 속도가 대부분 로컬 노트북 하드 드라이브의 속도에 의해 제한되는 경우 38Meg/초는 비정상적인 것이 아닙니다.
어쨌든 저는 귀하의 RAID 10이 실제로 정상인지 확인하겠습니다. 여기서 나타나는 증상으로 인해 RAID 10이 필요한 만큼 빠르게 쓸 수 없다고 의심하게 됩니다.
답변4
하드 드라이브 공간이 부족하여 문제가 발생할 수 있는 시스템 하드 드라이브의 가상 메모리를 강화해야 할 수도 있습니다.
또한 논리적 관점에서 볼 때 서버는 파일 시스템에서 파일 시스템으로 복사할 때 실제로 파일을 메모리에 저장할 필요가 없습니다. 단지 파일이 통과하는 메모리에 버퍼를 할당할 뿐입니다. 그러나 파일을 복사하는 방법에 따라 일부 응용 프로그램은 먼저 파일을 메모리에 완전히 저장한 다음 디스크에 씁니다.
FTP와 같은 프로토콜을 사용해 보십시오. 그래도 문제가 발생한다면 네트워킹 문제를 조사해야 할 것입니다.
여기서 흥미로운 질문은 서버가 실제로 파일을 저장하는 방법입니다. 보시다시피 I/O 로드가 상당히 낮아졌습니다. 이는 실제로 파일을 어디에도 쓰지 않고 메모리에 버퍼링한다는 의미입니다.