Interpreta los resultados de rendimiento en AlloyDB Omni en una VM

Selecciona una versión de la documentación:

En este documento, se describe cómo interpretar los resultados de rendimiento en AlloyDB Omni en una VM. En este documento, se supone que estás familiarizado con PostgreSQL.

Cuando graficas la capacidad de procesamiento a lo largo del tiempo a medida que se modifica otra variable, por lo general, ves que la capacidad de procesamiento aumenta hasta que alcanza un punto de agotamiento de recursos.

En la siguiente figura, se muestra un gráfico típico de ajuste de escala de la capacidad de procesamiento. A medida que aumenta la cantidad de clientes, la carga de trabajo y la capacidad de procesamiento aumentan hasta que se agotan todos los recursos.

Gráfico de ajuste de la capacidad de procesamiento que muestra la capacidad de procesamiento para la cantidad de clientes. A medida que aumenta la cantidad de clientes, también lo hace la capacidad de procesamiento hasta que se agotan todos los recursos.
Figura 1: Una figura que muestra un gráfico típico de ajuste de escala de la capacidad de procesamiento. A medida que aumenta la cantidad de clientes, la carga de trabajo y la capacidad de procesamiento aumentan hasta que se agotan todos los recursos.

Lo ideal es que, a medida que duplicas la carga en el sistema, la capacidad de procesamiento también se duplique. En la práctica, habrá contención en los recursos que generará aumentos más pequeños en la capacidad de procesamiento. En algún momento, el agotamiento o la contención de recursos harán que la capacidad de procesamiento se estabilice o incluso disminuya. Si estás optimizando la capacidad de procesamiento, este es un punto clave para identificar, ya que impulsa tus esfuerzos para ajustar la aplicación o el sistema de base de datos para mejorar la capacidad de procesamiento.

Entre los motivos típicos por los que la capacidad de procesamiento se estabiliza o disminuye, se incluyen los siguientes:

  • Agotamiento de recursos de CPU en el servidor de la base de datos
  • Agotamiento de recursos de CPU en el cliente, por lo que no se envía más trabajo al servidor de la base de datos
  • Contención de bloqueo de la base de datos
  • Tiempo de espera de E/S cuando los datos superan el tamaño del grupo de búfer de Postgres
  • Tiempo de espera de E/S debido al uso del motor de almacenamiento
  • Cuellos de botella en el ancho de banda de la red que muestran datos al cliente

La latencia y la capacidad de procesamiento son inversamente proporcionales. A medida que aumenta la latencia, disminuye la capacidad de procesamiento. Esto tiene sentido de forma intuitiva. A medida que comienza a materializarse un cuello de botella, las operaciones comienzan a tardar más y el sistema realiza menos operaciones por segundo.

Gráfico de ajuste de escala de latencia que muestra que la latencia permanece constante hasta que se produce fricción debido a la contención de recursos.
Figura 2: Una figura que muestra un gráfico típico de ajuste de escala de la latencia. La latencia permanece constante hasta que se produce fricción debido a la contención de recursos.

El gráfico de ajuste de escala de la latencia muestra cómo cambia la latencia a medida que aumenta la carga en un sistema. La latencia permanece relativamente constante hasta que se produce fricción debido a la contención de recursos. El punto de inflexión de esta curva generalmente corresponde a la estabilización de la curva de capacidad de procesamiento en el gráfico de ajuste de escala de la capacidad de procesamiento.

Otra forma útil de evaluar la latencia es como un histograma. En esta representación, agrupamos las latencias en buckets y contamos cuántas solicitudes corresponden a cada bucket.

Gráfico de ajuste de escala de latencia que muestra que la latencia permanece constante hasta que se produce fricción debido a la contención de recursos.
Figura 3: Una figura que muestra un histograma típico de latencia. La latencia permanece constante hasta que se produce fricción debido a la contención de recursos.*

Este histograma de latencia muestra que la mayoría de las solicitudes son inferiores a 100 milisegundos y que las latencias son superiores a 100 milisegundos. Comprender la causa de las solicitudes con una cola de latencias más largas puede ayudar a explicar las variaciones en el rendimiento de la aplicación que se observan. Las causas de la cola larga de latencias aumentadas corresponden a las latencias aumentadas que se observan en el gráfico típico de ajuste de escala de la latencia y la estabilización del gráfico de capacidad de procesamiento.

El histograma de latencia es más útil cuando hay varias modalidades en una aplicación. Una modalidad es un conjunto normal de condiciones operativas. Por ejemplo, la mayoría de las veces, la aplicación accede a páginas que están en la caché de búfer. La mayoría de las veces, la aplicación actualiza las filas existentes. Sin embargo, puede haber varios modos. En algunas ocasiones, la aplicación recupera páginas del almacenamiento, inserta filas nuevas o experimenta contención de bloqueo.

Cuando una aplicación encuentra estos diferentes modos de operación a lo largo del tiempo, el histograma de latencia muestra estas múltiples modalidades.

Gráfico de ajuste de escala de latencia que muestra que la latencia permanece constante hasta que se produce fricción debido a la contención de recursos.
Figura 4: Una figura que muestra un histograma típico de latencia bimodal. La latencia permanece constante hasta que se produce fricción debido a la contención de recursos.

En esta figura, se muestra un histograma bimodal típico en el que la mayoría de las solicitudes se atienden en menos de 100 milisegundos, pero hay otro grupo de solicitudes que tardan entre 401 y 500 milisegundos. Comprender la causa de esta segunda modalidad puede ayudar a mejorar el rendimiento de tu aplicación. También puede haber más de dos modalidades.

La segunda modalidad puede deberse a operaciones normales de la base de datos, infraestructura y topología heterogéneas o comportamiento de la aplicación. Estos son algunos ejemplos que debes tener en cuenta:

  • La mayoría de los accesos a los datos provienen del grupo de búfer de PostgreSQL, pero algunos provienen del almacenamiento.
  • Diferencias en las latencias de red para algunos clientes en el servidor de la base de datos
  • Lógica de la aplicación que realiza diferentes operaciones según la entrada o la hora del día
  • Contención de bloqueo esporádica
  • Picos en la actividad del cliente