Información acerca de la administración automática de la memoria

AlloyDB Omni usa algoritmos adaptables para la administración de memoria.

Puedes decidir el límite superior del búfer compartido cuando inicias AlloyDB Omni. Si no estableces el límite superior, AlloyDB Omni establece automáticamente el tamaño de la copia de seguridad del búfer compartido en el 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 supervisa 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 cuando se almacenan datos en caché.

Memoria automática

De forma predeterminada, el parámetro shared_buffers se establece en 0, que es un valor especial que establece el límite superior del tamaño de la caché de shared buffers en el 80% de la memoria del sistema. AlloyDB Omni comienza en el 10% del límite superior de shared_buffers. Si un valor personalizado anula shared_buffers, AlloyDB Omni respeta el valor como el límite superior del tamaño de shared_buffers y comienza con ese tamaño personalizado especificado.

Para especificar un tamaño personalizado, edita el archivo de configuración postgresql.conf. Por ejemplo, puedes establecer shared_buffers en 1GB con cualquiera de las siguientes opciones:

  • docker run --name CONTAINER_NAME -e INITDB_ARGS="-c shared_buffers=1GB" $image

  • docker run --name CONTAINER_NAME $image -c shared_buffers=1GB

    Reemplaza CONTAINER_NAME por el nombre que le asignaste al contenedor de AlloyDB Omni cuando lo instalaste.

Optimiza el rendimiento de las consultas

El valor predeterminado del parámetro shared_buffers funciona para situaciones comunes.

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 memory.max de cgroup para influir en el procesamiento.

Memoria del motor de columnas

El shared_buffers dinámico es independiente de la memoria del motor de columnas. Cuando el motor de columnas está habilitado, el tamaño dinámico de shared_buffers se puede obtener restando la cantidad de memoria que usa el motor de columnas del 80% de la memoria total disponible para el sistema o el cgroup.

Páginas enormes

Las páginas enormes mejoran el rendimiento de la base de datos. AlloyDB Omni administra páginas enormes de forma explícita si es posible; de lo contrario, se basa en la función de páginas enormes y transparentes (THP) del sistema operativo. Si no se admite ninguno de los tipos de páginas enormes, AlloyDB Omni recurre a la página 4K y, luego, imprime una advertencia en los registros del contenedor de Docker docker logs $container_name con instrucciones específicas para configurar páginas enormes. Consulta Cómo iniciar AlloyDB Omni para obtener instrucciones sobre cómo iniciar un contenedor.

La advertencia es similar a la 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

Administración automática de la memoria durante el tiempo de ejecución

AlloyDB Omni supervisa constantemente la carga del sistema y ajusta su consumo de memoria para mejorar el rendimiento. Específicamente, es posible que observes lo siguiente:

Cambio de tamaño dinámico de shared_buffers
AlloyDB Omni aumenta el tamaño dinámico de shared_buffers cuando el consumo de memoria del sistema es bajo y disminuye el tamaño cuando el consumo de memoria del sistema es alto. Para supervisar el tamaño dinámico de shared_buffers, usa lo siguiente: 
CREATE EXTENSION IF NOT EXISTS g_memory;
SELECT g_dynamic_shared_size();
Cierre 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 borrar las conexiones de PostgreSQL que consumen más memoria hasta que la carga vuelva a un nivel razonable. Cuando ocurre 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)