Mejorar el rendimiento de AlloyDB Omni con la aceleración de E/S

Selecciona una versión de la documentación:

En esta página se describe cómo habilitar un conjunto de funciones de aceleración de E/S en AlloyDB Omni que pueden ayudarte a mejorar el uso de los recursos de computación y E/S para que las cargas de trabajo y el rendimiento de las consultas sean más rápidos.

Se incluyen las siguientes funciones:

  • Protección contra escritura dañada
  • Asistencia de O_DIRECT
  • E/S asíncrona (AIO)
  • Lecturas de streaming

Para habilitar estas funciones de aceleración de E/S, habilita la alloydb_omni_atomicconfiguración unificada general (GUC) y configura AlloyDB Omni para que pueda usar la GUC.

Funciones de aceleración de E/S

En las siguientes secciones se describen las funciones de aceleración de E/S que habilita el alloydb_omni_atomic GUC.

Protección contra escritura dañada

Cuando habilitas la configuración de alloydb_omni_atomic, desactivas las escrituras de página completa para evitar la sobrecarga de rendimiento que supone generar imágenes de página completa para el registro.

Compatibilidad con O_DIRECT

La compatibilidad con O_DIRECT es un requisito previo para las escrituras atómicas. O_DIRECT se aplica al directorio de datos de PostgreSQL y a la caché de disco de AlloyDB Omni. Para obtener más información, consulta el artículo sobre cómo acelerar el rendimiento de las bases de datos con la caché de disco.

O_DIRECT también ofrece las siguientes ventajas:

  • Con O_DIRECT, puedes evitar el problema de doble almacenamiento en búfer en PostgreSQL. PostgreSQL gestiona su propia caché de búfer y puede omitir la caché de búfer del kernel del sistema operativo.
  • O_DIRECT reduce la sobrecarga de la CPU y la memoria del sistema operativo que se necesita para mantener la caché del búfer del kernel.

E/S asíncrona

La configuración alloydb_omni_atomic proporciona funciones de E/S asíncronas (AIO) mediante las bibliotecas io_uring y libaio. Te recomendamos que uses io_uring para evitar las limitaciones de la biblioteca libaio anterior. AlloyDB Omni vuelve a libaio cuando no se detecta la compatibilidad con io_uring. Este enfoque supera la pérdida de ventajas de E/almacenada en búfer, como la lectura anticipada y la combinación de escritura, y también asegura que se maximice el ancho de banda de E/disponible del almacenamiento ofrecido subyacente.

Lecturas de streaming

AlloyDB Omni usa lecturas de streaming, de forma similar a la función de PostgreSQL 17, que proporciona un mejor rendimiento de los análisis secuenciales, ANALYZE y pg_prewarm mediante el uso de E/S vectorizada para leer varios bloques en la caché de búfer. E/S vectorizada es un método en el que una sola llamada de procedimiento puede obtener previamente datos de varios búferes, lo que mejora la eficiencia al reducir los cambios de contexto y las llamadas al sistema.

AlloyDB Omni amplía la compatibilidad para usar lecturas de streaming en las lecturas de la caché de disco de AlloyDB Omni mediante AIO para mejorar el rendimiento de lectura. Este enfoque facilita la lectura anticipada eficaz de los búferes en el grupo de memoria compartida desde el almacenamiento para que las consultas los usen, en lugar de tener que leer estos bloques del almacenamiento cada vez que se necesiten.

Antes de empezar

  1. Comprueba si tu sistema operativo y tu sistema de archivos son compatibles.

    1. Para asegurarte de que el kernel es compatible con RWF_ATOMIC, consulta la versión del kernel. En el siguiente ejemplo, se usa una máquina Ubuntu 24.10 que ejecuta el kernel de Linux 6.14, que admite escrituras atómicas.

      > sudo hostnamectl
       ...
       Operating System: Ubuntu 24.10
            Kernel: Linux 6.14.0-061400rc5-generic
      ...
      
    2. Si tu kernel no es compatible con RWF_ATOMIC, te recomendamos que actualices a una versión del kernel que sí lo sea.RWF_ATOMIC

  2. Para usar las funciones de aceleración de E/S de AlloyDB Omni y probar las mejoras de rendimiento con la protección contra escrituras incompletas, habilita la configuración alloydb_omni_atomic Grand Unification Configuration (GUC). Para usar este GUC, debes tener un kernel y un sistema de archivos compatibles que proporcionen E/S atómica y protejan contra escrituras incompletas.

    La marca RWF_ATOMIC se usa para admitir la escritura atómica. De forma predeterminada, la compatibilidad con RWF_ATOMIC se comprueba durante el inicio. PostgreSQL no se inicia si no se pueden confirmar las escrituras atómicas con la marca RWF_ATOMIC.

    Puedes anular este comportamiento predeterminado, pero te recomendamos que utilices una plataforma compatible y la opción force para evitar anular por error los ajustes de configuración óptimos.

    Puedes anular la RWF_ATOMICcomprobación de compatibilidadforce_unsafe, pero no se garantiza la seguridad de los datos. Te recomendamos que no uses esta opción a menos que estés evaluando AlloyDB Omni en un entorno que no se pueda actualizar para usar el kernel y el sistema de archivos adecuados.

    En la siguiente tabla se enumeran los ajustes de configuración de alloydb_omni_atomic y las comprobaciones de compatibilidad correspondientes.

    alloydb_omni_atomic value Comprobación de compatibilidad al inicio Descripción
    off
    N/A Este valor desactiva el modo atómico. La función está inactiva.
    force
    Realiza una comprobación de compatibilidad al inicio. No se inicia si falla la escritura de RWF_ATOMIC. Define las configuraciones del modo atómico.
    force_unsafe
    No realiza una comprobación de compatibilidad al inicio. Devuelve una advertencia, pero continúa si falla la escritura de RWF_ATOMIC. Define las configuraciones del modo atómico.

    En la configuración force/force_unsafe, se definen automáticamente las configuraciones full_page_writes, io_combine_limit y debug_io_direct. Puede anular estas configuraciones con la configuración opcional on/on_unsafe.

