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


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

Ваша рабочая нагрузка ограничивается

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

    • Ошибка ограничения запросов клиента аккаунта
    • Ошибка регулирования пропускной способности аккаунта клиента

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

    • SuccessWithShareEgressThrottling
    • Успех с разделением входного ограничения скорости
    • Успех с регулировкой IOPS в совместном использовании
    • ClientShareEgressThrottlingError
    • Ошибка ограничения скорости входа ClientShare
    • 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. Перейдите в раздел "Управление дисками" и выберите Действие > Создать VHD (виртуальный жесткий диск).
    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: Однопотоковое приложение

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

Решение

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

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

Низкая производительность файлового ресурса 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 Files путём создания уведомлений.

Решение проблемы 2

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

Причина 3: Файловое хранилище Azure достигает предела емкости.

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

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

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

	cd /path/to/mount/point
	du -ah --max-depth=1 | sort -rh | head -n 20

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

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

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

Причина

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

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

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

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

Причина

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

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

  • По возможности избегайте слишком частого открытия и закрытия одного и того же каталога в течение короткого периода времени.
  • Для виртуальных машин 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 Files и из нее в 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.