# Rendimiento y escalado para Amazon Aurora PostgreSQL La siguiente sección trata sobre la administración del rendimiento y el escalado de un clúster de bases de datos de Amazon Aurora PostgreSQL. También incluye información sobre otras tareas de mantenimiento. **Topics** + [Escalado de las instancias de base de datos Aurora PostgreSQL](#AuroraPostgreSQL.Managing.Performance.InstanceScaling) + [Número máximo de conexiones a una instancia de base de datos Aurora PostgreSQL](#AuroraPostgreSQL.Managing.MaxConnections) + [Límites de almacenamiento temporal de Aurora PostgreSQL](#AuroraPostgreSQL.Managing.TempStorage) + [Páginas enormes para Aurora PostgreSQL](#AuroraPostgreSQL.Managing.HugePages) + [Pruebas de Amazon Aurora PostgreSQL mediante consultas de inserción de errores](AuroraPostgreSQL.Managing.FaultInjectionQueries.md) + [Visualización del estado del volumen para un clúster de bases de datos de Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md) + [Especificación del disco RAM para stats\$1temp\$1directory](AuroraPostgreSQL.Managing.RamDisk.md) + [Administración de archivos temporales con PostgreSQL](PostgreSQL.ManagingTempFiles.md) ## Escalado de las instancias de base de datos Aurora PostgreSQL Puede escalar las instancias de base de datos Aurora PostgreSQL de dos formas, mediante el escalado de instancia y mediante el escalado de lectura. Para obtener más información acerca del escalado de lectura, consulte [Escalado de lectura](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling). Para escalar el clúster de bases de datos de Aurora PostgreSQL, modifique la clase de instancia de base de datos para cada instancia de base de datos del clúster de bases de datos. Aurora PostgreSQL admite varias clases de instancia de base de datos optimizadas para Aurora. No utilice las clases de instancia db.t2 o db.t3 con clústeres de Aurora que tengan más de 40 terabytes (TB). **nota** Recomendamos que las clases de instancia de base de datos T se utilicen solo para los servidores de desarrollo y de pruebas, o para otros servidores que no se utilicen para la producción. Para obtener más detalles sobre las clases de instancia T, consulte [Tipos de clase de instancia de base de datos](Concepts.DBInstanceClass.Types.md). El escalado no es instantáneo. Puede llevar 15 minutos o más completar el cambio a una clase de instancia de base de datos diferente. Si utiliza este enfoque para modificar la clase de instancia de base de datos, aplique el cambio durante el siguiente periodo de mantenimiento programado (en lugar de hacerlo de inmediato) para evitar afectar a los usuarios. Como alternativa a modificar la clase de instancia de base de datos directamente, puede minimizar el tiempo de inactividad por medio de las características de alta disponibilidad de Amazon Aurora. En primer lugar, agregue una réplica de Aurora al clúster. Cuando cree la réplica, elija el tamaño de clase de la instancia de base de datos que desea utilizar para el clúster. Cuando la réplica de Aurora se sincroniza con el clúster, se realiza la conmutación por error a la réplica recién agregada. Para obtener más información, consulte [Réplicas de Aurora](Aurora.Replication.md#Aurora.Replication.Replicas) y [Conmutación por error rápida con Amazon Aurora PostgreSQL](AuroraPostgreSQL.BestPractices.FastFailover.md). Para ver especificaciones detalladas de las clases de instancia de base de datos admitidas en Aurora PostgreSQL, consulte [Motores de base de datos compatibles para clases de instancia de base de datos](Concepts.DBInstanceClass.SupportAurora.md). ## Número máximo de conexiones a una instancia de base de datos Aurora PostgreSQL Un clúster de base de datos de Aurora PostgreSQL asigna recursos en función de la clase de instancia de base de datos y la memoria disponible. Cada conexión al clúster de base de datos consume cantidades incrementales de estos recursos, como memoria y CPU. La memoria consumida por conexión varía según el tipo de consulta, el recuento y si se utilizan tablas temporales. Incluso una conexión inactiva consume memoria y CPU. Esto se debe a que, cuando las consultas se ejecutan en una conexión, se asigna más memoria a cada consulta y esta no se libera por completo, ni siquiera cuando el procesamiento se detiene. Por lo tanto, le recomendamos que se asegure de que sus aplicaciones no mantienen las conexiones inactivas, ya que malgastan recursos y afectan negativamente al rendimiento. Para obtener más información, consulte [Resources consumed by idle PostgreSQL connections](https://aws.amazon.com/blogs/database/resources-consumed-by-idle-postgresql-connections/). El número máximo de conexiones permitidas por una instancia de base de datos de Aurora PostgreSQL está determinado por el valor del parámetro `max_connections` especificado en el grupo de parámetros para esa instancia de base de datos. La configuración ideal para el parámetro `max_connections` es una que admita todas las conexiones de clientes que su aplicación necesita, sin un exceso de conexiones no usadas, más al menos 3 conexiones más para soportar la automatización de AWS. Antes de modificar la configuración del parámetro `max_connections`, le recomendamos que considere las siguientes acciones: + Si el valor de `max_connections` es muy bajo, la instancia de base de datos de Aurora PostgreSQL podría no tener suficientes conexiones disponibles cuando los clientes intenten conectarse. Si esto sucede, intenta conectarse mediante mensajes de generación de errores de `psql` como los siguientes: ``` psql: FATAL: remaining connection slots are reserved for non-replication superuser connections ``` + Si el valor de `max_connections` excede el número de conexiones que realmente se necesitan, las conexiones no utilizadas pueden hacer que el rendimiento se degrade. El valor predeterminado de `max_connections` se obtiene de la siguiente función `LEAST` de Aurora PostgreSQL: `LEAST({DBInstanceClassMemory/9531392},5000)`. Si desea cambiar el valor de `max_connections`, necesita crear un grupo de parámetros de clúster de base de datos personalizado para cambiarlo valor allí. Después de aplicar el grupo de parámetros de base de datos personalizado al clúster, asegúrese de reiniciar la instancia principal para que se aplique el nuevo valor. Para obtener más información, consulte [Parámetros de Amazon Aurora PostgreSQL.](AuroraPostgreSQL.Reference.ParameterGroups.md) y [Creación de un grupo de parámetros de clúster de base de datos en Amazon Aurora](USER_WorkingWithParamGroups.CreatingCluster.md). **sugerencia** Si sus aplicaciones abren y cierran conexiones con frecuencia, o mantienen abierto un gran número de conexiones de larga duración, le recomendamos que utilice Amazon RDS Proxy. El RDS Proxy es un proxy de base de datos totalmente administrado y de alta disponibilidad que utiliza agrupación de conexiones para compartir conexiones de base de datos de forma segura y eficiente. Para obtener más información acerca de RDS Proxy, consulte [Amazon RDS Proxy para Aurora](rds-proxy.md). Para obtener más información acerca de cómo las instancias de Aurora Serverless v2 manejan este parámetro, consulte [Número máximo de conexiones para Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections). ## Límites de almacenamiento temporal de Aurora PostgreSQL Aurora PostgreSQL almacena tablas e índices en el subsistema de almacenamiento de Aurora. Aurora PostgreSQL utiliza almacenamiento temporal independiente para archivos temporales no persistentes. Esto incluye archivos que se utilizan para fines tales como ordenar conjuntos de datos grandes durante el procesamiento de consultas o para operaciones de creación de índices. Para obtener más información, consulte el artículo [How can I troubleshoot local storage issues in Aurora PostgreSQL-Compatible instances?](https://repost.aws/knowledge-center/postgresql-aurora-storage-issue) (¿Cómo puedo solucionar problemas de almacenamiento local en instancias compatibles con Aurora PostgreSQL?). Estos volúmenes de almacenamiento local están respaldados por Amazon Elastic Block Store y pueden ampliarse utilizando una clase de instancia de base de datos mayor. Para obtener más información acerca del almacenamiento, consulte [Almacenamiento de Amazon Aurora](Aurora.Overview.StorageReliability.md). También puede aumentar el almacenamiento local de objetos temporales mediante un tipo de instancia habilitado para NVMe y objetos temporales habilitados para las lecturas optimizadas de Aurora. Para obtener más información, consulte [Mejora del rendimiento de las consultas de Aurora PostgreSQL con lecturas optimizadas de Aurora](AuroraPostgreSQL.optimized.reads.md). **nota** Puede ver los eventos `storage-optimization` al escalar las instancias de base de datos, por ejemplo, de db.r5.2xlarge a db.r5.4xlarge. En la siguiente tabla se muestra la cantidad máxima de almacenamiento temporal disponible para cada clase de instancia de base de datos de Aurora PostgreSQL. Para obtener más información sobre la compatibilidad de la clase de instancia de la base de datos con Aurora, consulte [Clases de instancia de base de datos de Amazon Aurora](Concepts.DBInstanceClass.md). | Clase de instancia de base de datos | Almacenamiento temporal máximo disponible (GiB) | | --- | --- | | db.x2g.16xlarge | 1829 | | db.x2g.12xlarge | 1606 | | db.x2g.8xlarge | 1071 | | db.x2g.4xlarge | 535 | | db.x2g.2xlarge | 268 | | db.x2g.xlarge | 134 | | db.x2g.large | 67 | | db.r8g.48xlarge | 3072 | | db.r8g.24xlarge | 1536 | | db.r8g.16xlarge | 998 | | db.r8g.12xlarge | 749 | | db.r8g.8xlarge | 499 | | db.r8g.4xlarge | 250 | | db.r8g.2xlarge | 125 | | db.r8g.xlarge | 63 | | db.r8g.large | 31 | | db.r7g.16xlarge | 1008 | | db.r7g.12xlarge | 756 | | db.r7g.8xlarge | 504 | | db.r7g.4xlarge | 252 | | db.r7g.2xlarge | 126 | | db.r7g.xlarge | 63 | | db.r7g.large | 32 | | db.r7i.48xlarge | 3072 | | db.r7i.24xlarge | 1500 | | db.r7i.16xlarge | 1008 | | db.r7i.12xlarge | 748 | | db.r7i.8xlarge | 504 | | db.r7i.4xlarge | 249 | | db.r7i.2xlarge | 124 | | db.r7i.xlarge | 62 | | db.r7i.large | 31 | | db.r6g.16xlarge | 1008 | | db.r6g.12xlarge | 756 | | db.r6g.8xlarge | 504 | | db.r6g.4xlarge | 252 | | db.r6g.2xlarge | 126 | | db.r6g.xlarge | 63 | | db.r6g.large | 32 | | db.r6i.32xlarge | 1829 | | db.r6i.24xlarge | 1500 | | db.r6i.16xlarge | 1008 | | db.r6g.12xlarge | 748 | | db.r6i.8xlarge | 504 | | db.r6i.4xlarge | 249 | | db.r6i.2xlarge | 124 | | db.r6i.xlarge | 62 | | db.r6i.large | 31 | | db.r5.24xlarge | 1500 | | db.r5.16xlarge | 1008 | | db.r5.12xlarge | 748 | | db.r5.8xlarge | 504 | | db.r5.4xlarge | 249 | | db.r5.2xlarge | 124 | | db.r5.xlarge | 62 | | db.r5.large | 31 | | db.r4.16xlarge | 960 | | db.r4.8xlarge | 480 | | db.r4.4xlarge | 240 | | db.r4.2xlarge | 120 | | db.r4.xlarge | 60 | | db.r4.large | 30 | | db.t4g.large | 16,5 | | db.t4g.medium | 8,13 | | db.t3.large | 16 | | db.t3.medium | 7.5 | **nota** Los tipos de instancias compatibles con NVMe pueden aumentar el espacio temporal disponible hasta el tamaño total de NVMe. Para obtener más información, consulte [Mejora del rendimiento de las consultas de Aurora PostgreSQL con lecturas optimizadas de Aurora](AuroraPostgreSQL.optimized.reads.md). Puede supervisar el almacenamiento temporal disponible para una instancia de base de datos con la métrica de CloudWatch `FreeLocalStorage`, que se describe en [Métricas de Amazon CloudWatch para Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). (Esto no se aplica a Aurora Serverless v2.) Para algunas cargas de trabajo, puede reducir la cantidad de almacenamiento temporal asignando más memoria a los procesos que están realizando la operación. Para aumentar la memoria disponible de una operación, se aumentan los valores de los parámetros [work\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) o [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) de PostgreSQL. ## Páginas enormes para Aurora PostgreSQL Las *páginas enormes* son una característica de administración de la memoria que reduce la sobrecarga cuando una instancia de base de datos trabaja con grandes fragmentos contiguos de memoria, como la utilizada por los búferes compartidos. Esta característica de PostgreSQL es compatible con todas las versiones de Aurora PostgreSQL disponibles actualmente. El parámetro `Huge_pages` se activa de forma predeterminada para todas las clases de instancia de base de datos que no sean las siguientes: t3.medium, db.t3.large, db.t4g.medium y db.t4g.large. No puede cambiar el valor del parámetro `huge_pages` ni desactivar esta característica en las clases de instancias compatibles de Aurora PostgreSQL. En las instancias de base de datos de Aurora PostgreSQL que no admiten la característica de memoria de páginas enormes, el uso de memoria de procesos específicos podría aumentar sin los correspondientes cambios en la carga de trabajo. El sistema asigna segmentos de memoria compartida, como la caché del búfer, durante el inicio del servidor. Cuando no hay páginas de memoria enormes disponibles, el sistema no carga estas asignaciones al proceso postmaster. En su lugar, incluye la memoria en el proceso que accedió por primera vez a cada página de 4 KB del segmento de memoria compartida. **nota** Las conexiones activas comparten la memoria asignada según sea necesario, independientemente de cómo se realice el seguimiento del uso de la memoria compartida en los procesos. # Pruebas de Amazon Aurora PostgreSQL mediante consultas de inserción de errores Puede probar la tolerancia a errores de su clúster de bases de datos de Aurora PostgreSQL usando consultas de inserción de errores. Las consultas de inyección de errores se emiten como comandos SQL a una instancia Amazon Aurora. Las consultas de inyección de errores le permiten bloquear la instancia para poder probar la conmutación por error y la recuperación. También puede simular un fallo de Aurora Replica, un fallo de disco y una congestión del disco. Las consultas de inyección de errores son compatibles con todas las versiones disponibles de Aurora PostgreSQL, de la siguiente manera. + Aurora PostgreSQL versiones 12, 13, 14 y posteriores + Aurora PostgreSQL versión 11.7 y posteriores + Aurora PostgreSQL versión 10.11 y posteriores **Topics** + [Prueba de un bloqueo de instancia](#AuroraPostgreSQL.Managing.FaultInjectionQueries.Crash) + [Prueba de un error de una réplica de Aurora](#AuroraPostgreSQL.Managing.FaultInjectionQueries.ReplicaFailure) + [Prueba de un error de disco](#AuroraPostgreSQL.Managing.FaultInjectionQueries.DiskFailure) + [Prueba de congestión del disco](#AuroraPostgreSQL.Managing.FaultInjectionQueries.DiskCongestion) Cuando una consulta de inserción de errores especifica un bloqueo, fuerza un bloqueo de la instancia de base de datos de Aurora PostgreSQL. Las otras consultas de inserción de errores producen simulaciones de eventos de error, pero no hacen que el evento ocurra. Cuando se envía una consulta de inserción de errores, se especifica también la cantidad de tiempo que debe durar la simulación del evento de error. Puede enviar una consulta de inserción de errores a una de las instancias de réplica de Aurora conectándose al punto de enlace de la réplica de Aurora. Para obtener más información, consulte [Conexiones de puntos de conexión de Amazon Aurora](Aurora.Overview.Endpoints.md). ## Prueba de un bloqueo de instancia Puede forzar el bloqueo de una instancia de Aurora PostgreSQL mediante la función de consulta de inserción de errores `aurora_inject_crash()`. En esta consulta de inserción de errores no se produce una conmutación por error. Si quiere probar una conmutación por error, puede elegir la acción de instancia **Failover** (Conmutación por error) para el clúster de base de datos en la consola de RDS o usar el comando [failover-db-clúster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html) de AWS CLI o la operación [FailoverDBclúster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) de la API de RDS. **Sintaxis** ``` 1. SELECT aurora_inject_crash ('instance' | 'dispatcher' | 'node'); ```Opciones La consulta de inserción de errores toma uno de los siguientes tipos de bloqueos. El tipo de bloqueo no distingue entre mayúsculas y minúsculas: *'instance'* Se simula un bloqueo de la base de datos compatible con PostgreSQL para la instancia de Amazon Aurora. *“despachador”* Se simula un bloqueo del distribuidor de la instancia principal del clúster de bases de datos de Aurora. El *distribuidor* escribe actualizaciones en el volumen de clúster de un clúster de bases de datos Amazon Aurora. *'node'* Se simula un bloqueo de la base de datos compatible con PostgreSQL y del distribuidor para la instancia de Amazon Aurora. ## Prueba de un error de una réplica de Aurora Puede simular el error de una réplica de Aurora mediante la función de consulta de inserción de errores `aurora_inject_replica_failure()`. Un error de réplica de Aurora bloquea la reproducción en la réplica de Aurora o en todas las réplicas de Aurora del clúster de bases de datos en el porcentaje especificado para el intervalo de tiempo especificado. Cuando se complete el intervalo de tiempo, las réplicas de Aurora afectadas se sincronizan automáticamente con la instancia principal. **Sintaxis** ``` 1. SELECT aurora_inject_replica_failure( 2. percentage_of_failure, 3. time_interval, 4. 'replica_name' 5. ); ```Opciones Esta consulta de inserción de errores toma los siguientes parámetros: *percentage\$1of\$1failure* El porcentaje de reproducción que se debe bloquear durante el evento de error. Puede ser un valor doble entre 0 y 100. Si especifica 0, no se bloquea la reproducción. Si especifica 100, se bloquea toda la reproducción. *time\$1interval* Cantidad de tiempo para simular el error de la réplica de Aurora. El intervalo es en segundos. Por ejemplo, si el valor es 20, la simulación se ejecuta durante 20 segundos. Debe tener cuidado al especificar el intervalo de tiempo del evento de error de la réplica de Aurora. Si especifica un intervalo demasiado largo y la instancia de escritor escribe una gran cantidad de datos durante el evento de error, su clúster de bases de datos de Aurora podría entender que la réplica de Aurora se ha bloqueado y reemplazarla. *replica\$1name* La réplica de Aurora en la que se inserta la simulación de errores. Especifique el nombre de una réplica de Aurora para simular un error de la réplica de Aurora única. Especifique una cadena vacía para simular errores para todas las réplicas de Aurora en el clúster de bases de datos. Para identificar nombres de réplica, consulte la columna `server_id` de la función `aurora_replica_status()`. Por ejemplo: ``` postgres=> SELECT server_id FROM aurora_replica_status(); ``` ## Prueba de un error de disco Puede simular un error de disco para un clúster de bases de datos de Aurora PostgreSQL mediante la función de consulta de inserción de errores `aurora_inject_disk_failure()`. Durante la simulación de un error de disco, el clúster de bases de datos de Aurora PostgreSQL marca de forma aleatoria los segmentos de disco como defectuosos. Las solicitudes que lleguen a esos segmentos se bloquean mientras dure la simulación. **Sintaxis** ``` 1. SELECT aurora_inject_disk_failure( 2. percentage_of_failure, 3. index, 4. is_disk, 5. time_interval 6. ); ```Opciones Esta consulta de inserción de errores toma los siguientes parámetros: *percentage\$1of\$1failure* El porcentaje del disco que se debe marcar como defectuoso durante el evento de error. Puede ser un valor doble entre 0 y 100. Si se especifica 0, ninguna parte del disco se marca como defectuosa. Si se especifica 100, todo el disco se marca como defectuoso. *índice* Un bloque lógico de datos específico en el que se simula el evento de error. Si se sobrepasa el intervalo de datos de nodos de almacenamiento o bloques lógicos disponibles, aparece un error que indica el valor máximo del índice que se puede especificar. Para evitar este error, consulte [Visualización del estado del volumen para un clúster de bases de datos de Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md). *is\$1disk* Indica si el error de inserción se produce en un bloque lógico o en un nodo de almacenamiento. Especificar «true» significa que los errores de inserción son de un bloque lógico. Especificar «false» significa que los errores de inyección son en un nodo de almacenamiento. *time\$1interval* La cantidad de tiempo para simular el error de disco. El intervalo es en segundos. Por ejemplo, si el valor es 20, la simulación se ejecuta durante 20 segundos. ## Prueba de congestión del disco Puede simular una congestión de disco para un clúster de bases de datos de Aurora PostgreSQL mediante la función de consulta de inserción de errores `aurora_inject_disk_congestion()`. Durante la simulación de congestión del disco, el clúster de bases de datos de Aurora PostgreSQL marca de forma aleatoria los segmentos de disco como congestionados. Las solicitudes que lleguen a esos segmentos se retrasan entre el mínimo especificado y el tiempo de demora máximo mientras dure la simulación. **Sintaxis** ``` 1. SELECT aurora_inject_disk_congestion( 2. percentage_of_failure, 3. index, 4. is_disk, 5. time_interval, 6. minimum, 7. maximum 8. ); ```Opciones Esta consulta de inserción de errores toma los siguientes parámetros: *percentage\$1of\$1failure* El porcentaje del disco que se debe marcar como congestionado durante el evento de error. Este es un valor doble entre 0 y 100. Si se especifica 0, ninguna parte del disco se marca como congestionada. Si se especifica 100, todo el disco se marca como congestionado. *índice* Un bloque lógico de datos o nodo de almacenamiento específico en el que se simula el evento de error. Si se sobrepasa el intervalo de nodos de almacenamiento o bloques lógicos de datos disponibles, aparece un error que indica el valor máximo del índice que se puede especificar. Para evitar este error, consulte [Visualización del estado del volumen para un clúster de bases de datos de Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md). *is\$1disk* Indica si el error de inserción se produce en un bloque lógico o en un nodo de almacenamiento. Especificar «true» significa que los errores de inserción son de un bloque lógico. Especificar «false» significa que los errores de inyección son en un nodo de almacenamiento. *time\$1interval* La cantidad de tiempo para simular la congestión del disco. El intervalo es en segundos. Por ejemplo, si el valor es 20, la simulación se ejecuta durante 20 segundos. *mínimo, máximo* La cantidad mínima y máxima de demora de la congestión en milisegundos. Los valores válidos varían entre 0,0 y 100,0 milisegundos. Los segmentos de disco marcados como congestionados se retrasan por una cantidad de tiempo aleatoria dentro del rango mínimo y máximo mientras dure la simulación. El valor máximo debe ser mayor que el valor mínimo. # Visualización del estado del volumen para un clúster de bases de datos de Aurora PostgreSQL En Amazon Aurora, un volumen de clúster de bases de datos se compone de un conjunto de bloques lógicos. Cada uno de esos bloques representa 10 gigabytes de almacenamiento asignado. Estos bloques se denominan *grupos de protección*. Los datos de cada grupo de protección se replican en seis dispositivos de almacenamiento físicos denominados *nodos de almacenamiento*. Estos nodos de almacenamiento se distribuyen entre tres zonas de disponibilidad (AZ) en la región en la que reside el clúster de bases de datos. A su vez, cada nodo de almacenamiento contiene uno o varios bloques lógicos de datos para el volumen del clúster de bases de datos. Para obtener más información acerca de los grupos de protección y los nodos de almacenamiento, consulte [Introducing the Aurora Storage Engine](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) en el Blog de base de datos de AWS. Para obtener más información sobre volúmenes de clúster de Aurora en general, consulte [Almacenamiento de Amazon Aurora](Aurora.Overview.StorageReliability.md). Utilice la función `aurora_show_volume_status()` para devolver las siguientes variables de estado del servidor: + `Disks`: el número total de bloques lógicos de datos para el volumen del clúster de bases de datos. + `Nodes` **—** el número total de nodos de almacenamiento para el volumen del clúster de bases de datos. Puede utilizar la función `aurora_show_volume_status()` para evitar un error al usar la función de inserción de errores `aurora_inject_disk_failure()`. La función de inserción de errores `aurora_inject_disk_failure()` simula el error de un nodo de almacenamiento completo o de un único bloque lógico de datos dentro de un nodo de almacenamiento. En la función, especifique el valor del índice de un bloque lógico de datos o nodo de almacenamiento concreto. Sin embargo, si especifica un valor del índice mayor que el número de bloques lógicos de datos o los nodos de almacenamiento utilizados por el volumen de clúster de bases de datos, la instrucción devuelve un error. Para obtener más información acerca de las consultas de inserción de errores, vea [Pruebas de Amazon Aurora PostgreSQL mediante consultas de inserción de errores](AuroraPostgreSQL.Managing.FaultInjectionQueries.md). **nota** La función `aurora_show_volume_status()` está disponible para la versión 10.11 de Aurora PostgreSQL. Para obtener más información acerca de las versiones de Aurora PostgreSQL, consulte [Versiones de Amazon Aurora PostgreSQL y versiones del motor](AuroraPostgreSQL.Updates.20180305.md). **Sintaxis** ``` 1. SELECT * FROM aurora_show_volume_status(); ``` **Ejemplo** ``` customer_database=> SELECT * FROM aurora_show_volume_status(); disks | nodes -------+------- 96 | 45 ``` # Especificación del disco RAM para stats\$1temp\$1directory Puede utilizar el parámetro de Aurora PostgreSQL `rds.pg_stat_ramdisk_size` para especificar la memoria del sistema asignada a un disco RAM para almacenar `stats_temp_directory` de PostgreSQL. El parámetro del disco RAM solo está disponible en la versión 14 e inferiores de Aurora PostgreSQL. Para algunas cargas de trabajo, configurar este parámetro puede mejorar el rendimiento y reducir los requisitos de E/S. Para obtener más información sobre el `stats_temp_directory`, consulte [Run-time Statistics (Estadísticas de tiempo de ejecución)](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY) en la documentación de PostgreSQL. A partir de la versión 15 de PostgreSQL, la comunidad de PostgreSQL pasó a utilizar la memoria compartida dinámica. Por lo tanto, no es necesario configurar `stats_temp_directory`. Para habilitar un disco RAM para `stats_temp_directory`, defina el parámetro `rds.pg_stat_ramdisk_size` en un valor distinto de cero en el grupo de parámetros de clúster de bases de datos que utilice su clúster de bases de datos. Este parámetro indica MB, por lo que debe utilizar un valor entero. Las expresiones, fórmulas y funciones no son válidas para el parámetro `rds.pg_stat_ramdisk_size`. Asegúrese de reiniciar el clúster de bases de datos para que el cambio surta efecto. Para obtener información acerca de cómo configurar los parámetros, consulte [Grupos de parámetros para Amazon Aurora](USER_WorkingWithParamGroups.md). Para obtener más información acerca de la conexión al clúster de base de datos, consulte [Reinicio de un clúster de base de datos de Amazon Aurora o de una instancia de base de datos de Amazon Aurora](USER_RebootCluster.md). Por ejemplo, el comando AWS CLI siguiente establece el parámetro del disco RAM en 256 MB. ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name db-cl-pg-ramdisk-testing \ --parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot" ``` Después de reiniciar el clúster de bases de datos, ejecute el siguiente comando para ver el estado de `stats_temp_directory`: ``` postgres=> SHOW stats_temp_directory; ``` El comando debe devolver lo siguiente: ``` stats_temp_directory --------------------------- /rdsdbramdisk/pg_stat_tmp (1 row) ``` # Administración de archivos temporales con PostgreSQL En PostgreSQL, una consulta compleja puede realizar varias operaciones de ordenación y hash al mismo tiempo, y cada una de ellas utiliza memoria de la instancia para almacenar los resultados hasta el valor especificado en el parámetro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Cuando la memoria de la instancia no es suficiente, se crean archivos temporales para almacenar los resultados. Se escriben en el disco para completar la ejecución de la consulta. Posteriormente, una vez finalizada la consulta, estos archivos se eliminan automáticamente. En En Aurora PostgreSQL, estos archivos comparten el almacenamiento local con otros archivos de registro. Puede supervisar el espacio de almacenamiento local de su clúster de base de datos de Aurora PostgreSQL observando la métrica de Amazon CloudWatch para `FreeLocalStorage`. Para obtener más información, consulte [ Troubleshoot local storage issues](https://aws.amazon.com/premiumsupport/knowledge-center/postgresql-aurora-storage-issue/) (Solución de problemas del almacenamiento local). Recomendamos utilizar clústeres de lecturas optimizadas para Aurora para las cargas de trabajo que implican múltiples consultas simultáneas que aumentan el uso de archivos temporales. Estos clústeres utilizan almacenamiento por bloques local basado en unidades de estado sólido (SSD) de memoria rápida no volátil (NVMe) para colocar los archivos temporales. Para obtener más información, consulte [Mejora del rendimiento de las consultas de Aurora PostgreSQL con lecturas optimizadas de Aurora](AuroraPostgreSQL.optimized.reads.md). Puede utilizar los siguientes parámetros y funciones para administrar los archivos temporales de la instancia. + **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** – este parámetro cancela cualquier consulta que supere el tamaño de temp\$1files en KB. Este límite evita que cualquier consulta se ejecute de forma indefinida y consuma espacio en disco con archivos temporales. Puede calcular el valor utilizando los resultados del parámetro `log_temp_files`. Como práctica recomendada, examine el comportamiento de la carga de trabajo y establezca el límite de acuerdo con la estimación. En el siguiente ejemplo, se cancela una consulta cuando se supera el límite. ``` postgres=>select * from pgbench_accounts, pg_class, big_table; ``` ``` ERROR: temporary file size exceeds temp_file_limit (64kB) ``` + **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** – este parámetro envía mensajes a postgresql.log cuando se eliminan los archivos temporales de una sesión. Este parámetro produce registros después de que la consulta se complete correctamente. Por lo tanto, puede que no ayude a solucionar problemas de consultas activas y de larga ejecución. El ejemplo siguiente muestra que, cuando la consulta se completa correctamente, las entradas se registran en el archivo postgresql.log y se limpian los archivos temporales. ``` 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; ``` + **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** – esta función que está disponible desde RDS para PostgreSQL 13 y versiones posteriores proporciona visibilidad sobre el uso actual de los archivos temporales. La consulta completada no aparece en los resultados de la función. En el siguiente ejemplo, puede ver los resultados de esta función. ``` postgres=>select * from pg_ls_tmpdir(); ``` ``` name | size | modification -----------------+------------+------------------------ pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00 pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00 pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00 pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00 pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00 (7 rows) ``` ``` postgres=>select query from pg_stat_activity where pid = 8355; query ---------------------------------------------------------------------------------------- select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid (1 row) ``` El nombre del archivo incluye el ID de procesamiento (PID) de la sesión que generó el archivo temporal. Una consulta más avanzada, como en el ejemplo siguiente, realiza una suma de los archivos temporales de cada PID. ``` postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid; ``` ``` pid | count | sum ------+------------------- 8355 | 2 | 2144501760 8351 | 2 | 2090770432 8327 | 1 | 1072250880 8328 | 2 | 2144501760 (4 rows) ``` + **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** – si activa el parámetro pg\$1stat\$1statements, puede ver el uso medio de archivos temporales por llamada. Puede identificar el query\$1id de la consulta y usarlo para examinar el uso de archivos temporales, como se muestra en el siguiente ejemplo. ``` postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%'; ``` ``` queryid ---------------------- -7170349228837045701 (1 row) ``` ``` postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701; ``` ``` queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call ----------------------+---------------------------+-------+-------------------------+---------------------------- -7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678 (1 row) ``` + **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`**: en el panel de Información sobre el rendimiento, puede ver el uso temporal de los archivos activando las métricas **temp\$1bytes** y **temp\$1files**. A continuación, puede ver la media de estas dos métricas y cómo se corresponden con la carga de trabajo de la consulta. La vista de Información sobre el rendimiento no muestra específicamente las consultas que generan los archivos temporales. Sin embargo, al combinar Información sobre el rendimiento con la consulta que se muestra para `pg_ls_tmpdir`, puede solucionar problemas, realizar análisis y determinar los cambios en la carga de trabajo de la consulta. Para obtener más información sobre cómo analizar métricas y consultas con Información de rendimiento, consulte [Análisis de métricas mediante el panel de Información sobre rendimiento](USER_PerfInsights.UsingDashboard.md). Para ver un ejemplo sobre la visualización del uso de archivos temporales con Información de rendimiento, consulte [Visualización del uso de archivos temporales con Información de rendimiento](PostgreSQL.ManagingTempFiles.Example.md) # Visualización del uso de archivos temporales con Información de rendimiento Puede usar Información de rendimiento para consultar el uso de archivos temporales activando las métricas **temp\$1bytes** y **temp\$1files**. En Información de rendimiento, la vista no muestra las consultas específicas que generan archivos temporales; sin embargo, si combina Información de rendimiento con la consulta mostrada para `pg_ls_tmpdir`, puede solucionar problemas, realizar análisis y determinar cuáles son los cambios necesarios en la carga de trabajo de consultas. 1. En el panel de Información sobre el rendimiento, elija **Administrar métricas**. 1. Elija las **Métricas de la base de datos** y seleccione las métricas **temp\$1bytes** y **temp\$1files** como se muestra en la siguiente captura de pantalla. ![\[Las métricas se muestran en el gráfico.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/rpg_mantempfiles_metrics.png) 1. En la pestaña **Principales SQL**, seleccione el icono **Preferencias**. 1. En la ventana **Preferencias**, active las siguientes estadísticas para que aparezcan en la pestaña **Principales SQL** y seleccione **Continuar**. + Escrituras temporales por segundo + Lecturas temporales por segundo + Escritura temporal en bloque por llamada + Lectura temporal en bloque por llamada 1. El archivo temporal se divide cuando se combina con la consulta mostrada para `pg_ls_tmpdir`, como se observa en el siguiente ejemplo. ![\[Consulta que muestra el uso de archivos temporales.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/rpg_mantempfiles_query.png) Los eventos `IO:BufFileRead` y `IO:BufFileWrite` se producen cuando las consultas principales de la carga de trabajo crean archivos temporales a menudo. Puede utilizar la Información de rendimiento para identificar las principales consultas pendientes en `IO:BufFileRead` e `IO:BufFileWrite` mediante la revisión del promedio de sesiones activas (AAS) en las secciones de carga de base de datos y SQL principales. ![\[IO:BufFileRead e IO:BufFileWrite en el gráfico.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/perfinsights_IOBufFile.png) Para obtener más información sobre cómo analizar las consultas principales y cargar mediante eventos de espera con Información de Rendimiento, consulte [Información general sobre la pestaña Top SQL (SQL principal)](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Debe identificar y ajustar las consultas que provocan el aumento del uso de archivos temporales y los eventos de espera relacionados. Para obtener más información sobre estos eventos de espera y su corrección, consulte [IO:BufFileRead e IO:BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.iobuffile.html). **nota** El parámetro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) controla cuándo se agota la memoria de la operación de ordenación y los resultados se escriben en archivos temporales. Se recomienda no cambiar la configuración de este parámetro por encima del valor predeterminado, ya que haría que cada sesión de base de datos consumiera más memoria. Además, una sola sesión que realiza combinaciones y ordenaciones complejas puede realizar operaciones paralelas en las que cada operación consume memoria. Como práctica recomendada, cuando tenga un informe de gran tamaño con múltiples combinaciones y ordenaciones, defina este parámetro en el nivel de sesión mediante el comando `SET work_mem`. Por tanto, el cambio solo se aplica a la sesión actual y no cambia el valor globalmente.