Conceptos esenciales para el ajuste de RDS para PostgreSQL - Amazon Relational Database Service
Eventos de espera de RDS para PostgreSQLMemoria de RDS para PostgreSQLProcesos de RDS para PostgreSQL

Conceptos esenciales para el ajuste de RDS para PostgreSQL

Antes de ajustar la base de datos de RDS para PostgreSQL, asegúrese de saber qué son los eventos de espera y por qué se producen. Revise también la arquitectura básica de memoria y disco de RDS para PostgreSQL. Para ver un diagrama de arquitectura útil, consulte el wikibook de PostgreSQL.

Eventos de espera de RDS para PostgreSQL

Un evento de espera es una indicación de que la sesión espera un recurso. Por ejemplo, el evento de espera Client:ClientRead ocurre cuando RDS para PostgreSQL espera recibir datos del cliente. Por lo general, las sesiones esperan recursos como los siguientes.

  • Acceso de subproceso único a un búfer, por ejemplo, cuando una sesión intenta modificar un búfer

  • Una fila bloqueada actualmente por otra sesión

  • Lectura de un archivo de datos

  • Escritura de un archivo de registro

Por ejemplo, para satisfacer una consulta, la sesión podría hacer un escaneo de tabla completo. Si los datos ya no están en la memoria, la sesión espera a que se complete la E/S del disco. Cuando los búferes se leen en la memoria, es posible que la sesión tenga que esperar porque otras sesiones tienen acceso a los mismos búferes. La base de datos registra las esperas mediante un evento de espera predefinido. Estos eventos se agrupan en categorías.

Un evento de espera no significa por sí solo un problema de rendimiento. Por ejemplo, si los datos solicitados no están en memoria, es necesario leer los datos del disco. Si una sesión bloquea una fila para una actualización, otra sesión espera a que se desbloquee la fila para poder actualizarla. Una confirmación requiere un tiempo de espera para que se complete la escritura en un archivo de registro. Las esperas forman parte del funcionamiento normal de una base de datos.

Por otro lado, un gran número de eventos de espera suele ser indicativo de un problema de rendimiento. En estos casos, se pueden utilizar los datos de los eventos de espera para determinar en qué se gastan las sesiones. Por ejemplo, si un informe que normalmente se ejecuta en minutos ahora se ejecuta durante horas, puede identificar los eventos de espera que más contribuyen al tiempo total de espera. Si puede determinar las causas de los principales eventos de espera, a veces puede hacer cambios que mejoren el rendimiento. Por ejemplo, si la sesión se encuentra a la espera de una fila que ha sido bloqueada por otra sesión, puede terminar la sesión de bloqueo.

Memoria de RDS para PostgreSQL

La memoria de RDS para PostgreSQL se divide en compartida y local.

Memoria compartida en RDS para PostgreSQL

RDS para PostgreSQL asigna memoria compartida cuando se inicia la instancia. La memoria compartida se divide en múltiples subáreas. A continuación se describen las más importantes.

Búferes compartidos

El grupo de búferes compartidos es un área de memoria de RDS para PostgreSQL que contiene todas las páginas que utilizan o han utilizado las conexiones de la aplicación. Una página es la versión de memoria de un bloque de disco. El grupo de búferes compartidos almacena en caché los bloques de datos leídos desde el disco. El grupo reduce la necesidad de volver a leer los datos del disco, lo que hace que la base de datos funcione de forma más eficiente.

Cada tabla e índice se almacena como una matriz de páginas de tamaño fijo. Cada bloque contiene varias tuplas, que corresponden a filas. Una tupla se puede almacenar en cualquier página.

El grupo de búferes compartidos tiene memoria finita. Si una nueva solicitud requiere una página que no está en la memoria, y no hay más memoria, RDS para PostgreSQL desaloja una página que se utiliza con menos frecuencia para satisfacer la solicitud. La política de expulsión se implementa mediante un algoritmo de barrido de reloj.

El parámetro shared_buffers determina la cantidad de memoria que el servidor dedica al almacenamiento en caché de los datos.

Búferes de registro de escritura anticipada (WAL)

Un búfer del registro de escritura anticipada (WAL) contiene datos de transacciones que RDS para PostgreSQL escribe posteriormente en el almacenamiento persistente. Con el mecanismo WAL, RDS para PostgreSQL puede hacer lo siguiente:

  • Recuperar datos después de un error

  • Reducir la E/S del disco al evitar las escrituras frecuentes en el disco

Cuando un cliente cambia los datos, RDS para PostgreSQL escribe los cambios en el búfer de WAL. Cuando el cliente emite un COMMIT, el proceso de escritura WAL escribe los datos de la transacción en el archivo WAL.

