Назад | Перейти на главную страницу

Сервер хранения Windows 2003 зависает при передаче больших файлов

В одном из наших офисов есть NAS-устройство Dell PowerVault 745N, которое действует как главный файловый сервер. Он работает под управлением 32-битного Windows 2003 Storage Server SP2 с 3 ГБ оперативной памяти. Сервер содержит около 60 домашних папок пользователей, которые отображаются через AD.

Офисные клиенты представляют собой смесь XP SP3, Vista и Windows 7. Иногда сервер полностью зависает при передаче больших файлов. Когда происходит зависание, консоль перестает отвечать, остается только мышь и пустые обои. Иногда остановка копии освобождает сервер, иногда нет.

Подвешивание может длиться около 20 минут. В это время другие серверы также перестают отвечать с пустыми обоями на консоли. Если вам удается попасть на другой сервер, панель задач и команды запуска не отвечают.

Это также распространяется на клиентские компьютеры, иногда с аварийным завершением работы проводника. Я предполагаю, что это связано с отображением папки HOME.

В конце концов, сервер NAS освободится, и все вернется в норму.

Сервер настроен следующим образом:

PERC 4 / DC DATA 2 - 12 жестких дисков SCSI - RAID5

SHADOWCOPY 2 SCSI HDD - RAID1

CERC SATA DATA 11 4 жестких диска SATA - RAID5

ОС 4 SATA HDD - RAID5

Все драйвера и прошивки в актуальном состоянии. Я прошел через всю диагностику с Dell, и оборудование пришло в норму, включая полные тесты жестких дисков на массивах. На сервере установлен NOD32 как AV, но при удалении происходит зависание.

Когда это происходит, в журнале событий нет ошибок, и мы не регистрируем никаких ошибок ни на одном из наших переключателей ProCurve. DNS в домене работает нормально, а AD, насколько я могу судить, работает нормально.

Также нет установки общих папок DFS или NFS. Все акции стандартные Windows.

Я снял флажок «Разрешить компьютеру выключать это устройство для экономии энергии» в разделе «Управление питанием» на сетевой карте.

«Set Link Speed ​​and Duplex to Auto -gotiate 1000» Увеличен буфер дескрипторов приема с 256 до 352 (резервирует больше ресурсов ЦП для обработки данных)

Я провел трассировку сети с помощью сетевого монитора и обнаружил следующее: 417 8.078125 {SMB: 192, NbtSS: 25, TCP: 24, IPv4: 23} 192.168.2.244 192.168.5.35 SMB SMB: R; Nt Create Andx - Статус NT: Система - Ошибка, код = (52) STATUS_OBJECT_NAME_NOT_FOUND

Я пробовал разные кабели; Сетевые адаптеры и порты коммутатора дают одинаковый результат. Перенос файлов с других серверов в домене - это нормально. Все, что я не сделал, это запустил CHKDSK на дисках для поиска ошибок файловой системы.

На клиентах Vista я также запускал netsh interface tcp set global autotuning = disabled без результата.

Может быть, на сервере неисправен диск или количество операций ввода-вывода слишком велико для его обработки?

Есть идеи, почему зависание может вызывать проблемы с другими серверами в локальной сети?

Большое спасибо.

Вы наблюдали за использованием памяти сервером при копировании этих больших файлов? Лично я обнаружил, что перемещение файла размером 10 ГБ - отличный способ разрушить мой сервер Windows 2003 ... Взгляните на эту тему: Windows Server 2008 x64, передача больших файлов и использование памяти

Обсуждаются некоторые альтернативные инструменты копирования файлов для работы с большими файлами. Мне повезло с RichCopy.

Это похоже на то, что количество копий на сервер опережает возможности записи дисковой подсистемы (или ее части). Группа 12xSCSI Raid 5 на контроллере PERC должна быть в состоянии поддерживать большие последовательные записи со скоростью> 200 МБ / с (надеюсь, намного больше), но группа SATA на CERC, вероятно, изо всех сил пытается преодолеть 70 МБ / с и даже может быть совсем немного медленнее, чем это. Большая копия, предназначенная для пакета SATA Data Raid, может легко попасть через соединение GigE быстрее, чем это, и если это произойдет, Windows 2003 будет потреблять столько локальной памяти на сервере, сколько необходимо для буферизации копии. Размер буфера будет увеличиваться за счет всего остального на сервере, он даже приведет к тому, что основные службы ОС будут отключены, например, что приведет к общему поведению блокировки, о котором вы сообщаете. В этом случае может помочь перемещение целевого местоположения для работы с большими копиями в группу PERC RAID.

Это должно быть очень локализованной проблемой (т.е. затрагивать только этот сервер), если вы находитесь в исправной коммутируемой сети, но если другие серверы имеют зависимости от общих ресурсов или служб, размещенных на этом сервере, тогда они тоже могут иметь некоторые проблемы. Тем не менее, описанные вами симптомы намекают на нечто более серьезное, чем это. Если вы физически войдете на один из этих серверов во время одного из этих инцидентов, заметите ли вы ту же проблему?

У меня были лучшие результаты с сервером после того, как я сопоставил порт коммутатора со скоростью NIC. Я также отключил модуль AMON на NOD32, так как заметил, что иногда, когда происходили передачи, AV, казалось, зависал в файле в течение определенного периода времени. Я использую 2.7 на сервере, так как у меня были огромные проблемы с V4 на большинстве моих серверов.

Сервер все еще не на 100%, но я, похоже, больше не испытываю долгих зависаний. Кроме того, память серверов, похоже, не была причиной проблемы.

Когда возникает проблема, возникают ли у вас проблемы из-за того, что при входе на второй сервер будет предпринята попытка загрузить профиль с сервера NAS?

Насколько велики большие файлы? Он каждый раз блокирует сервер? Можете ли вы протестировать большую копию файла между двумя рабочими станциями и убедиться, что он работает правильно, когда AV работает на обоих (или на втором сервере).

Я знаю, что кто-то сказал выше, чтобы посмотреть на использование памяти Windows ....

Я бы посмотрел на драйверы сетевой карты, вы уже сказали, что драйверы обновлены, в этом случае я бы поискал более старый драйвер или отключил параметры разгрузки tcp для сетевой карты. Мне пришлось работать с MS из-за проблемы с сетью кластера Windows, при устранении неполадок хорошо отключить разгрузку nic.

HTH, Марк