En esta página, se describe cómo habilitar un conjunto de funciones de aceleración de E/S en AlloyDB Omni que pueden ayudar a mejorar el uso de los recursos de procesamiento y E/S para acelerar las cargas de trabajo y el rendimiento de las consultas.
Se incluyen las siguientes funciones:
- Protección de escritura parcial
- Asistencia de
O_DIRECT - E/S asíncrona (AIO)
- Lecturas de transmisión
Para habilitar estas funciones de aceleración de E/S, habilita la configuración unificada general (GUC) de alloydb_omni_atomic
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 GUC alloydb_omni_atomic.
Protección de escritura parcial
Cuando habilitas el parámetro de configuración alloydb_omni_atomic, desactivas las
escrituras de página completa
para evitar la sobrecarga de rendimiento que implica tener que 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 operaciones de escritura atómicas. O_DIRECT se aplica al
directorio de datos de PostgreSQL y a la memoria caché del disco
de AlloyDB Omni. Para obtener más información, consulta
Acelera el rendimiento de la base de datos con la memoria caché del disco.
O_DIRECT también ofrece los siguientes beneficios:
- El uso de
O_DIRECTte 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_DIRECTreduce 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 alloydb_omni_atomic proporciona capacidades de E/S asíncrona (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 las ventajas de E/S almacenadas en búfer, como
la lectura anticipada y la combinación de escritura, 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, similares a la
función de PostgreSQL 17, que proporcionan un mejor rendimiento de
las operaciones de análisis secuenciales, ANALYZE y pg_prewarm con E/S vectorizada
para leer varios bloques en la caché del búfer. La E/S vectorizada es un método en el que una sola llamada de procedimiento puede recuperar previamente datos de varios búferes, lo que mejora la eficiencia, ya que reduce los cambios de contexto y las llamadas al sistema.
AlloyDB Omni extiende la compatibilidad para usar lecturas de transmisión para lecturas de la memoria caché del 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 desde el almacenamiento cada vez que se necesitan.
Antes de comenzar
Verifica la compatibilidad de tu sistema operativo y de archivos.
Para asegurarte de que el kernel admita
RWF_ATOMIC, verifica la versión del kernel. En el siguiente ejemplo, usarás una máquina con 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 ...Si tu kernel no es compatible con
RWF_ATOMIC, te recomendamos que lo actualices a una versión de kernel que sí lo seaRWF_ATOMIC.
Para usar las funciones de aceleración de E/S de AlloyDB Omni y probar las mejoras de rendimiento con la protección de escritura dañada, habilita el parámetro de configuración de unificación general (GUC)
alloydb_omni_atomic. Para usar este GUC, debes tener un kernel y un sistema de archivos compatibles que proporcionen E/S atómica y protejan contra escrituras dañadas.La marca
RWF_ATOMICse usa para la compatibilidad con la escritura atómica. De forma predeterminada, la compatibilidad conRWF_ATOMICse verifica durante el inicio. PostgreSQL no se inicia si no se pueden confirmar las escrituras atómicas con la marcaRWF_ATOMIC.Puedes anular este comportamiento predeterminado, pero te recomendamos que uses una plataforma compatible y la opción
forcepara evitar anular de forma accidental los parámetros de configuración óptimos.Puedes anular la verificación de compatibilidad de
RWF_ATOMICcon la opciónforce_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_atomicy las verificaciones de compatibilidad correspondientes.Valor alloydb_omni_atomicVerificació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, los parámetros de configuración defull_page_writes,io_combine_limitydebug_io_directse establecen automáticamente. Puedes anular estos parámetros de configuración con el parámetro opcionalon/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 total con
RWF_ATOMIC.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 (
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.
Verifica 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 memoria caché del disco de AlloyDB Omni.
Usa el siguiente ejemplo para crear un sistema de archivos con
ext4,y, luego, móntalo.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 un rendimiento óptimo de las funciones de aceleración de E/S de AlloyDB Omni cuando el almacenamiento principal no ofrece operaciones de entrada y salida por segundo (IOPS) más altas, te recomendamos que configures la memoria caché del disco de AlloyDB Omni. Para obtener más información, consulta Acelera el rendimiento de la base de datos con la memoria caché del disco.
Descarga y ejecuta AlloyDB Omni.
- Descarga el contenedor de Docker de AlloyDB Omni más reciente. Para obtener más información, consulta Instala AlloyDB Omni en una VM.
- Para usar la memoria caché del disco, sigue las instrucciones que se indican en Acelera el rendimiento de la base de datos con la memoria caché del disco.
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 la memoria caché del disco dentro del contenedor.HOST_PORT: Es la publicación de TCP en la máquina anfitrión en la que el contenedor debe publicar su propio puerto 5432.
Configura AlloyDB Omni para usar E/S atómica.
Establece el GUC
alloydb_omni_atomicen 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 que realizan E/S de un solo bloque, lo que
ralentiza
O_DIRECT. 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 limpieza y el calentamiento previo de la memoria caché del disco de Omni. - Las funciones de aceleración de E/S de AlloyDB Omni en las réplicas de lectura no se admiten en la versión preliminar.
- En cargas de trabajo pesadas, los sistemas basados en ARM pueden mostrar un rendimiento más bajo debido a diferencias de arquitectura.
- Debido a sus limitaciones con el aumento de las cargas de trabajo,
libaioes susceptible a la falta de disponibilidad de recursos. Es posible queio_uringexperimente problemas de asignación de memoria cuando la memoria disponible del sistema se esté agotando.