El parámetro wal_level determina la cantidad de información que se escribe en el WAL.

Memoria local en RDS para PostgreSQL

Cada proceso de backend asigna memoria local para el procesamiento de consultas.

Área de memoria de trabajo

El área de memoria de trabajo contiene datos temporales para las consultas que ejecutan ordenaciones y hashes. Por ejemplo, una consulta con una cláusula ORDER BY ejecuta una ordenación. Las consultas utilizan tablas hash en uniones hash y agregaciones.

El parámetro work_mem indica la cantidad de memoria que se utilizará en las operaciones internas de ordenación y en las tablas hash antes de escribir en los archivos temporales del disco. El valor predeterminado es 4 MB. Se pueden ejecutar varias sesiones simultáneamente, y cada sesión puede ejecutar operaciones de mantenimiento en paralelo. Por esta razón, la memoria de trabajo total utilizada puede ser múltiplo del parámetro work_mem.

Área de memoria de trabajo de mantenimiento

El área de memoria de trabajo de mantenimiento almacena en caché los datos de las operaciones de mantenimiento. Estas operaciones incluyen el vaciado, creación de un índice y adición de claves externas.

El parámetro maintenance_work_mem especifica la cantidad máxima de memoria que se utilizará para las operaciones de mantenimiento. El valor predeterminado es 64 MB. Una sesión de base de datos solo puede ejecutar una operación de mantenimiento a la vez.

Área de búfer temporal

El área de búfer temporal almacena en caché las tablas temporales de cada sesión de la base de datos.

Cada sesión asigna búferes temporales según sea necesario hasta el límite que se especifique. Cuando finaliza la sesión, el servidor borra los búferes.

El parámetro temp_buffers establece el número máximo de búferes temporales utilizados por cada sesión. Antes del primer uso de las tablas temporales dentro de una sesión, puede cambiar el valor de temp_buffers.

Procesos de RDS para PostgreSQL

RDS para PostgreSQL utiliza varios procesos.

Proceso de administrador de correos

El proceso de administrador de correos es el primer proceso que se ejecuta cuando se inicia RDS para PostgreSQL. El proceso de administrador de correos tiene las siguientes funciones principales:

  • Bifurcar y monitorear los procesos en segundo plano

  • Recibir solicitudes de autenticación de los procesos cliente, y autenticarlos antes de permitir que la base de datos atienda las solicitudes

Procesos de backend

Si el administrador de correos autentica una solicitud de cliente, el administrador de correos bifurca un nuevo proceso de backend, también llamado proceso postgres. Un proceso cliente se conecta exactamente a un proceso backend. El proceso cliente y el proceso backend se comunican directamente sin la intervención del proceso de administrador de correos.

Procesos en segundo plano

El proceso de administrador de correos bifurca varios procesos que ejecutan distintas tareas de backend. Algunas de las más importantes son las siguientes:

  • Escritor de WAL

    RDS para PostgreSQL escribe datos en el búfer WAL (registro de escritura anticipada) en los archivos de registro. El principio del registro por adelantado es que la base de datos no puede escribir los cambios en los archivos de datos hasta que la base de datos escriba los registros que describen esos cambios en el disco. El mecanismo de WAL reduce la E/S del disco y permite a RDS para PostgreSQL utilizar los registros para recuperar la base de datos en caso de error.

  • Escritor en segundo plano

    Este proceso escribe de forma periódica las páginas sucias (modificadas) desde los búferes de memoria a los archivos de datos. Una página se vuelve sucia cuando un proceso de backend la modifica en la memoria.

  • Daemon de autovacuum

    El daemon consta de lo siguiente:

    • El iniciador de autovacuum

    • Los procesos de trabajo de autovacuum

    Cuando autovacuum está activado busca las tablas en las que se ha insertado, actualizado o eliminado un número elevado de tuplas. El daemon tiene las siguientes responsabilidades:

    • Recuperar o reutilizar el espacio de disco ocupado por las filas actualizadas o eliminadas

    • Actualizar las estadísticas utilizadas por el planificador

    • Proteger contra la pérdida de datos antiguos debido al reinicio del ID de transacción

    La característica de autovacuum automatiza la ejecución de los comandos VACUUM y ANALYZE. VACUUM tiene las siguientes variantes: estándar y completo. El vacío estándar se ejecuta en paralelo con otras operaciones de la base de datos. VACUUM FULL requiere un bloqueo exclusivo sobre la tabla en la que se trabaja. Por lo tanto, no puede ejecutarse en paralelo con operaciones que acceden a la misma tabla. VACUUM crea una cantidad considerable de tráfico de E/S, lo que puede causar un bajo rendimiento para otras sesiones activas.