Configuración WAL de Postgresql

Hay varios parámetros de configuración relacionados con WAL que afectan el rendimiento de la base de datos. Esta sección explica su uso. Consultar Capítulo 19 para obtener información general sobre la configuración de los parámetros de configuración del servidor.

Puntos de control son puntos en la secuencia de transacciones en los que se garantiza que los archivos de datos de pila e índice se han actualizado con toda la información escrita antes de ese punto de control. En el momento del punto de control, todas las páginas de datos sucios se vacían en el disco y se escribe un registro de punto de control especial en el archivo de registro. (Los registros de cambios se volcaron previamente a los archivos WAL). En caso de una falla, el procedimiento de recuperación de fallas busca en el último registro de punto de control para determinar el punto en el registro (conocido como el registro de rehacer) desde el cual debe comenzar la Operación REDO. Se garantiza que cualquier cambio realizado en los archivos de datos antes de ese punto estará ya en el disco. Por lo tanto, después de un punto de control, los segmentos de registro que preceden al que contiene el registro de rehacer ya no son necesarios y pueden reciclarse o eliminarse. (Cuando se realiza el archivo WAL, los segmentos de registro deben archivarse antes de reciclarse o eliminarse).

El requisito del punto de control de vaciar todas las páginas de datos sucios en el disco puede causar una carga de E / S significativa. Por esta razón, la actividad de los puntos de control se limita para que la E / S comience en el inicio del punto de control y se complete antes de que comience el siguiente punto de control; esto minimiza la degradación del rendimiento durante los puntos de control.

El proceso de puntero de control del servidor realiza automáticamente un punto de control de vez en cuando. Se inicia un punto de control cada checkpoint_timeout segundos, o si max_wal_size está a punto de excederse, lo que ocurra primero. La configuración predeterminada es 5 minutos y 1 GB, respectivamente. Si no se ha escrito WAL desde el punto de control anterior, se omitirán los puntos de control nuevos incluso si checkpoint_timeout ha pasado. (Si se utiliza el archivo WAL y desea establecer un límite inferior en la frecuencia con la que se archivan los archivos para limitar la posible pérdida de datos, debe ajustar el parámetro archive_timeout en lugar de los parámetros del punto de control). También es posible forzar un punto de control. usando el comando SQL CHECKPOINT.

Reducir checkpoint_timeout y / o max_wal_size hace que los puntos de control ocurran con más frecuencia. Esto permite una recuperación más rápida después de la caída, ya que será necesario rehacer menos trabajo. Sin embargo, se debe equilibrar esto con el mayor costo de eliminar las páginas de datos sucias con más frecuencia. Si se establece full_page_writes (como es el predeterminado), hay otro factor a considerar. Para garantizar la coherencia de la página de datos, la primera modificación de una página de datos después de cada punto de control da como resultado el registro de todo el contenido de la página. En ese caso, un intervalo de punto de control más pequeño aumenta el volumen de salida al registro WAL, anulando parcialmente el objetivo de usar un intervalo más pequeño y, en cualquier caso, provocando más E / S de disco.

Los puntos de control son bastante caros, primero porque requieren escribir todos los búferes actualmente sucios, y segundo porque dan como resultado tráfico WAL adicional adicional como se discutió anteriormente. Por lo tanto, es aconsejable establecer los parámetros de puntos de control lo suficientemente altos para que los puntos de control no sucedan con demasiada frecuencia. Como una simple verificación de cordura en sus parámetros de puntos de control, puede establecer el parámetro checkpoint_warning. Si los puntos de control ocurren más cerca que checkpoint_warning segundos, se enviará un mensaje al registro del servidor recomendando aumentar max_wal_size. La aparición ocasional de un mensaje de este tipo no es motivo de alarma, pero si aparece con frecuencia, se deben aumentar los parámetros de control del punto de control. Operaciones masivas como grandes COPY Las transferencias pueden hacer que aparezcan algunas de estas advertencias si no ha configurado max_wal_size suficientemente alto.

Para evitar inundar el sistema de E / S con una ráfaga de escrituras de página, la escritura de búferes sucios durante un punto de control se distribuye durante un período de tiempo. Ese período está controlado por checkpoint_completion_target, que se da como una fracción del intervalo del punto de control. La tasa de E / S se ajusta para que el punto de control finalice cuando la fracción dada de checkpoint_timeout han transcurrido los segundos, o antes max_wal_size se excede, lo que ocurra primero. Con el valor predeterminado de 0.5, se puede esperar que PostgreSQL complete cada punto de control en aproximadamente la mitad del tiempo antes de que comience el siguiente. En un sistema que está muy cerca del rendimiento máximo de E / S durante el funcionamiento normal, es posible que desee aumentar checkpoint_completion_target para reducir la carga de E / S de los puntos de control. La desventaja de esto es que la prolongación de los puntos de control afecta el tiempo de recuperación, porque será necesario mantener más segmentos WAL para su posible uso en la recuperación. A pesar de que checkpoint_completion_target puede establecerse tan alto como 1.0, es mejor mantenerlo por debajo de eso (tal vez 0.9 como máximo) ya que los puntos de control incluyen algunas otras actividades además de escribir búferes sucios. Es muy probable que una configuración de 1.0 dé como resultado que los puntos de control no se completen a tiempo, lo que resultaría en una pérdida de rendimiento debido a una variación inesperada en el número de segmentos WAL necesarios.

