Solución de problemas de rendimiento en cuentas de Almacenamiento de Azure

Este artículo le ayuda a investigar cambios inesperados en el comportamiento (por ejemplo, tiempos de respuesta más lentos que habituales). Estos cambios en el comportamiento a menudo se pueden identificar supervisando las métricas de almacenamiento en Azure Monitor. Para obtener información general sobre el uso de métricas y registros en Azure Monitor, consulte los siguientes artículos:

• Supervisión de Azure Blob Storage
• Supervisión de Azure Files
• Supervisión de Azure Queue Storage
• Supervisión de Azure Table Storage

Supervisión del rendimiento

Para supervisar el rendimiento de los servicios de almacenamiento, puede usar las métricas siguientes:

• Las métricas SuccessE2ELatency y SuccessServerLatency muestran el tiempo medio que tarda el tipo de operación de API o servicio de almacenamiento en procesar las solicitudes. SuccessE2ELatency es una medida de latencia de un extremo a otro que incluye el tiempo necesario para leer la solicitud y enviar la respuesta además del tiempo necesario para procesar la solicitud (por lo tanto, incluye latencia de red una vez que la solicitud alcanza el servicio de almacenamiento). SuccessServerLatency es una medida de solo el tiempo de procesamiento y, por tanto, excluye cualquier latencia de red relacionada con la comunicación con el cliente.

• Las métricas Egress e Ingress muestran la cantidad total de datos, en bytes, que entran en el servicio de almacenamiento o salen de él, o que atraviesan un tipo de operación de API específico.

• La métrica Transactions muestra el número total de solicitudes que está recibiendo la operación de API o el servicio de almacenamiento. Las transacciones son el número total de solicitudes que recibe el servicio de almacenamiento.

Puede supervisar si hay cambios inesperados en cualquiera de estos valores. Estos cambios podrían indicar un problema que deba investigarse con más detalle.

En Azure Portal, puede agregar reglas de alerta que le notifiquen cuando cualquiera de las métricas de rendimiento de este servicio se encuentra por debajo o supera un umbral que especifique.

Diagnóstico de problemas de rendimiento

El rendimiento de una aplicación puede ser subjetivo, especialmente desde el punto de vista de los usuarios. Por ello, es importante tener métricas de línea base disponibles con las que le resulte más fácil identificar los casos en los que puede haber un problema de rendimiento. Hay muchos factores que pueden afectar al rendimiento de un servicio de almacenamiento de Azure desde la perspectiva de la aplicación cliente. Estos factores pueden funcionar en el servicio de almacenamiento, el cliente o la infraestructura de red. Por lo tanto, es importante tener una estrategia para identificar el origen del problema de rendimiento.

Después de identificar, a partir de las métricas, la ubicación donde es más probable que se encuentre el motivo del problema de rendimiento, puede usar los archivos de registro para buscar información detallada que le permita seguir diagnosticando y solucionando el problema.

Las métricas muestran un valor de SuccessE2ELatency alto y un valor de successServerLatency bajo

En algunos casos, es posible que encuentre que SuccessE2ELatency es mayor que SuccessServerLatency. El servicio de almacenamiento solo calcula la métrica SuccessE2ELatency de las solicitudes correctas y, a diferencia de SuccessServerLatency, incluye el tiempo que tarda el cliente en enviar los datos y recibir la confirmación del servicio de almacenamiento. Por lo tanto, una diferencia entre SuccessE2ELatency y SuccessServerLatency podría deberse a que la aplicación cliente es lenta para responder o debido a condiciones en la red.

Nota:

También puede ver el valor de E2ELatency y ServerLatency de cada operación de almacenamiento individual en los datos de registro del registro de almacenamiento.

Investigación de problemas de rendimiento del cliente

Las posibles razones para que el cliente responda lentamente incluyen tener conexiones o subprocesos disponibles limitados o estar bajos en recursos como CPU, memoria o ancho de banda de red. Puede resolver el problema modificando el código de cliente para que sea más eficaz (por ejemplo, mediante llamadas asincrónicas al servicio de almacenamiento) o mediante una máquina virtual más grande con más núcleos y más memoria.

En el caso de los servicios de tabla y cola, el algoritmo nagle también puede provocar una alta latencia successE2ELatency en comparación con SuccessServerLatency. Para obtener más información, consulte la publicación Algoritmo de Nagle no es descriptivo para solicitudes pequeñas. Puede deshabilitar el algoritmo de Nagle en el código mediante la ServicePointManager clase en el System.Net espacio de nombres . Debe hacer esto antes de realizar ninguna llamada a Table service o Queue service en la aplicación, dado que esta acción no afecta a las conexiones que ya están abiertas. El ejemplo siguiente procede del Application_Start método en un rol de trabajo:

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

Debe comprobar los registros del lado cliente para ver cuántas solicitudes envía la aplicación cliente y comprobar si hay cuellos de botella generales relacionados con .NET en el cliente, como CPU, recolección de elementos no utilizados de .NET, uso de red o memoria. Como punto de partida para solucionar los problemas de las aplicaciones cliente .NET, consulte Debugging, Tracing, and Profiling(Depuración, seguimiento y generación de perfiles).

