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

Статья
11/20/2024

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

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

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

Метрики SuccessE2ELatency и SuccessServerLatency отражают среднее время, затрачиваемое службой хранилища или операцией API на обработку запросов. SuccessE2ELatency — это мера сквозной задержки, которая включает время, затраченное на чтение запроса и отправку ответа в дополнение к времени, затраченного на обработку запроса (поэтому оно включает задержку сети после того, как запрос достигнет службы хранилища). SuccessServerLatency — это мера просто времени обработки и, следовательно, исключает любую задержку сети, связанную с взаимодействием с клиентом.
Метрики Egress и Ingress показывают общий объем данных (в байтах), передаваемых в службу хранилища и из нее или получаемых и отправляемых с помощью определенной операции API.
Метрика Transactions показывает общее число запросов, получаемых службой хранилища или операцией 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 используйте статью Debugging, Tracing, and Profiling (Отладка, трассировка и профилирование).

Изучение проблем, связанных с задержками в сети

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

Метрики содержат низкие значения показателей SuccessE2ELatency и SuccessServerLatency, но клиент сталкивается с большой задержкой

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

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

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

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

Если в клиенте неполадки не обнаружены, проверьте, нет ли проблем в сети (например, потери пакетов). Вы можете применить Wireshark или другие средства для анализа сетевых проблем.

Метрики отражают высокое значение показателя SuccessServerLatency

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

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

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

Примечание.

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

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

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

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

См. также

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

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

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