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 aumenta hasta que llega a un punto de agotamiento de recursos.
En la siguiente figura, se muestra un gráfico de escalamiento de rendimiento típico. A medida que aumenta la cantidad de clientes, la carga de trabajo y la productividad aumentan hasta que se agotan todos los recursos.
Idealmente, a medida que duplicas la carga en el sistema, la capacidad de procesamiento también debería duplicarse. En la práctica, habrá una contención de 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 aplane o incluso disminuya. Si realizas optimizaciones para mejorar la capacidad de procesamiento, este es un punto clave que debes identificar, ya que te permite saber dónde ajustar la aplicación o el sistema de base de datos para mejorar la capacidad de procesamiento.
Entre los motivos habituales 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 la 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úferes de Postgres
- Tiempo de espera de E/S debido al uso del motor de almacenamiento
- Engorgamientos de ancho de banda de 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 manera intuitiva. A medida que se empieza a materializar un cuello de botella, las operaciones comienzan a tardar más y el sistema realiza menos operaciones por segundo.
El gráfico de escalamiento de latencia muestra cómo cambia la latencia a medida que aumenta la carga en un sistema. La latencia se mantiene relativamente constante hasta que se produce una fricción debido a la contención de recursos. El punto de inflexión de esta curva suele corresponderse con el aplanamiento de la curva de rendimiento en el gráfico de escalamiento de rendimiento.
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 se incluyen en cada uno.
Este histograma de latencia muestra que la mayoría de las solicitudes son inferiores a 100 milisegundos, y las latencias superiores a 100 milisegundos. Comprender la causa de las solicitudes con colas de latencia más largas puede ayudar a explicar las variaciones en el rendimiento de la aplicación. Las causas de la cola larga de latencias aumentadas corresponden a las latencias aumentadas que se ven en el gráfico de escalamiento de latencia típico y el aplanamiento del gráfico de rendimiento.
El histograma de latencia es más útil cuando hay varias modalidades en una aplicación. Una modalidad es un conjunto normal de condiciones de funcionamiento. Por ejemplo, la mayoría de las veces, la aplicación accede a páginas que están en la caché del búfer. La mayoría de las veces, la aplicación actualiza filas existentes. Sin embargo, puede haber varios modos. A veces, la aplicación recupera páginas del almacenamiento, inserta filas nuevas o experimenta una 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.
Esta figura muestra un histograma bimodal típico en el que la mayoría de las solicitudes se entregan en menos de 100 milisegundos, pero hay otro clúster de solicitudes que demora 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 al 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úferes de PostgreSQL, pero algunos provienen del almacenamiento.
- Diferencias en las latencias de red de algunos clientes con el servidor de bases 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
- Aumentos repentinos de la actividad del cliente