У меня странная проблема, которая, судя по всему, началась недавно.
Когда я копирую большой файл (около 6 ГБ) со своего ноутбука на один из наших старых файловых серверов, на сервере через несколько секунд заканчивается память.
Это началось совсем недавно, возможно, после вторничного патча, хотя я не могу быть уверен.
Этот сервер работает под управлением Windows 2000 SP4, это Dell 2950 с 1 ГБ оперативной памяти (Примечание: я уверен, что на этом сервере было больше 1 ГБ! Я не смогу физически проверить это до конца дня, когда смогу его выключить), процессор Xeon 3 ГГц, 4 диска SATA по 250 Гб 7,5 тыс. об/мин в RAID 10 и 1-гигабитная сетевая карта, подключенная к порту 1 ГБ на управляемом коммутаторе Intel.
(Очевидно, я не могу публиковать изображения, так что придется ограничиться ссылкой)
График использования памяти + информация во время копирования
Как только я останавливаю копирование, память мгновенно освобождается:
График использования памяти + информация сразу после остановки копирования
Я удалил антивирус, который не оказал никакого влияния. Я изменил параметры «Общий доступ к файлам и принтерам для сетей Microsoft» на сбалансированные.
У нас есть еще один сервер, Windows 2000 SP4 с 2 ГБ ОЗУ, 2,8 ГГц Intel Quad Core, 6 x 300 Гб 15k SAS в RAID 10.
Когда я копирую сюда тот же файл размером 6 ГБ, объем доступной памяти не меняется.
Есть ли что-нибудь еще, на что я могу посмотреть, пока сервер работает? Поскольку он используется и не сильно зависит от небольших копий файлов, я пока не могу его перезагрузить.
Вот снимок экрана некоторых счетчиков perfmon, которые я открыл как раз в тот момент, когда на сервере закончилась память.
Счетчики Perfmon во время копирования
Спасибо
, Гарет.
решение1
У меня та же проблема.
Попытка выполнить преобразование P2V на 64-разрядном сервере под управлением Windows Server 2008. Любой из обычных методов передачи файлов VMDK (объемом 44 ГБ) приводит к тому, что Windows на целевом сервере через несколько минут исчерпывает свои 14 ГБ оперативной памяти из-за кэширования файловой системы.
При выполнении преобразования P2V или копирования файлов на 32-разрядном сервере эта проблема не возникает, и использование памяти остается разумным.
Затем при попытке скопировать файл 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
Также, как сказал towo, проверьте настройки виртуальной памяти. Лучше всего, чтобы файл подкачки был в 1,5 раза больше памяти (т. е. 1 ГБ памяти = 1024 МБ; 1024*1,5 = 1536 МБ файла подкачки)
решение3
Известны проблемы с процессами копирования сетевых файлов в W2K — если удаленная система не может очистить кэш записи быстрее, чем скорость поступления данных файла по сети, то она будет постоянно потреблять всю физическую память на сервере, если файл достаточно большой. У Марка Руссиновича есть некоторые подробности о том, как это может произойтив этой статьеоб изменениях, внесенных в механизмы копирования файлов Windows Vista. График производительности, который вы опубликовали, похож на эту проблему, и я видел точно такое же поведение в прошлом, когда у меня была целевая система с очень медленными дисками и быстрой сетью.
Однако, даже если ваша целевая ОС немного устарела, оборудование не такое уж слабое, и настройка RAID 10 с 4 дисками SATA по 7,2 тыс. бит должна быть хороша для скорости записи где-то между 60 и 120 Мбит/с, что значительно выше, чем 39 Мбит/с, которые Vista сообщает для вашей копии. Странно здесь то, что если это надежное, хорошо настроенное соединение GigE, то вы можете достичь скорости передачи данных по сети, достигающей 70 Мбит/с (и, возможно, немного выше) для устойчивой копии большого файла, такого как этот. При этом 38 Мбит/с не являются ненормальными, если есть какой-либо другой трафик, входящий или исходящий либо от клиента, либо от сервера, или (что более вероятно) эта скорость в основном ограничена скоростью вашего локального жесткого диска ноутбука.
В любом случае я бы проверил, что ваш RAID 10 действительно исправен — описанные выше симптомы заставляют меня подозревать, что он не может записывать данные так быстро, как должен.
решение4
Возможно, вам необходимо увеличить объем виртуальной памяти на системном жестком диске, поскольку нехватка места на жестком диске могла стать причиной указанной проблемы.
Также, с логической точки зрения, серверу на самом деле не нужно хранить файл в памяти при копировании из файловой системы в файловую систему; он просто выделяет буфер в памяти, через который проходит файл. Однако в зависимости от того, как вы копируете файлы, некоторые приложения сначала сохранят файл полностью в памяти, а затем запишут его на диск.
Попробуйте использовать протокол типа FTP — если проблема все равно возникает, вероятно, следует проверить наличие сетевых неполадок.
Интересный вопрос здесь заключается в том, как сервер на самом деле хранит файлы — как вы можете видеть, нагрузка ввода-вывода существенно снизилась, что означает, что сервер на самом деле никуда не записывает файл, а просто буферизует его в памяти.