Puedes decidir el límite superior del búfer compartido al iniciar AlloyDB Omni. Si no defines el límite superior, AlloyDB Omni asigna automáticamente el tamaño de la copia de seguridad del búfer compartido al 80% de la memoria del sistema. El tamaño inicial de la copia de seguridad del búfer compartido puede ser diferente del límite superior.
AlloyDB Omni consta de un trabajador de memoria inteligente que monitoriza constantemente el estado de la memoria y ajusta el tamaño de la copia de seguridad del búfer compartido para obtener el mejor rendimiento al almacenar datos en caché.
De forma predeterminada, el parámetro shared_buffers
se define como 0
, que es un valor especial que establece el límite superior del tamaño de la caché shared buffers
en el 80% de la memoria del sistema. AlloyDB Omni empieza con el 10% del shared_buffers
límite superior. Si se anula shared_buffers
con un valor personalizado, AlloyDB Omni respeta el valor como límite superior del tamaño de shared_buffers
y empieza con el tamaño personalizado especificado.
Para especificar un tamaño personalizado, edita el archivo de configuración postgresql.conf
. Por ejemplo, puedes definir shared_buffers
como 1GB
de una de las siguientes formas:
docker run --name CONTAINER_NAME -e INITDB_ARGS="-c shared_buffers=1GB" $image
docker run --name CONTAINER_NAME $image -c shared_buffers=1GB
Sustituye
CONTAINER_NAME
por el nombre que asignaste al contenedor de AlloyDB Omni cuando lo instalaste.
Optimizar el rendimiento de las consultas
El valor predeterminado del parámetro shared_buffers
funciona en situaciones habituales.
Sin embargo, puedes ajustar el valor para obtener el mejor rendimiento.
Si decides usar el valor predeterminado de shared_buffers
para deducir el límite superior del búfer compartido, usa el valor de cgroup memory.max
para influir en el cálculo.
Memoria del motor en columnas
El shared_buffers
dinámico es independiente de la memoria del motor de columnas. Cuando el motor columnar está habilitado, el tamaño dinámico de shared_buffers
se puede obtener restando la cantidad de memoria que usa el motor columnar del 80% de la memoria total disponible para el sistema o el cgroup.
Páginas enormes
Las páginas enormes mejoran el rendimiento de las bases de datos. AlloyDB Omni gestiona las páginas enormes de forma explícita si es posible. De lo contrario, se basa en la función de páginas enormes transparentes (THP) del sistema operativo. Si no se admite ninguno de los dos tipos de páginas enormes, AlloyDB Omni recurre a la página de 4 k e imprime una advertencia en los registros del contenedor de Docker docker logs $container_name
con instrucciones específicas para configurar las páginas enormes. Consulta Iniciar AlloyDB Omni para obtener instrucciones sobre cómo iniciar un contenedor.
La advertencia tiene un aspecto similar al siguiente:
HINT: Please either execute the all-in-one setup script:
docker run --rm --privileged $image setup-host
OR manually execute:
echo within_size | sudo tee /sys/kernel/mm/transparent_hugepage/shmem_enabled
sudo sysctl -w vm.nr_overcommit_hugepages=1048576
Gestión automática de la memoria en tiempo de ejecución
AlloyDB Omni monitoriza constantemente la carga del sistema y ajusta su consumo de memoria para mejorar el rendimiento. En concreto, puede que observes lo siguiente:
- Cambio de tamaño
shared_buffers
dinámico - AlloyDB Omni aumenta el tamaño dinámico de
shared_buffers
cuando el consumo de memoria del sistema es bajo y lo reduce cuando el consumo de memoria del sistema es alto. Para monitorizar el tamaño dinámicoshared_buffers
, usa lo siguiente:CREATE EXTENSION IF NOT EXISTS g_memory; SELECT g_dynamic_shared_size();
- Finalización de una conexión de PostgreSQL cuando el sistema tiene muy poca memoria
- Cuando AlloyDB Omni detecta que el sistema tiene muy poca memoria, intenta eliminar las conexiones de PostgreSQL que consumen más memoria hasta que la carga vuelve a un nivel razonable. Cuando se produce un evento de este tipo, AlloyDB Omni registra lo siguiente en los registros del contenedor de Docker:
WARNING: Sending SIGTERM to pid=xxx NSpid=xxx (VA size = xxxMB) (RSS size = xxxMB)