Configurar las funciones de aceleración de E/S de AlloyDB Omni

  1. Configura el sistema de archivos XFS para el directorio de datos. XFS se usa porque admite un tamaño de bloque del sistema de archivos superior al tamaño de página. AlloyDB Omni puede usar XFS para escribir de forma atómica bloques de 8 KiB con compatibilidad total con RWF_ATOMIC.

    1. Crea un sistema de archivos XFS con un tamaño de bloque de 8 KiB y móntalo en la ubicación del directorio de datos que quieras (DATA_DIR).

      sudo mkfs.xfs -f -b size=8k /dev/$DEVICE
      sudo mount /dev/$DEVICE DATA_DIR
      

      Haz la siguiente sustitución:

      • DATA_DIR: la ubicación del directorio de datos.
    2. Consulta los registros del kernel para asegurarte de que se usan bloques de 8 k:

      > sudo journalctl -f
      ...
      kernel: XFS (sdc): EXPERIMENTAL large block size feature enabled.  Use at your own risk!
      kernel: XFS (sdc): Mounting V5 Filesystem 350aa26a-7555-4566-94c1-74e54ddc9250
      ...
      
  2. Opcional: Configura la caché de disco de AlloyDB Omni.

    Usa el siguiente ejemplo para crear un sistema de archivos con ext4, y, a continuación, montar el sistema de archivos.

    sudo /sbin/mkfs.ext4 -m 1 -F -E lazy_itable_init=0,lazy_journal_init=0 /dev/DEVICE
    sudo mount --make-shared -o noatime,discard,errors=panic /dev/DEVICE /OMNI_DISK_CACHE_DIRECTORY
    

    Haz la siguiente sustitución:

    • DEVICE: la entidad con la que interactúa la aplicación para realizar operaciones de E/S (lectura o escritura de datos).

    Para que las funciones de aceleración de E/S de AlloyDB Omni funcionen de forma óptima cuando el almacenamiento principal no ofrezca un número de operaciones de entrada/salida por segundo (IOPS) más alto, te recomendamos que configures la caché de disco de AlloyDB Omni. Para obtener más información, consulta el artículo sobre cómo acelerar el rendimiento de las bases de datos con la caché de disco.

  3. Descarga y ejecuta AlloyDB Omni.

    1. Descarga el contenedor Docker de AlloyDB Omni más reciente. Para obtener más información, consulta Instalar AlloyDB Omni en una VM.
    2. Para usar la caché de disco, sigue las instrucciones que se indican en el artículo Acelerar el rendimiento de la base de datos con la caché de disco.
    3. Para permitir io_uring, añade un argumento adicional: --security-opts="seccomp:unconfined"

      docker run -d --name CONTAINER_NAME \
         -e POSTGRES_PASSWORD=NEW_PASSWORD \
         -v DATA_DIR:/var/lib/postgresql/data \
         -v /OMNI_DISK_CACHE_DIRECTORY:/CACHE_DIRECTORY_PATH_INSIDE_CONTAINER \  # Only if disk cache is enabled
         -p HOST_PORT:5432 \
         --security-opts="seccomp:unconfined" \
         --restart=always \
         google/alloydbomni:16
      

      Haz las siguientes sustituciones:

      • CONTAINER_NAME: el nombre del contenedor de AlloyDB Omni en el registro de contenedores de tu máquina host.
      • NEW_PASSWORD: la contraseña asignada al usuario de PostgreSQL del contenedor.
      • DATA_DIR: la ubicación del directorio de datos.
      • CACHE_DIRECTORY_PATH_INSIDE_CONTAINER: la ruta del directorio de caché de disco dentro del contenedor.
      • HOST_PORT: el puerto TCP de la máquina host al que debe publicar su propio puerto 5432 el contenedor.
  4. Configura AlloyDB Omni para que use E/S atómica.

    Asigna un valor adecuado al alloydb_omni_atomic GUC y reinicia el contenedor.

    alter system set alloydb_omni_atomic='force';
    sudo docker restart CONTAINER_NAME;
    

    Haz las siguientes sustituciones:

    • CONTAINER_NAME: el nombre del contenedor de AlloyDB Omni en el registro de contenedores de tu máquina host.

Limitaciones

  • PostgreSQL 16 contiene rutas que realizan E/S de un solo bloque, lo que O_DIRECTreduce la velocidad. Puede que las lecturas sean más lentas durante la recuperación de la base de datos (ruta de rehacer), los análisis de vacío y el precalentamiento de la caché de disco de Omni.
  • Las funciones de aceleración de E/S de AlloyDB Omni en réplicas de lectura no se admiten en la versión preliminar.
  • Con cargas de trabajo pesadas, los sistemas basados en ARM pueden mostrar un rendimiento inferior debido a las diferencias de arquitectura.
  • Debido a sus limitaciones con cargas de trabajo mayores, libaio es susceptible a la falta de disponibilidad de recursos. io_uring puede tener problemas de asignación de memoria cuando la memoria del sistema disponible es escasa.