Optimiza el rendimiento de los Hyperdisks

Después de aprovisionar los volúmenes de Google Cloud Hyperdisk, es posible que la aplicación y el sistema operativo requieran un ajuste del rendimiento para satisfacer tus necesidades de rendimiento.

En las siguientes secciones, describimos algunos elementos clave que se pueden ajustar para obtener un mejor rendimiento y cómo puedes aplicar algunos de estos elementos a tipos específicos de cargas de trabajo.

Para obtener una descripción general de cómo funciona el rendimiento de Google Cloud Hyperdisk, consulta Acerca del rendimiento de Hyperdisk.

Usa una profundidad de cola de E/S alta

Los volúmenes de Hyperdisk tienen una latencia más alta que los discos conectados localmente, como los SSD locales, porque son dispositivos conectados a la red. Pueden proporcionar IOPS y capacidad de procesamiento muy altas, pero debes asegurarte de que se realicen suficientes solicitudes de E/S en paralelo. La cantidad de solicitudes de E/S realizadas en paralelo se conoce como profundidad de cola de E/S.

En las siguientes tablas, se muestra la profundidad de cola de E/S recomendada para asegurarte de que puedas lograr un nivel de rendimiento determinado. Las tablas usan una leve sobreestimación de la latencia típica para mostrar recomendaciones conservadoras. En el ejemplo, se supone que usas un tamaño de E/S de 16 KB.

IOPS deseadas Profundidad de la cola
500 1
1,000 2
2,000 4
4,000 8
8,000 16
16,000 32
32,000 64
64,000 128
100,000 200
200,000 400
320,000 640
Capacidad de procesamiento deseada (MB/s) Profundidad de la cola
8 1
16 2
32 4
64 8
128 16
256 32
512 64
1,000 128
1,200 153

Asegúrate de tener CPU libres

Leer y escribir en volúmenes de Hyperdisk requiere ciclos de CPU de tu VM. Si tu instancia de VM consume mucha CPU, tu aplicación no podrá administrar las IOPS descritas con anterioridad. Para lograr niveles de IOPS muy altos y coherentes, debes tener CPU libres para procesar E/S.

Inhabilita la protección contra escrituras incompletas a nivel de la base de datos para optimizar las escrituras

Como Google Cloud Hyperdisk proporciona protección integrada contra escrituras incompletas, puedes inhabilitar las funciones de protección a nivel de la base de datos para reducir la sobrecarga de E/S y aumentar la capacidad de procesamiento de escritura de la base de datos hasta en un 25%. Para obtener más información sobre esta función, consulta Protección contra escrituras incompletas en la página de descripción general de Hyperdisk.

Requisitos de configuración del entorno

Para que la protección contra escrituras incompletas de Hyperdisk sea eficaz, las escrituras de la base de datos no deben fragmentarse antes de llegar a la capa de almacenamiento. Según tu base de datos, puedes lograr esto con una de las siguientes opciones de configuración:

Opción 1: Alinea las capas a los límites de bloques de 16 KiB (recomendado para MySQL y PostgreSQL)

Configura tu sistema operativo, sistema de archivos y capas de software intermedias para conservar el límite de 16 KiB. Cuando usas esta opción, debes mantener esta configuración específica:

  • Sistema de archivos: Usa un sistema de archivos ext4. Debes crear el sistema de archivos con la opción bigalloc y configurar el tamaño del clúster del sistema de archivos en 16 KiB (16,384 bytes) o un múltiplo de potencia de dos más grande de 16 KiB:

    mkfs.ext4 -O bigalloc -C 16384 /dev/<var>DEVICE_NAME</var>

    Reemplaza DEVICE_NAME por el nombre del dispositivo de almacenamiento.

  • Configuraciones no compatibles: Evita las configuraciones que puedan introducir escrituras incompletas por encima de la capa de almacenamiento en bloque, como las siguientes:

    • Ejecutar bases de datos alojadas en contenedores en Google Kubernetes Engine o Kubernetes autoalojado.
    • Almacenar archivos de base de datos en un sistema de archivos xfs, que, por lo general, no admite tamaños de bloque suficientes en la mayoría de las distribuciones de Linux.
    • Usar configuraciones de matrices redundantes de discos independientes (RAID) o administradores de volúmenes lógicos (LVM) que quitan la E/S.
    • Usar Hyperdisk con cachés de SSD locales, incluidos lvmcache, dm-cache o bcache.
    • Usar la virtualización anidada para la VM de la base de datos.

Opción 2: Usa la E/S atómica de bloques de Linux (recomendado para MariaDB)

Si tu base de datos o aplicación admite la E/S atómica de bloques de Linux y accede a los archivos con la E/S directa (O_DIRECT), puedes omitir las reglas de configuración que se indican en la opción 1, siempre que cumplas con las siguientes condiciones:

  • Marca RWF_ATOMIC: La aplicación debe usar la llamada al sistema pwritev2()con la marca RWF_ATOMIC. Cuando se usa esta marca, el kernel de Linux garantiza que una operación de escritura se procese como un solo bloque contiguo en el dispositivo Hyperdisk subyacente. Si el kernel no puede garantizar la atomicidad, la llamada de escritura falla de inmediato para evitar la corrupción de datos.
  • Sistema operativo: Debe ser la versión 6.11 o posterior del kernel de Linux.
  • Sistema de archivos: Debe ser ext4 o xfs en la versión 6.13 o posterior del kernel de Linux.
  • Acceso a archivos: La aplicación debe abrir archivos de base de datos con la E/S directa (O_DIRECT).
  • Bases de datos compatibles: Recomendamos esta opción solo para MariaDB versión 11.x o posterior (para la compatibilidad genérica de Linux RWF_ATOMIC). MySQL y PostgreSQL no admiten esta función.

Para obtener instrucciones detalladas de optimización específicas de la base de datos, consulta Configura MySQL en Compute Engine.

Revisa las métricas de rendimiento de Hyperdisk

Puedes revisar las métricas de rendimiento del disco en Cloud Monitoring, Google Cloudla solución de supervisión integrada de. Puedes usar estas métricas para observar el rendimiento de los discos y otros recursos de VM en diferentes cargas de trabajo de aplicaciones.

Para obtener más información, consulta Revisa las métricas de rendimiento del disco persistente.

También puedes usar la página Observabilidad en la consola para ver las métricas de rendimiento del disco.

¿Qué sigue?