SMB утверждал, что "медленный"

Сеть нашей компании (которую я считаю доменом Windows, работающим на сервере 2008) мучительно медленная. Ярким примером этого является копирование файлов через SMB - списки занимают минуты, а копирование файлов даже небольшого размера - еще дольше. Когда к нему обращаются по поводу проблемы, ИТ-менеджер (который, несмотря на любые другие его достоинства, очень упрямый и не очень технический человек) поднимает руки, становится очень оборонительным и дает оправдания вместо того, чтобы выслушивать и пытаться выяснить причину проблемы.

Теперь, осознавая, что человеческий элемент этой проблемы займет некоторое время и усилия, я остаюсь не в курсе, как технически опровергнуть его оправдания. В этом случае он утверждает, что SMB является проблемой, и что это «медленный» протокол. Есть ли какие-либо доказательства для этого утверждения (у меня есть только случайные встречные доказательства)? Каков наилучший способ добиться прогресса в этом аргументе?

SMB вполне может быть медленнее, чем некоторые другие протоколы обмена файлами, и вполне может быть быстрее, чем некоторые другие. Но это не важная часть.

Вместо того, чтобы выдвигать этот вопрос / аргумент, вы можете найти способ отойти от этого и спросить, является ли SMB настолько быстрым (или таким же медленным!), Как и должно быть. Например, можете ли вы передать файл с помощью FTP между сервером и рабочей станцией, который страдает от медлительности и видит заметный скачок производительности?

Поставщик может указать вам обзоры оборудования с установленной Windows, которые говорят о производительности файлового сервера.

По моему опыту, SMB более чем «достаточно быстр» в моей сети. Мы используем сеть 10 Гбит / с между серверами, и мы очень довольны производительностью файлового сервера с использованием SMB, и мы измерили хорошие скачки производительности на том же оборудовании в зависимости от того, используем ли мы сетевую карту 1 ГБ или 10 ГБ. SMB не проблема для нас.

Я бы, конечно, посмотрел на другие вещи в вашей сети - устарела ли инфраструктура, настроена ли она оптимально (например, все ли сетевые карты сервера настроены правильно для последних драйверов, работают должным образом с наилучшей возможной скоростью), такие вещи, как DNS и т. Д. если все настроено правильно, много ли в сети «мусорного» трафика, вызывающего замедление, антивирус настроен слишком параноидально (я видел, что это вызывает некоторые шокирующие замедления).

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

Хотя существуют более быстрые протоколы, чем SMB, это никоим образом не является медленным по своей сути.

Однако, возможно, он немного более восприимчив к внешним воздействиям, чем другие протоколы, это насыщенные серверы, насыщенные сегменты и т. Д.

Если бы я был азартным игроком, я бы заподозрил, что ваша сеть могла бы быть связана либо с редизайном, либо с некоторыми инвестициями, поскольку обычные офисные сети многих компаний не были модернизированы, чтобы учесть огромный рост интернет- и интранет-трафика, наблюдаемый в последние годы. Кроме того, существует разумная вероятность того, что серверы / серверы могут нуждаться в замене или переделке, чтобы получить от них максимум.

В любом случае я бы не стал уделять слишком много внимания тому, чтобы SMB был прямым виновником, скорее всего, он просто падший парень для плохой / старой сети и комплекта серверов.

Он имеет больше накладных расходов (для передачи), чем такие вещи, как NFS или FTP. Перечисление файлов больших каталогов может занять некоторое время - часть из-за SMB, часть из-за NTFS, другая из-за глупых вещей, которые различные версии Explorer и установленного программного обеспечения могут делать со стороны клиента. Некоторые вещи, такие как файловые базы данных (файлы Access, PST), не следует открывать по медленным (WAN) каналам, поскольку они плохо справляются с задержкой.

Сказав это, операции, которые вы описываете, не должны занимать много времени. Может быть, файловый сервер (ы?) Недостаточно. Возможно, у компании есть какое-то программное обеспечение как часть стандартной установки, которая замедляет работу. Возможно, неправильно настроен антивирусный сканер. Может быть, есть вирус. Может быть, есть связь WAN, о которой вы не знаете, между вами и сервером.

1. Список файлов быстрее, если вы делаете это из командной строки вместо Проводника?
2. Как насчет копирования?
3. Пингуйте сервер с вашего рабочего стола - какова задержка?
4. Сделайте трассировку - сколько прыжков между вами и сервером?

К сожалению, Нейт, мы не можем иметь дело напрямую с PHB. Ваша первая линия защиты здесь - это фактические метрики, как, например, сделать сравнение между передачей SMB и NFS.

Если у вас есть реальные цифры или статистика, подтверждающая ваши аргументы, вам не нужно будет так много работать с человеческим фактором. Статистика говорит: «Вот где проблема, и вот доказательство». Это твой аргумент.

Вы можете сузить это вообще? Имеет ли передача между серверами в одной подсети лучшие результаты? Как насчет передачи от одного клиента другому ( \\client\c$→ \\client\d$)?

Вы можете найти что-то простое, например, несоответствие дуплекса.

Я знаю, что это старый, но очень важный фактор, который нужно учитывать, - дисковый ввод-вывод. Если производительность записи на диск невероятно низкая из-за программного / материнского RAID-массива, а не аппаратного RAID-карты с выделенной памятью.

Нагрузка на сеть является фактором, но лучшее, что нужно сделать как системный администратор, - это взглянуть на Resource Monitor и проверить, откуда могут возникать узкие места, - осмотреть вкладку Overview, чтобы увидеть общий процессор, сеть, дисковый ввод-вывод, память и т. Д. Из этого преимущества вы можете увидеть, существует ли процесс-виновник или набор процессов, которые поглощают дисковый ввод-вывод, или утечка памяти (SQLServer.exe - экземпляр SBSMonitoring) и т. Д. Если существует сетевой процесс, использующий много пропускной способности, проверьте этот процесс и проверьте, сколько и какие хосты связаны с этим процессом. Это может быть много попыток взломать RDP на 3389. Я видел это раньше, и наше решение было удалить прямой доступ RDP и переключить конечных удаленных пользователей на VPN.

Надеюсь это поможет!