Устранение неполадок с производительностью в учетных записях хранения Azure

Статья
04/10/2024

Эта статья поможет вам исследовать непредвиденные изменения в поведении (например, время отклика замедленное, чем обычно). Эти изменения в поведении часто можно определить с помощью метрик хранилища в Azure Monitor. Общие сведения об использовании метрик и журналов в Azure Monitor см. в следующих статьях:

Мониторинг производительности

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

Метрики SuccessE2ELatency и SuccessServerLatency показывают среднее время, забираемое службой хранилища или типом операции API для обработки запросов. SuccessE2ELatency — это мера сквозной задержки, которая включает время, затраченное на чтение запроса и отправку ответа, а также время, затраченное на обработку запроса (следовательно, включает задержку в сети после того, как запрос достигает службы хранилища). SuccessServerLatency — это мера только времени обработки и, следовательно, исключает задержку в сети, связанную с обменом данными с клиентом.
Метрики исходящего трафика и входящего трафика показывают общий объем данных в байтах, поступающих в службу хранилища и выходящих из нее, или через определенный тип операции API.
Метрика Транзакции показывает общее количество запросов, которые получает служба хранилища операции API. Транзакции — это общее количество запросов, получаемых службой хранилища.

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

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

Диагностика проблем с производительностью

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

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

Метрики показывают высокий уровень SuccessE2ELatency и низкий уровень SuccessServerLatency

В некоторых случаях значение SuccessE2ELatency выше , чем SuccessServerLatency. Служба хранилища вычисляет метрику SuccessE2ELatency только для успешных запросов и, в отличие от SuccessServerLatency, включает время, необходимое клиенту для отправки данных и получения подтверждения от службы хранилища. Таким образом, разница между SuccessE2ELatency и SuccessServerLatency может быть вызвана медленной реакцией клиентского приложения или из-за условий в сети.

Примечание.

Вы также можете просмотреть E2ELatency и ServerLatency для отдельных операций хранения в данных журнала хранилища.

Изучение проблем с производительностью клиента

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

Для служб таблиц и очередей алгоритм Nagle также может привести к высокой производительности SuccessE2ELatency по сравнению с SuccessServerLatency. Дополнительные сведения см. в записи Алгоритм Nagle не подходит для небольших запросов. Вы можете отключить алгоритм Nagle в коде ServicePointManager с помощью класса в System.Net пространстве имен. Это следует сделать перед вызовами к службам таблиц или очередей в приложении, так как это не влияет на уже открытые подключения. Следующий пример получен из Application_Start метода в рабочей роли:

var connectionString = Constants.connectionString;
QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

Необходимо проверка журналы на стороне клиента, чтобы узнать, сколько запросов отправляет клиентское приложение, и проверка для общих узких мест производительности .NET в клиенте, таких как ЦП, сборка мусора .NET, использование сети или память. Отправную точку для устранения неполадок клиентских приложений .NET см. в статье Отладка, трассировка и профилирование.

Изучение проблем с задержкой сети

Как правило, высокая сквозная задержка, вызванная сетью, вызвана временными условиями. Вы можете исследовать как временные, так и постоянные проблемы с сетью, такие как удаленные пакеты, с помощью таких средств, как Wireshark.

Метрики показывают низкий уровень SuccessE2ELatency и низкий successServerLatency, но у клиента наблюдается большая задержка.

В этом сценарии наиболее вероятной причиной является задержка в запросе хранилища, достигаемом службы хранилища. Следует выяснить, почему запросы от клиента не передаются в службу BLOB-объектов.

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

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

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

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

Метрики показывают высокий уровень SuccessServerLatency

В случае высокого уровня SuccessServerLatency для запросов на скачивание BLOB-объектов следует использовать журналы хранилища, чтобы узнать, есть ли повторные запросы для одного и того же BLOB-объекта (или набора BLOB-объектов). Для запросов на отправку BLOB-объектов следует выяснить, какой размер блока используется клиентом (например, блоки размером менее 64 КБ может привести к дополнительным затратам, если операции чтения также не имеют меньше 64 тыс. блоков) и если несколько клиентов отправляют блоки в один и тот же BLOB-объект параллельно. Также следует проверка поминутные метрики для пиков числа запросов, которые приводят к превышению целевых показателей масштабируемости в секунду.

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

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

Примечание.

Полный контрольный список производительности можно найти в служба хранилища Microsoft Azure Контрольный список производительности и масштабируемости.

Возникают непредвиденные задержки при доставке сообщений в очереди

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

Убедитесь, что приложение успешно добавляет сообщения в очередь. Перед выполнением убедитесь, что приложение не повторяет AddMessage метод несколько раз.
Убедитесь, что между рабочей ролью, которая добавляет сообщение в очередь, и рабочей ролью, считывающей сообщение из очереди, нет перекоса часов. При перекосе часов оно выглядит так, как если бы обработка была отложена.
Проверьте, не завершается ли сбой рабочей роли, считывающей сообщения из очереди. Если клиент очереди вызывает GetMessage метод, но не отвечает подтверждением, сообщение остается невидимым в очереди до invisibilityTimeout истечения периода. На этом этапе сообщение снова становится доступным для обработки.
Проверьте, увеличивается ли длина очереди с течением времени. Это может произойти, если у вас недостаточно рабочих ролей для обработки всех сообщений, которые другие рабочие роли помещают в очередь. Кроме того, проверка метрики, чтобы узнать, не выполняются ли запросы на удаление, и количество списаний сообщений, что может указывать на повторные неудачные попытки удаления сообщения.
Проверьте журналы хранилища на наличие операций с очередью, которые имеют более высокие, чем ожидалось, значения E2ELatency и ServerLatency за более длительный период времени, чем обычно.

См. также

Свяжитесь с нами для получения помощи

Если у вас есть вопросы или вам нужна помощь, создайте запрос в службу поддержки или обратитесь за поддержкой сообщества Azure. Вы также можете отправить отзыв о продукте в сообщество отзывов Azure.