Прочитать на английском

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


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

Низкое число операций ввода-вывода в секунду в CentOS Linux или RHEL

Причина

Глубина ввода-вывода больше 1 не поддерживается в старых версиях CentOS Linux или RHEL.

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

  • Обновление до CentOS Linux 8.6+ или RHEL 8.6+.
  • Перейдите на Ubuntu.
  • Для других виртуальных машин с Linux обновите ядро до 5.0 или более поздней версии.

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

    • SuccessWithShareEgressThrottling
    • Успех с разделением входного ограничения скорости
    • Успех с регулировкой IOPS в совместном использовании
    • Ошибка ограничения исходящего трафика ClientShare
    • Ошибка ограничения скорости входа ClientShare
    • ClientShareIopsThrottlingError

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

    • Kerberos успех с ограничением исходящей скорости совместного доступа
    • KerberosSuccessWithShareIngressThrottling

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

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

Решение

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

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

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

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

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

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

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

  • Если вы используете общие папки 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 путем создания оповещений.

Решение проблемы 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 или более поздней версии.

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

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

Объем доступной памяти влияет на количество хэш-контейнеров инодов в системе, что улучшает производительность перечисления для больших каталогов. Можно изменить количество хэш-ведер inode в системе, чтобы уменьшить количество хэш-конфликтов, которые могут возникать при больших рабочих нагрузках перечисления. Инструкции см. в разделе "Увеличение количества хэш-контейнеров".

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

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

Медленное копирование файлов в Azure Files и из Azure Files в Linux

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

    • Используйте AZCopy для передачи данных между двумя файловыми ресурсами.
    • Использование cp или dd с параллелизмом может повысить скорость копирования. Количество потоков зависит от варианта использования и рабочей нагрузки. В следующих примерах используется шесть:
      • Пример cp (в качестве размера блока cp будет использовать размер блока по умолчанию файловой системы): find * -type f | parallel --will-cite -j 6 cp {} /mntpremium/ &.
      • Пример dd (эта команда явно устанавливает размер блока, равный 1 МиБ): find * -type f | parallel --will-cite-j 6 dd if={} of=/mnt/share/{} bs=1M.
    • Средства сторонних разработчиков с открытым кодом, например: - GNU Parallel. - Fpart — сортирует файлы и упаковывает их в разделы. - Fpsync — использует Fpart и средство копирования для создания нескольких экземпляров и переноса данных из src_dir в dst_url. - Multi — многопоточные cp и md5sum, основанные на GNU coreutils.
  • Если задать размер файла заранее, чтобы каждый раз не использовать расширенную запись, это поможет повысить скорость копирования в сценариях с известным размером файла. Если нужно избежать расширения записи, можно задать размер целевого файла с помощью команды truncate --size <size> <file>. После этого команда dd if=<source> of=<target> bs=1M conv=notrunc скопирует исходный файл без необходимости постоянного обновления размера целевого файла. Например, можно задать размер целевого файла для каждого файла, который требуется скопировать (предположим, что общая папка подключена в /mnt/share):

    for i in `` find * -type f``; do truncate --size ``stat -c%s $i`` /mnt/share/$i; done

    Параллельно скопируйте файлы, не расширяя записи параллельно:

    find * -type f | parallel -j6 dd if={} of =/mnt/share/{} bs=1M conv=notrunc

Чрезмерное число вызовов 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.