En las plataformas Linux y POSIX, checkpoint_flush_after permite forzar al sistema operativo a que las páginas escritas por el punto de control se descarguen en el disco después de un número configurable de bytes. De lo contrario, estas páginas pueden mantenerse en la caché de la página del sistema operativo, provocando un bloqueo cuando fsync se emite al final de un puesto de control. Esta configuración a menudo ayudará a reducir la latencia de las transacciones, pero también puede tener un efecto adverso en el rendimiento; particularmente para cargas de trabajo que son más grandes que shared_buffers, pero más pequeñas que la caché de página del SO.

El número de archivos de segmento WAL en pg_wal directorio depende de min_wal_size, max_wal_size y la cantidad de WAL generada en ciclos de puntos de control anteriores. Cuando los archivos de segmentos de registro antiguos ya no son necesarios, se eliminan o reciclan (es decir, se les cambia el nombre para que se conviertan en segmentos futuros en la secuencia numerada). Si, debido a un pico a corto plazo de la tasa de salida de registros, max_wal_size se excede, los archivos de segmento innecesarios se eliminarán hasta que el sistema vuelva a estar por debajo de este límite. Por debajo de ese límite, el sistema recicla suficientes archivos WAL para cubrir la necesidad estimada hasta el siguiente punto de control y elimina el resto. La estimación se basa en un promedio móvil del número de archivos WAL utilizados en ciclos de puntos de control anteriores. El promedio móvil aumenta inmediatamente si el uso real excede la estimación, por lo que se adapta al uso pico en lugar del uso promedio hasta cierto punto. min_wal_size pone un mínimo en la cantidad de archivos WAL reciclados para uso futuro; esa gran cantidad de WAL siempre se recicla para uso futuro, incluso si el sistema está inactivo y la estimación de uso de WAL sugiere que se necesita poca WAL.

Independientemente de max_wal_size, los megabytes wal_keep_size más recientes de archivos WAL más un archivo WAL adicional se mantienen en todo momento. Además, si se utiliza el archivo WAL, los segmentos antiguos no se pueden eliminar ni reciclar hasta que se archivan. Si el archivo WAL no puede seguir el ritmo al que se genera WAL, o si archive_command falla repetidamente, los archivos WAL antiguos se acumularán en pg_wal hasta que se resuelva la situación. Un servidor en espera lento o fallido que utiliza una ranura de replicación tendrá el mismo efecto (consulte la Sección 26.2.6).

En modo de recuperación de archivo o en espera, el servidor realiza periódicamente puntos de reinicio, que son similares a los puntos de control en funcionamiento normal: el servidor fuerza todo su estado al disco, actualiza el pg_control para indicar que los datos WAL ya procesados ​​no necesitan ser escaneados nuevamente, y luego recicla cualquier archivo de segmento de registro antiguo en el pg_wal directorio. Los puntos de reinicio no se pueden realizar con más frecuencia que los puntos de control en el maestro porque los puntos de reinicio solo se pueden realizar en los registros de puntos de control. Se activa un punto de reinicio cuando se alcanza un registro de punto de control si al menos checkpoint_timeout Han pasado segundos desde el último punto de reinicio, o si el tamaño de WAL está a punto de exceder max_wal_size. Sin embargo, debido a las limitaciones sobre cuándo se puede realizar un punto de reinicio, max_wal_size a menudo se excede durante la recuperación, hasta por el valor de WAL de un ciclo de punto de control. (max_wal_size nunca es un límite estricto de todos modos, por lo que siempre debe dejar suficiente margen para evitar quedarse sin espacio en el disco).

Hay dos funciones WAL internas de uso común: XLogInsertRecord y XLogFlush. XLogInsertRecord se utiliza para colocar un nuevo registro en los búferes WAL en la memoria compartida. Si no hay espacio para el nuevo registro, XLogInsertRecord tendrá que escribir (mover a la caché del kernel) algunos búferes WAL llenos. Esto es indeseable porque XLogInsertRecord se utiliza en cada modificación de bajo nivel de la base de datos (por ejemplo, inserción de filas) en un momento en que se mantiene un bloqueo exclusivo en las páginas de datos afectadas, por lo que la operación debe ser lo más rápida posible. Lo que es peor, escribir búferes WAL también podría forzar la creación de un nuevo segmento de registro, lo que lleva aún más tiempo. Normalmente, los búferes WAL deben escribirse y vaciarse mediante un XLogFlush solicitud, que se realiza, en su mayor parte, en el momento del compromiso de la transacción para garantizar que los registros de la transacción se vacíen en el almacenamiento permanente. En sistemas con alta producción de registros, XLogFlush Es posible que las solicitudes no se produzcan con la frecuencia suficiente para evitar XLogInsertRecord de tener que hacer escrituras. En tales sistemas, se debe aumentar el número de búferes WAL modificando el parámetro wal_buffers. Cuando se establece full_page_writes y el sistema está muy ocupado, la configuración wal_buffers mayor ayudará a suavizar los tiempos de respuesta durante el período inmediatamente posterior a cada punto de control.

