Поделиться через

Устранение неполадок с производительностью Файлы Azure

  • Статья

Примечание.

CentOS, на который ссылается в этой статье, является дистрибутивом Linux и достигнет конца жизни (EOL). Думайте об использовании и планировании соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.

В этой статье перечислены распространенные проблемы, связанные с производительностью общей папки Azure, а также возможные причины и обходные пути. Чтобы получить наибольшее значение из этого руководства по устранению неполадок, рекомендуется сначала прочитать общие сведения о производительности Файлы Azure.

Применяется к

Тип общей папки SMB NFS
Стандартные общие папки (GPv2), LRS/ZRS
Стандартные общие папки (GPv2), GRS/GZRS
Общие папки уровня "Премиум" (FileStorage), LRS/ZRS

Общие способы устранения неполадок с производительностью

Во-первых, исключите некоторые распространенные причины, по которым могут возникнуть проблемы с производительностью.

Вы используете старую операционную систему

Если виртуальная машина клиента работает под управлением Windows 8.1 или Windows Server 2012 R2 или более старой версии дистрибутива Или ядра Linux, при доступе к общим папкам Azure могут возникнуть проблемы с производительностью. Обновите клиентную ОС или примените приведенные ниже исправления.

Рекомендации по Windows 8.1 и Windows Server 2012 R2

Клиенты под управлением Windows 8.1 или Windows Server 2012 R2 могут видеть более высокую задержку при доступе к общим папкам Azure для рабочих нагрузок с интенсивным вводом-выводом. Убедитесь, что установлен KB3114025 исправление. Это исправление повышает производительность операций создания и закрытия дескрипторов.

Выполните следующий сценарий, чтобы проверить, установлено ли это исправление.

reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies

Если установлен исправление, отображаются следующие выходные данные:

HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1

Примечание.

Начиная с декабря 2015 года в образах Windows Server 2012 R2, содержащихся в Azure Marketplace, исправление KB3114025 установлено по умолчанию.

Рабочая нагрузка регулируется

Запросы регулируются при достижении предельных значений для объема операций ввода-вывода в секунду и входящего или исходящего трафика для общей папки. Например, если клиент превышает базовое число операций ввода-вывода в секунду, служба Файлы Azure применяет к нему регулирование. Регулирование может привести к снижению производительности на стороне клиента.

Сведения об ограничениях для файловых ресурсов уровня "Стандартный" и "Премиум" см. в разделе Общие папки и целевые объекты масштабирования файлов. В зависимости от рабочей нагрузки регулирование часто можно избежать, перейдя из уровня «Стандартный» в общие папки Azure уровня «Премиум».

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

Высокая задержка, низкая пропускная способность или низкое число операций ввода-вывода в секунду

Причина 1. Регулирование учетной записи общего доступа или хранения

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

Внимание

Для стандартных учетных записей хранения регулирование выполняется на уровне учетной записи хранения. Для общих папок уровня "Премиум" регулирование происходит на уровне общего ресурса.

  1. Войдите в свою учетную запись хранения на портале Azure.

  2. В области слева в разделе Мониторинг выберите Метрики.

  3. Выберите Файл в качестве пространства имен метрик для области своей учетной записи хранения.

  4. Выберите Транзакции в качестве метрики.

  5. Добавьте фильтр для Тип ответа, а затем проверьте, не регулировались ли какие-либо запросы.

    Для стандартных файловых ресурсов регистрируются следующие типы ответов, если запрос регулируется на уровне учетной записи клиента:

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Для общих папок уровня премиум при регулировании запроса в журнале регистрируются следующие типы ответов:

    • SuccessWithShareEgressThrottling
    • SuccessWithShareIngressThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareEgressThrottlingError
    • ClientShareIngressThrottlingError
    • ClientShareIopsThrottlingError

    Если запрос с регулированием прошел проверку подлинности с помощью Kerberos, может появиться префикс, указывающий на протокол проверки подлинности, например:

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

    Дополнительные сведения о каждом типе ответа см. в разделе Измерения метрик.

    Снимок экрана: фильтр свойств

Решение

Если используется общая папка уровня "Премиум", увеличьте размер подготовленной общей папки, чтобы увеличить максимальное число операций ввода-вывода в секунду. Дополнительные сведения см. в разделе Основные сведения о подготовке общих папок уровня "Премиум".

Причина 2. Рабочая нагрузка с интенсивным использованием метаданных или пространства имен

Если большинство запросов ориентированы на метаданные (например, createfile, openfile, closefile, queryinfo или querydirectory), задержка будет большей, чем в случае операций чтения и записи.

