# 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](https://en.wikibooks.org/wiki/PostgreSQL/Architecture). **Topics** + [Eventos de espera de RDS para PostgreSQL](PostgreSQL.Tuning.concepts.waits.md) + [Memoria de RDS para PostgreSQL](PostgreSQL.Tuning.concepts.memory.md) + [Procesos de RDS para PostgreSQL](PostgreSQL.Tuning.concepts.processes.md) # 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. **Topics** + [Memoria compartida en RDS para PostgreSQL](#PostgreSQL.Tuning.concepts.shared) + [Memoria local en RDS para PostgreSQL](#PostgreSQL.Tuning.concepts.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. En las siguientes secciones se proporcionan descripciones de las más importantes. **Topics** + [Búferes compartidos](#PostgreSQL.Tuning.concepts.buffer-pool) + [Búferes de registro de escritura anticipada (WAL)](#PostgreSQL.Tuning.concepts.WAL) ### 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. El valor predeterminado se establece en `{DBInstanceClassMemory/32768}` bytes, en función de la memoria disponible para la instancia de base de 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, con posibles valores como `minimal`, `replica` y `logical`. ## Memoria local en RDS para PostgreSQL Cada proceso de backend asigna memoria local para el procesamiento de consultas. **Topics** + [Área de memoria de trabajo](#PostgreSQL.Tuning.concepts.local.work_mem) + [Área de memoria de trabajo de mantenimiento](#PostgreSQL.Tuning.concepts.local.maintenance_work_mem) + [Área de búfer temporal](#PostgreSQL.Tuning.concepts.temp) ### Á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, medido en megabytes. 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 utilizarán las operaciones de mantenimiento, medido en megabytes. 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, medido en megabytes. El valor predeterminado es 8 MB. 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. **Topics** + [Proceso de administrador de correos](#PostgreSQL.Tuning.concepts.postmaster) + [Procesos de backend](#PostgreSQL.Tuning.concepts.backend) + [Procesos en segundo plano](#PostgreSQL.Tuning.concepts.vacuum) ## 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.