El parámetro commit_delay define por cuántos microsegundos un proceso de líder de compromiso de grupo dormirá después de adquirir un bloqueo dentro de XLogFlush, mientras que los seguidores del grupo de confirmación hacen cola detrás del líder. Esta demora permite que otros procesos del servidor agreguen sus registros de confirmación a los búferes de WAL para que la operación de sincronización eventual del líder los vacíe todos. No habrá suspensión si fsync no está habilitado, o si hay menos de commit_siblings en otras sesiones actualmente en transacciones activas; esto evita dormir cuando es poco probable que alguna otra sesión se confirme pronto. Tenga en cuenta que en algunas plataformas, la resolución de una solicitud de suspensión es de diez milisegundos, por lo que cualquier commit_delay establecer entre 1 y 10000 microsegundos tendría el mismo efecto. Tenga en cuenta también que en algunas plataformas, las operaciones de suspensión pueden tardar un poco más de lo solicitado por el parámetro.

Dado que el propósito de commit_delay es permitir que el costo de cada operación de descarga se amortice en las transacciones que se comprometen simultáneamente (potencialmente a expensas de la latencia de la transacción), es necesario cuantificar ese costo antes de que se pueda elegir la configuración de manera inteligente. Cuanto mayor sea el costo, más efectivo commit_delay se espera que aumente el rendimiento de las transacciones, hasta cierto punto. El programa pg_test_fsync se puede usar para medir el tiempo promedio en microsegundos que toma una sola operación de descarga WAL. Un valor de la mitad del tiempo promedio que el programa informa que tarda en vaciarse después de una sola operación de escritura de 8kB es a menudo la configuración más efectiva para commit_delay, por lo que este valor se recomienda como punto de partida para usar al optimizar para una carga de trabajo en particular. Mientras sintoniza commit_delay es particularmente útil cuando el registro WAL se almacena en discos giratorios de alta latencia, los beneficios pueden ser significativos incluso en medios de almacenamiento con tiempos de sincronización muy rápidos, como unidades de estado sólido o matrices RAID con caché de escritura respaldada por batería; pero esto definitivamente debe probarse contra una carga de trabajo representativa. Valores más altos de commit_siblings debe utilizarse en tales casos, mientras que los más pequeños commit_siblings Los valores a menudo son útiles en medios de latencia más alta. Tenga en cuenta que es muy posible que un ajuste de commit_delay que es demasiado alto puede aumentar la latencia de la transacción tanto que el rendimiento total de la transacción sufre.

Cuando commit_delay está establecido en cero (el valor predeterminado), todavía es posible que se produzca una forma de confirmación de grupo, pero cada grupo consistirá solo en sesiones que alcancen el punto en el que necesitan vaciar sus registros de confirmación durante la ventana en la que la descarga anterior operación (si la hay) está ocurriendo. A mayor cliente cuenta un “efecto de pasarela“ tiende a ocurrir, de modo que los efectos del compromiso grupal se vuelven significativos incluso cuando commit_delay es cero y, por lo tanto, establece explícitamente commit_delay tiende a ayudar menos. Configuración commit_delay solo puede ayudar cuando (1) hay algunas transacciones que se comprometen simultáneamente y (2) el rendimiento está limitado hasta cierto punto por la tasa de compromiso; pero con una latencia de rotación alta, esta configuración puede ser eficaz para aumentar el rendimiento de las transacciones con tan solo dos clientes (es decir, un solo cliente comprometido con una transacción hermana).

El parámetro wal_sync_method determina cómo PostgreSQL le pedirá al kernel que fuerce las actualizaciones de WAL al disco. Todas las opciones deben ser iguales en términos de confiabilidad, con la excepción de fsync_writethrough, que a veces puede forzar un vaciado de la caché del disco incluso cuando otras opciones no lo hacen. Sin embargo, es bastante específico de la plataforma cuál será el más rápido. Puede probar las velocidades de diferentes opciones usando el programa pg_test_fsync. Tenga en cuenta que este parámetro es irrelevante si fsync ha sido apagado.

Habilitar el parámetro de configuración wal_debug (siempre que PostgreSQL haya sido compilado con soporte para él) resultará en cada XLogInsertRecord y XLogFlush La llamada WAL se registra en el registro del servidor. Esta opción podría ser reemplazada por un mecanismo más general en el futuro.