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

  • Статья

Примечание.

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

В этой статье перечислены распространенные проблемы, связанные с производительностью файловых ресурсов 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

Примечание.

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

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

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

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

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

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

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

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

Важно!

Для учетных записей хранения уровня "Стандартный" с поддержкой больших общих папок (LFS) регулирование выполняется на уровне учетной записи. Для общих папок уровня "Премиум" и общих папок уровня "Стандартный" без включения LFS регулирование выполняется на уровне общего ресурса.

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

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

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

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

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

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

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

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

    • 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, это позволяет выполнять операции с метаданными локально. Настройка обеспечивает производительность, аналогичную производительности локального напрямую подключенного хранилища. Однако, так как данные находится в виртуальном жестком диске, к ним нельзя получить доступ с помощью каких-либо других средств, кроме подключения SMB, таких как REST API или через портал Azure.

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

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

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

Решение

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

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

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

Решение

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

Причина 5. Размер перед чтением слишком мал (только NFS)

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

Решение

Рекомендуется увеличить read_ahead_kb значение параметра ядра до 15 мебибайт (МиБ). Чтобы изменить это значение, постоянно задайте размер для чтения, добавив правило в 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 параметр подключения может привести к выполнению lsstat команды для каждой записи каталога. Такое поведение приводит к снижению производительности при перечислении большого каталога. Параметры подключения можно проверка в записи /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 Multichannel без повторного подключения.

Решение

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

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

В зависимости от используемого метода сжатия и операции распаковки операции распаковки могут выполняться медленнее в общей папке Azure, чем на локальном диске. Это часто связано с тем, что средства распаковки выполняют ряд операций с метаданными в процессе распаковки сжатого архива. Для максимальной производительности рекомендуется скопировать сжатый архив из общей папки Azure на локальный диск, распакуть его, а затем использовать средство копирования, например Robocopy (или AzCopy), для копирования в общую папку Azure. С помощью средства копирования, например 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.