Устранение неполадок, связанных с низкой производительностью архивации файлов и папок в службе архивации Azure

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

Прежде чем приступить к устранению неполадок, рекомендуется скачать и установить последнюю версию агента службы архивации Azure. Мы периодически обновляем агент службы архивации, чтобы устранить различные проблемы, добавить новые возможности и улучшить производительность.

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

Если проблема Azure не устранена в этой статье, посетите форумы Azure на форумах Microsoft Q и A и Stack Overflow. Описание своей проблемы можно опубликовать на этих форумах или написать в Twitter (@AzureSupport). Также можно отправить запрос в службу поддержки Azure. Чтобы отправить такой запрос, на странице поддержки Azure щелкните Получить поддержку.

Причина. Задание резервного копирования выполняется в неоптимизированном режиме

  • Агент MARS может запустить задание резервного копирования в оптимизированном режиме с помощью журнала изменений USN (порядковый номер обновления) или неоптимизированном режиме путем проверки всего тома на наличие изменений в каталогах или файлах.

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

  • Чтобы проверить режим, откройте сведения о задании из консоли агента MARS и проверьте, находится ли задание в состоянии Идет передача данных (без оптимизации, может занять определенное время), как показано ниже.

    Screenshot shows backup jobs running in unoptimized mode.

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

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

Причина: наличие узких мест производительности на компьютере

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

Windows предоставляет встроенное средство, системный монитор (Perfmon), для обнаружения этих узких мест.

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

Счетчик Состояние
Логический диск (физический диск) — % времени простоя
  • 100–50 % — работоспособное состояние
  • 49–20 % — состояние предупреждения или отслеживания
  • 19–0 % — критическое или недопустимое состояние.
  • Логический диск (физический диск) — среднее время выполнения операции чтения или записи на диске
  • 0,001–0,015 мс — работоспособное состояние
  • 0,015–0,025 мс — состояние предупреждения или отслеживания
  • 0,026 мс или больше — критическое или недопустимое состояние.
  • Логический диск (физический диск) — текущая длина очереди диска (для всех экземпляров) 80 запросов в течение более 6 минут
    Память — байт в невыгружаемом пуле
  • Потребление менее 60 % ресурсов пула — работоспособное состояние
  • 61–80 % — состояние предупреждения или отслеживания
  • Более 80 % — критическое или недопустимое состояние.
  • Память — байт в выгружаемом пуле
  • Потребление менее 60 % ресурсов пула — работоспособное состояние
  • 61–80 % — состояние предупреждения или отслеживания
  • Более 80 % — критическое или недопустимое состояние.
  • Доступная память (МБ)
  • 50 % свободной памяти или больше — работоспособное состояние
  • 25 % свободной памяти — состояние отслеживания
  • 10 % свободной памяти — состояние предупреждения
  • Менее 100 МБ или 5 % свободной памяти — критическое или недопустимое состояние.
  • Процессор — % загруженности процессора (все экземпляры)
  • Менее 60 % — работоспособное состояние
  • 61–90 % — состояние предупреждения или отслеживания
  • 91–100 % — критическое состояние.
  • Примечание.

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

    Причина: на работу службы архивации Azure влияет другой процесс или антивирусная программа

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

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

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

    • Все файлы и папки в местах для размещения временных файлов и корзины<InstallPath>\Scratch\* и <InstallPath>\Bin\*.
    • cbengine.exe

    Причина: агент службы архивации запущен на виртуальной машине Azure

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

    Причина: архивация большого количества файлов (нескольких миллионов)

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

    Причина этого состоит в том, что при архивации и переносе данных в Azure одновременно выполняется каталогизация файлов. Иногда операция каталогизации может занять больше времени, чем ожидалось.

    Ниже приведены признаки, которые помогут выявить узкие места и принять соответствующие меры.

    • В пользовательском интерфейсе отображается ход выполнения передачи данных. Идет перенос данных. Возможны задержки из-за пропускной способности сети или объема данных.
    • В пользовательском интерфейс не отображается ход выполнения передачи данных. В этом случае необходимо открыть файлы журналов в папке C:\Program Files\Microsoft Azure Recovery Services Agent\Temp и проверить в них наличие записи FileProvider::EndData. Наличие этой записи означает, что передача данных завершена, и выполняется операция каталогизации. Не отменяйте задание архивации. Вместо этого подождите еще немного, пока не завершится операция каталогизации. Если проблема не исчезла, обратитесь в службу поддержки Azure.

    При попытке резервного копирования больших дисков рекомендуется использовать Azure Data Box для создания первой резервной копии (начальной репликации). Если вы не можете использовать Data Box, то любые временные сетевые проблемы, происходящие в среде во время длительной передачи данных по сети, могут вызвать сбои резервного копирования. Для защиты от этих сбоев можно включить несколько папок в начальную резервную копию и постепенно добавлять папки до тех пор, пока все они не будут успешно архивированы в Azure. Последующие добавочные резервные копии будут создаваться относительно быстро.

    Следующие шаги