Чтобы определить, ориентировано ли большинство ваших запросов на метаданные, начните с выполнения шагов 1–4, как описано выше в разделе "Причина 1". На шаге 5 вместо добавления фильтра для типа ответа добавьте фильтр свойств для имени API.

Снимок экрана: фильтр свойств

Методы обхода проблемы

  • Проверьте, можно ли изменить приложение, чтобы сократить количество операций с метаданными.

  • Если вы используете общие папки Azure уровня премиум для малых и средних компаний (SMB), используйте кэширование метаданных.

  • Разделите общую папку на несколько общих папок в одной учетной записи хранения.

  • Добавьте виртуальный жесткий диск (VHD) для общей папки и подключите его на клиенте для выполнения файловых операций с данными. Этот вариант подходит для отдельных сценариев записи и чтения или сценариев с несколькими модулями чтения без модуля записи. Так как файловая система принадлежит клиенту, а не службе "Файлы Azure", это обеспечивает локальность операций с метаданными. Выполнив установку, можно добиться производительности на уровне непосредственно подключенного локального хранилища. Тем не менее, так как данные находится на виртуальном жестком диске (VHD), доступ к ним нельзя получить с помощью других средств, отличных от подключения SMB, таких как REST API или через портал Azure.

    1. На компьютере, который должен получить доступ к общей папке Azure, подключите общую папку с помощью ключа учетной записи хранения и сопоставьте ее с доступным сетевым диском (например, Z:).
    2. Перейдите в раздел "Управление дисками" и выберите "Создать > виртуальный жесткий диск".
    3. Задайте Расположение сетевому диску, в котором отображен общий файловый ресурс Azure, задайте Размер виртуального жесткого диска по мере необходимости и выберите Фиксированный размер.
    4. Нажмите кнопку ОК. После завершения создания VHD он автоматически подключается, и появится новый нераспределенный диск.
    5. Щелкните новый неизвестный диск правой кнопкой мыши и выберите пункт Инициализировать диск.
    6. Щелкните правой кнопкой мыши нераспределенную область и создайте новый простой том.
    7. В Управлении дисками появится новая буква диска, представляющая этот VHD с доступом на чтение и запись (например, E:). В Проводнике вы увидите новый VHD на отображаемом сетевом диске общей папки Azure (Z: в этом примере). Для ясности, должно быть две буквы диска: стандартное сетевое сопоставление общей папки Azure в Z:, а также сопоставление VHD на диске E:
    8. При выполнении операций на тяжелых метаданных с файлами на подключенном диске VHD (E:) производительность должна быть гораздо выше, чем на подключенном диске общей папки Azure (Z:). При необходимости следует отключить отображаемый сетевой диск (Z:) и снова получить доступ к подключенному виртуальному жесткому диску (E:).
    • Чтобы подключить VHD на клиенте Windows, вы также можете использовать командлет PowerShell Mount-DiskImage.
    • Сведения о подключении VHD на Linux см. в документации по дистрибутиву Linux. Ниже приведен пример.

Причина 3. Однопотоковое приложение

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

Решение

  • Повысьте параллелизм приложений, увеличив число потоков.
  • Переключитесь на приложения, в которых возможен параллелизм. Например, для операций копирования можно использовать AzCopy или RoboCopy из клиентов Windows или команду parallel из клиентов Linux.

Причина 4. Число каналов SMB превышает четыре

Если вы используете многоканальный протокол SMB и число каналов превышает четыре, это приведет к снижению производительности. Чтобы определить, превышает ли число подключений четыре, используйте командлет PowerShell get-SmbClientConfiguration для просмотра текущих параметров счетчика подключений.

Решение

Задайте параметр Windows для каждого сетевого адаптера для SMB, чтобы общее число каналов не превышало четырех. Например, если у вас есть два сетевых адаптера, максимальное число каналов для каждого сетевого адаптера может равняться двум, для этого используйте командлет PowerShell: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Причина 5. Слишком малый размер для чтения (только NFS)

Начиная с версии 5.4 ядра Linux клиент Linux NFS использует значение по умолчанию read_ahead_kb 128 кибибайт (KiB). Это небольшое значение может уменьшить объем пропускной способности чтения для больших файлов.

Решение

Рекомендуется увеличить read_ahead_kb значение параметра ядра до 15 мбибайт (MiB). Чтобы изменить это значение, задайте размер перед чтением постоянно, добавив правило в udev, диспетчер устройств ядра Linux. Выполните следующие действия:

  1. В текстовом редакторе создайте файл /etc/udev/rules.d/99-nfs.rules , введя и сохраняя следующий текст:

    SUBSYSTEM=="bdi" \
