Se usó la API de Cloud Translation para traducir esta página.

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

Selecciona una versión de la documentación:

Vista previa — AlloyDB Omni

Esta función está sujeta a las "Condiciones de la oferta de la fase previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Puedes procesar datos personales para esta función, como se describe en el Anexo de Tratamiento de Datos de Cloud, sujeto a las obligaciones y restricciones que se describen en el acuerdo en virtud del cual accedes a Google Cloud. Las funciones de la fase previa a la DG están disponibles "sin modificaciones" y pueden tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

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 procesamiento y de E/S para lograr cargas de trabajo más rápidas y un mejor rendimiento de las consultas.

Se incluyen las siguientes funciones:

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

Para habilitar estas funciones de aceleración de E/S, debes habilitar la configuración unificada general (GUC) de alloydb_omni_atomic y configurar 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 implica 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 Cómo acelerar el rendimiento de la base de datos con la caché de disco.

O_DIRECT también ofrece los siguientes beneficios:

El uso de O_DIRECT te permite evitar el problema de doble almacenamiento en búfer en PostgreSQL. PostgreSQL administra 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 necesitan para mantener la caché del búfer del kernel.

E/S asíncrona

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

Lecturas de transmisión

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

AlloyDB Omni extiende la compatibilidad para usar lecturas de transmisión para las lecturas desde la caché de disco de AlloyDB Omni con AIO para amplificar 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 comenzar

Comprueba la compatibilidad con tu sistema operativo y sistema de archivos.
1. Para asegurarte de que el kernel admita RWF_ATOMIC, verifica 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 admite RWF_ATOMIC, te recomendamos que actualices a una versión del kernel que sí lo admita.RWF_ATOMIC

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

La marca RWF_ATOMIC se usa para la compatibilidad con escrituras atómicas. De forma predeterminada, la compatibilidad con RWF_ATOMIC se verifica 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 uses una plataforma compatible y la opción force para evitar anular accidentalmente la configuración óptima.

Puedes anular la verificación de compatibilidad de RWF_ATOMIC con la opción force_unsafe, pero no se garantiza la seguridad de los datos con esta anulación. 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 parámetros de configuración de alloydb_omni_atomic y las verificaciones de compatibilidad correspondientes.

Valor `alloydb_omni_atomic`	Verificación de compatibilidad de inicio	Descripción
off	N/A	Este valor desactiva el modo atómico. La función está inactiva.
force	Realiza una verificación de compatibilidad de inicio. No se inicia si falla la escritura de `RWF_ATOMIC`.	Establece la configuración del modo atómico.
force_unsafe	No realiza una verificación de compatibilidad de inicio. Muestra una advertencia, pero continúa si falla la escritura de `RWF_ATOMIC`.	Establece la configuración del modo atómico.

En la configuración de force/force_unsafe, las configuraciones de full_page_writes, io_combine_limit y debug_io_direct se establecen automáticamente. Puedes anular estos parámetros de configuración con la configuración opcional on/on_unsafe.

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

Configura el sistema de archivos XFS para el directorio de datos. Se usa XFS porque admite un tamaño de bloque del sistema de archivos mayor que el tamaño de la página. AlloyDB Omni puede usar XFS para escribir de forma atómica bloques de 8 KiB con compatibilidad completa 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 deseado (DATA_DIR).
```
sudo mkfs.xfs -f -b size=8k /dev/$DEVICE
sudo mount /dev/$DEVICE DATA_DIR
```
  Realiza el siguiente reemplazo:
  - DATA_DIR: Es la ubicación del directorio de datos.
2. Revisa los registros del kernel para asegurarte de que se usen bloques de 8k:
```
> 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
...
```
Opcional: Configura la caché de disco de AlloyDB Omni.

Usa el siguiente ejemplo para crear un sistema de archivos con ext4, y, luego, para activarlo.
```
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
```
Realiza el siguiente reemplazo:
- DEVICE: Es la entidad con la que interactúa la aplicación para realizar operaciones de E/S (lectura o escritura de datos).
Para admitir el rendimiento óptimo de las funciones de aceleración de E/S de AlloyDB Omni cuando el almacenamiento principal no ofrece más operaciones de entrada/salida por segundo (IOPS), te recomendamos que configures la caché de disco de AlloyDB Omni. Para obtener más información, consulta Cómo acelerar el rendimiento de la base de datos con la caché de disco.

Nota: La memoria caché de disco no necesita admitir escrituras atómicas porque los datos en la memoria caché son efímeros. Sin embargo, las funciones de aceleración de E/S de AlloyDB Omni siguen usando O_DIRECT para acceder a la caché.
Descarga y ejecuta AlloyDB Omni.
1. Descarga el contenedor de Docker más reciente de AlloyDB Omni. Para obtener más información, consulta Instala AlloyDB Omni en una VM.
2. Para usar la caché de disco, sigue las instrucciones que se indican en Cómo acelerar el rendimiento de la base de datos con la caché de disco.
3. Para permitir io_uring, agrega 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
```
  Realiza los siguientes reemplazos:
  - CONTAINER_NAME: Es el nombre del contenedor de AlloyDB Omni en el registro de contenedores de tu máquina anfitrión.
  - NEW_PASSWORD: Es la contraseña asignada al usuario de PostgreSQL del contenedor.
  - DATA_DIR: Es la ubicación del directorio de datos.
  - CACHE_DIRECTORY_PATH_INSIDE_CONTAINER: Es la ruta de acceso al directorio de caché de disco dentro del contenedor.
  - HOST_PORT: Es el puerto TCP en la máquina anfitrión al que el contenedor debe publicar su propio puerto 5432.
Configura AlloyDB Omni para que use E/S atómicas.

Establece el GUC alloydb_omni_atomic en un valor adecuado y reinicia el contenedor.
```
alter system set alloydb_omni_atomic='force';
sudo docker restart CONTAINER_NAME;
```
Realiza los siguientes reemplazos:
- CONTAINER_NAME: Es el nombre del contenedor de AlloyDB Omni en el registro de contenedores de tu máquina anfitrión.

Limitaciones

PostgreSQL 16 contiene rutas de acceso que realizan E/S de un solo bloque, lo que O_DIRECT ralentiza el proceso. Es posible que las lecturas sean más lentas durante la recuperación de la base de datos (ruta de rehacer), los análisis de compactación y el precalentamiento de la caché de disco de Omni.
Las funciones de aceleración de E/S de AlloyDB Omni en las réplicas de lectura no son compatibles con la versión preliminar.
En cargas de trabajo pesadas, los sistemas basados en ARM pueden mostrar un rendimiento menor debido a las diferencias arquitectónicas.
Debido a sus limitaciones con cargas de trabajo mayores, libaio es susceptible a la falta de disponibilidad de recursos. io_uring puede experimentar problemas de asignación de memoria cuando la memoria del sistema disponible es baja.