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

Este artículo le ayuda a investigar cambios inesperados en el comportamiento (como tiempos de respuesta más lentos de lo habitual). Estos cambios en el comportamiento a menudo se pueden identificar mediante la supervisión de 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 artículos siguientes:

• Supervisión Azure Blob Storage
• Azure Files de supervisión
• 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 siguientes métricas:

• Las métricas SuccessE2ELatency y SuccessServerLatency muestran el tiempo medio que tarda el servicio de almacenamiento o el tipo de operación de API 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 la latencia de red una vez que la solicitud llega al 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 de salida e entrada muestran la cantidad total de datos, en bytes, que entran y salen del servicio de almacenamiento o a través de un tipo de operación de API específico.

• La métrica Transacciones muestra el número total de solicitudes que recibe el servicio de almacenamiento de la operación de API. 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 requiere una investigación adicional.

En el 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 especificado.

Diagnóstico de problemas de rendimiento

El rendimiento de una aplicación puede ser subjetivo, especialmente desde la perspectiva del usuario. Por lo tanto, es importante tener métricas de línea base disponibles para ayudarle a identificar dónde podría haber un problema de rendimiento. Muchos factores 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.

Una vez que haya identificado la ubicación probable de la causa del problema de rendimiento a partir de las métricas, puede usar los archivos de registro para encontrar información detallada para diagnosticar y solucionar el problema más adelante.

Las métricas muestran una alta latencia SuccessE2ELatency y una baja successServerLatency

En algunos casos, es posible que descubra que SuccessE2ELatency es mayor que SuccessServerLatency. El servicio de almacenamiento solo calcula la métrica SuccessE2ELatency para las solicitudes correctas y, a diferencia de SuccessServerLatency, incluye el tiempo que el cliente tarda 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 en responder o debido a condiciones en la red.

Investigación de problemas de rendimiento del cliente

Los posibles motivos para que el cliente responda lentamente incluyen tener conexiones o subprocesos disponibles limitados o tener pocos 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, vea la publicación El algoritmo de Nagle no es descriptivo para las solicitudes pequeñas. Puede deshabilitar el algoritmo Nagle en el código mediante la ServicePointManager clase en el System.Net espacio de nombres. Debe hacerlo antes de realizar llamadas a los servicios de tabla o cola de la aplicación, ya que esto 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 de rendimiento 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 problemas de aplicaciones cliente de .NET, consulte Depuración, seguimiento y generación de perfiles.

Investigación de problemas de latencia de red

Normalmente, la latencia de extremo a extremo alta causada por la red se debe a condiciones transitorias. Puede investigar problemas de red transitorios y persistentes, como paquetes eliminados, mediante herramientas como Wireshark.

Las métricas muestran una baja latencia SuccessE2ELatency y una baja successServerLatency, pero el cliente experimenta 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 de Blob Service.

Una posible razón para que el cliente retrase el envío de solicitudes es que hay un número limitado de conexiones o subprocesos disponibles.

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

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

• Examine los registros de cliente. El registro detallado indicará que se ha producido un reintento.

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

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

Las métricas muestran una alta latencia successServerLatency

En el caso de successServerLatency alto para las solicitudes de descarga de blobs, debe usar los registros de Almacenamiento para ver si hay solicitudes repetidas para el mismo blob (o conjunto de blobs). 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 en busca de picos en el número de solicitudes que dan lugar a superar los objetivos de escalabilidad por segundo.

Si ve una alta 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). Para las solicitudes de carga, puede mejorar el rendimiento mediante un tamaño de bloque mayor. En el caso de las consultas a tablas, también es posible implementar el almacenamiento en caché del lado cliente en clientes que realizan las mismas operaciones de consulta y donde los datos no cambian con frecuencia.

Los valores altos de SuccessServerLatency también pueden ser un síntoma de tablas o consultas mal diseñadas que dan lugar a operaciones de examen o que siguen el antipatrón append/prepend.

Está experimentando retrasos inesperados en la entrega de mensajes en una cola

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

• Compruebe que la aplicación agrega correctamente los mensajes a la cola. Compruebe que la aplicación no vuelva a intentar el AddMessage método varias veces antes de realizarlo correctamente.

• Compruebe que no hay ningún sesgo 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 se produce un error en el rol de trabajo que lee los mensajes de la cola. 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 este momento, el mensaje vuelve a estar disponible para su procesamiento.

• Compruebe si la longitud de la cola está creciendo con el tiempo. Esto puede ocurrir si no tiene suficientes trabajos disponibles para procesar todos los mensajes que otros trabajadores 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 eliminación de la cola en los mensajes, lo que podría indicar intentos repetidos de error para eliminar el mensaje.

• Examine los registros de almacenamiento en busca de cualquier operación de cola que tenga valores de E2ELatency y ServerLatency superiores a los esperados durante un período de tiempo más largo de lo habitual.

Vea también

• Solución de problemas de errores de la aplicación cliente
• Solución de problemas de disponibilidad
• Supervisión, diagnóstico y solución de 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.