, ACTION=="add" \
, PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
, ATTR{read_ahead_kb}="15360"

  2. В консоли примените правило udev, выполнив команду udevadm в качестве суперпользователя и перезагрузив файлы правил и другие базы данных. Чтобы сделать udev осведомленным о новом файле, необходимо выполнить эту команду только один раз.

    sudo udevadm control --reload

Очень высокая задержка для запросов

Причина

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

Решение

  • Запустите приложение из виртуальной машины, расположенной в том же регионе, что и общая папка.
  • Для учетной записи хранения проверьте метрики транзакций SuccessE2ELatency и SuccessServerLatency с помощью Azure Monitor на портале Azure. Большая разница между значениями метрик SuccessE2ELatency и SuccessServerLatency указывает на то, что задержка может быть вызвана сетью или клиентом. См. раздел Метрики транзакций в справочнике по данным мониторинга службы "Файлы Azure".

Клиенту не удалось достичь максимальной пропускной способности, поддерживаемой сетью

Причина

Одной из потенциальных причин является отсутствие поддержки нескольких каналов SMB для общей папки уровня "Стандартный". В настоящее время Файлы Azure поддерживает только один канал для стандартных общих папок, поэтому на сервере есть только одно подключение с клиентской виртуальной машины. Это отдельное подключение привязано к одному ядру на клиентской виртуальной машине, поэтому максимальная пропускная способность, достижимая с виртуальной машины, ограничивается одним ядром.

Обходное решение

Низкая производительность файлового ресурса Azure, подключенного к виртуальной машине Linux

Причина 1: кэширование

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

Решение для причины 1

Чтобы проверить, отключено ли кэширование, найдите запись cache=.

Cache=none указывает, что кэширование отключено. Повторно подключите общедоступный ресурс, введя команду подключения по умолчанию или явно добавив в нее параметр cache=strict, чтобы включить режим кэширования по умолчанию или «строгий» режим кэширования соответственно.

В некоторых сценариях параметр подключения serverino может привести к тому, что команда ls запускает stat для каждой записи каталога. Это приводит к снижению производительности при выводе содержимого большого каталога. Параметры подключения можно просмотреть в записи /etc/fstab.

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

Можно также проверить, правильные ли параметры используются, выполнив команду sudo mount | grep cifs и проверив ее выходные данные. Ниже представлен пример таких выходных данных:

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

Если параметр cache=strict или serverino отсутствует, отключите и повторно подключите службу файлов Azure, выполнив команду mount из этой документации. Затем еще раз проверьте наличие правильных параметров в записи /etc/fstab.

Причина 2: регулирование полосы пропускания

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

Решение для причины 2

Убедитесь, что приложение находится в целевых объектах масштабирования службы Файлы Azure. Если вы используете стандартные общие папки Azure, попробуйте перейти на премиум.

Пропускная способность клиентов Linux ниже, чем у клиентов Windows

Причина

Это известная проблема с реализацией клиента SMB в Linux.

Обходное решение

  • Распределите нагрузку между несколькими виртуальными машинами.
  • Используйте на той же виртуальной машине несколько точек подключения с параметром nosharesock и распределите нагрузку между этими точками подключения.
  • В Linux попробуйте выполнить подключение с параметром nostrictsync, чтобы избежать принудительной записи на диск данных SMB при каждом вызове fsync. Для службы "Файлы Azure" этот параметр не влияет на согласованность данных, но может привести к наличию устаревших метаданных файла в списках каталогов (команда ls -l). Непосредственное выполнение запросов к метаданным файла с помощью команды stat приведет к возврату наиболее актуальных метаданных файла.

Высокие задержки для рабочих нагрузок с интенсивным использованием метаданных и большим числом операций открытия и закрытия

Причина

Отсутствие поддержки аренды каталогов.

Обходное решение

  • По возможности избегайте чрезмерной обработки операций открытия и закрытия для одного и того же каталога в течение короткого периода времени.
  • Для виртуальных машин Linux увеличьте время ожидания кэша записи каталога, указав actimeo=<sec> в качестве параметра подключения. По умолчанию время ожидания равно 1 секунде, поэтому большее значение, например 30 секунд, может помочь.
  • Для виртуальных машин с CentOS Linux или Red Hat Enterprise Linux (RHEL) обновите систему до CentOS Linux 8.2 или RHEL 8.2. Для других дистрибутивов Linux обновите ядро до версии 5.0 или более поздней версии.

Медленное перечисление файлов и папок

Причина

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

Решение