Investigación de problemas de latencia de red

Normalmente, la latencia de un extremo a otro provocada por la red se debe a estados transitorios. Puede investigar problemas de red transitorios y persistentes, como paquetes descartados, mediante herramientas como Wireshark.

Las métricas muestran un valor de SuccessE2ELatency bajo y un valor de SuccessServerLatency bajo, pero el cliente tiene una latencia alta

En este escenario, la causa más probable es un retraso en la solicitud de almacenamiento que llega al servicio de almacenamiento. Debe investigar por qué las solicitudes del cliente no se realizan a través del servicio de blobs.

Un posible motivo de que el cliente envíe las solicitudes con retraso es que haya un número limitado de subprocesos o conexiones disponibles.

Además, compruebe si el cliente está realizando varios reintentos e investigue el motivo si es así. Para determinar si el cliente está realizando varios reintentos, puede:

• Examinar los registros. Si se producen varios reintentos, verá varias operaciones con los mismos identificadores de solicitud de cliente.

• Examinar los registros de cliente. Los registros detallados indicarán que se ha producido un reintento.

• Depure el código y compruebe las propiedades del OperationContext objeto asociado a la solicitud. Si se ha reintentado la operación, la RequestResults propiedad incluirá varias solicitudes únicas. También puede comprobar los tiempos de inicio y finalización de cada solicitud.

Si no hay ningún problema en el cliente, debe investigar los problemas de red potenciales, como la pérdida de paquetes. Puede usar herramientas como Wireshark para investigar problemas de red.

Las métricas muestran un valor de SuccessServerLatency alto

En el caso de que SuccessServerLatency de las solicitudes de descarga de BLOB sea alto, debe usar los registros del Almacenamiento para ver si se repiten varias solicitudes del mismo BLOB (o conjunto de BLOB). En el caso de las solicitudes de carga de blobs, debe investigar el tamaño de bloque que usa el cliente (por ejemplo, los bloques de menos de 64 K de tamaño pueden dar lugar a sobrecargas a menos que las lecturas también estén en menos de 64 K fragmentos) y si varios clientes cargan bloques en el mismo blob en paralelo. También debe comprobar las métricas por minuto para ver los picos en el número de solicitudes que dan lugar a superar los objetivos de escalabilidad por segundo.

Si ve una alta latencia successServerLatency para las solicitudes de descarga de blobs cuando hay solicitudes repetidas para el mismo blob o conjunto de blobs, considere la posibilidad de almacenar en caché estos blobs mediante Azure Cache o Azure Content Delivery Network (CDN). Con las solicitudes de carga, puede mejorar el rendimiento utilizando un tamaño de bloques mayor. Para realizar consultas a tablas, también se puede implementar el almacenamiento en caché del lado cliente en los clientes que realizan las mismas operaciones de consulta y cuando los datos no suelen cambiar.

Si los valores de SuccessServerLatency son altos, esto también puede ser síntoma de un diseño poco adecuado de las tablas o las consultas que genere operaciones de examen o que siga el antipatrón anexar/anteponer.

Nota:

Puede encontrar una lista de comprobación completa del rendimiento de Microsoft Azure Storage y lista de comprobación de escalabilidad.

Observa retrasos inesperados en la entrega de mensajes de una cola

Si experimenta un retraso entre el momento en que una aplicación agrega un mensaje a una cola y el tiempo que está disponible para leer desde la cola, siga estos pasos para diagnosticar el problema:

• Compruebe que la aplicación está agregando correctamente los mensajes a la cola. Compruebe que la aplicación no vuelva a intentar el AddMessage método varias veces antes de que se realice correctamente.

• Compruebe que no hay asimetría de reloj entre el rol de trabajo que agrega el mensaje a la cola y el rol de trabajo que lee el mensaje de la cola. Una asimetría de reloj hace que aparezca como si hubiera un retraso en el procesamiento.

• Compruebe si el rol de trabajo que lee los mensajes de la cola no está funcionando correctamente. Si un cliente de cola llama al GetMessage método pero no responde con una confirmación, el mensaje permanecerá invisible en la cola hasta que expire el invisibilityTimeout período. En ese momento, el mensaje volverá a estar disponible para el procesamiento.

• Compruebe si la longitud de la cola aumenta con el tiempo. Esto puede ocurrir si no tiene suficientes trabajos disponibles para procesar todos los mensajes que otros trabajos están colocando en la cola. Además, compruebe las métricas para ver si se producen errores en las solicitudes de eliminación y el recuento de puesta en cola en los mensajes, lo que podría indicar intentos erróneos repetidos para eliminar el mensaje.

• Examine los registros del Almacenamiento para ver si hay operaciones de la cola que tengan valores de E2ELatency y ServerLatency superiores a los que se esperaban durante un período de tiempo más largo de lo habitual.

Consulte también

• Solución de problemas de errores de la aplicación cliente
• Solución de problemas de disponibilidad
• Supervisar, diagnosticar y solucionar problemas de Azure Storage

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.