Устранение неполадок с производительностью Файлы 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

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

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

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

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

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

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

Решение

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

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

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

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

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

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

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

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

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

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

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