Чтобы устранить эту проблему, настройте значение реестра DirectoryCacheEntrySizeMax, чтобы разрешать кэшировать большие списки каталогов на компьютере клиента.

  • Расположение: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
  • Имя значения: DirectoryCacheEntrySizeMax
  • Тип значения: DWORD

Например, вы можете установить значение 0x100000 и посмотреть, повысится ли производительность.

Медленное копирование файлов в общие папки Azure и из них

При попытке передать файлы в службу файлов Azure можно наблюдать низкую производительность. Если определенные требования к минимальному размеру операций ввода-вывода отсутствуют, для оптимальной производительности мы рекомендуем использовать 1 МиБ.

Медленное копирование файлов в службе файлов Azure и из нее в Windows

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

  • Используйте правильный метод копирования:

    • Используйте AZCopy для передачи данных между двумя файловыми ресурсами.
    • Используйте Robocopy для передачи данных между файловыми ресурсами и локальным компьютером.

Чрезмерное число вызовов DirectoryOpen и DirectoryClose

Причина

Если число вызовов DirectoryOpen и DirectoryClose — это один из основных типов вызовов API, а вы не рассчитывали, что клиент будет осуществлять так много вызовов, эта неполадка может быть вызвана антивирусной программой, установленной на виртуальной машине клиента Azure.

Обходное решение

Исправление для этой проблемы доступно в апрельском обновлении платформы для Windows.

SMB Multichannel не активируется

Причина

Последние изменения параметров конфигурации многоканального доступа по SMB без повторного подключения.

Решение

  • После внесения изменений в параметры конфигурации клиента или учетной записи SMB для Windows SMB необходимо отключить общую папку, дождаться 60 секунд и повторно подключить общую папку, чтобы активировать многоканальный модуль.
  • Для клиентской ОС Windows создайте нагрузку ввода-вывода с большой глубиной очереди, скажем QD=8, например, путем копирования файла для активации многоканального подключения по SMB. Для серверной ОС многоканальное подключение по SMB активируется при длине очереди 1, то есть как только вы начнете любую операцию ввода-вывода в общей папке.

Низкая производительность при распаковке файлов

В зависимости от точного метода сжатия и используемой операции распаковки распаковка в общей папке Azure может выполняться медленнее, чем на локальном диске. Часто это происходит из-за того, что средства распаковки выполняют ряд операций с метаданными при распаковке сжатого архива. Для обеспечения максимальной производительности рекомендуется скопировать сжатый архив из общей папки Azure на локальный диск, распаковать его там, а затем скопировать полученные файлы обратно в общую папку Azure с помощью такого инструмента как Robocopy (или AzCopy). С помощью таких инструментов копирования как Robocopy можно компенсировать снижение производительности операций с метаданными в Файлах Azure по сравнению с локальным диском за счет использования нескольких потоков для параллельного копирования данных.

Высокая задержка на веб-сайтах, размещенных в общих папках

Причина

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

Чтобы подтвердить, на портале можно использовать метрики Azure.

  1. Войдите в свою учетную запись хранения на портале Azure.
  2. В меню слева в разделе Мониторинг выберите Метрики.
  3. Выберите Файл в качестве пространства имен метрик для области своей учетной записи хранения.
  4. Выберите Транзакции в качестве метрики.
  5. Добавьте фильтр для ResponseType и проверьте наличие кода SuccessWithThrottling ответа (для SMB или NFS) или ClientThrottlingError (для REST).

Решение

  • Если уведомление об изменении файла не используется, отключите уведомление об изменении файла (предпочтительно).

  • Увеличьте частоту интервала опроса уведомлений об изменении файла, чтобы уменьшить объем.

    Обновите интервал опроса рабочего процесса W3WP до более высокого значения (например, 10 или 30 минут) на основе вашего требования. Задайте HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds в реестре и перезапустите процесс W3WP.

  • Если сопоставленный физический каталог веб-сайта содержит вложенную структуру каталогов, можно попытаться ограничить область уведомлений об изменении файла, чтобы уменьшить объем уведомлений. По умолчанию СЛУЖБЫ IIS используют конфигурацию из файлов web.config в физическом каталоге, с которым сопоставляется виртуальный каталог, а также в любых дочерних каталогах в этом физическом каталоге. Если вы не хотите использовать файлы Web.config в дочерних каталогах, укажите false атрибут allowSubDirConfig в виртуальном каталоге. Дополнительные сведения можно найти здесь.

    Задайте параметр виртуального каталога allowSubDirConfig IIS в Web.Config , чтобы false исключить сопоставленные физические дочерние каталоги из области.

См. также

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.