Propongo leer la transcripción del informe de principios de 2016 de Andrey Salnikov "Errores típicos en las aplicaciones que conducen a la hinchazón en postgresql"
En este informe, analizaré los principales errores en las aplicaciones que ocurren en la etapa de diseño y escritura del código de la aplicación. Y tomaré solo aquellos errores que conducen a la hinchazón en Postgresql. Como regla, este es el principio del fin del rendimiento de su sistema como un todo, aunque inicialmente no se vieron requisitos previos para esto.
¡Encantado de dar la bienvenida a todos! Este informe no es tan técnico como el anterior de mi colega. Esta charla está dirigida a los desarrolladores de sistemas back-end principalmente porque tenemos una cantidad bastante grande de clientes. Y todos cometen los mismos errores. Te hablaré de ellos. Explicaré a qué fatal y malo conducen estos errores.
¿Por qué se cometen errores? Se realizan por dos motivos: al azar, tal vez funcione por desconocimiento de algunos mecanismos que se dan a nivel entre la base y la aplicación, así como en la propia base.
Te daré tres ejemplos con imágenes terribles de cómo las cosas se pusieron mal. Describiré brevemente el mecanismo que ocurre allí. Y cómo lidiar con ellos, cuándo sucedieron y qué métodos preventivos usar para evitar errores. Te contaré sobre herramientas auxiliares y te daré enlaces útiles.
Usé una base de datos de prueba donde tenía dos tablas. Una placa con cuentas de clientes, la otra con operaciones en estas cuentas. Y con cierta periodicidad, actualizamos los saldos de estas cuentas.
Los datos iniciales de la placa: es bastante pequeña, 2 MB. El tiempo de respuesta de la base de datos y en concreto de la placa también es muy bueno. Y una carga bastante buena: 2 operaciones por segundo en la placa.
Y a través de este informe, les mostraré gráficos para que quede claro lo que está sucediendo. Siempre habrá 2 diapositivas con gráficos. La primera diapositiva es lo que sucede en general en el servidor.
Y en esta situación, vemos que realmente tenemos un plato pequeño. El índice es pequeño en 2 MB. Este es el primer gráfico a la izquierda.
El tiempo de respuesta promedio en todo el servidor también es estable, pequeño. Este es el gráfico superior derecho.
El gráfico inferior izquierdo son las transacciones más largas. Podemos ver que las transacciones se están completando rápidamente. Y el autovacío no funciona aquí todavía, porque era una prueba de arranque. Entonces funcionará y nos será útil.
La segunda diapositiva siempre estará dedicada a la placa de prueba. En esta situación, actualizamos constantemente los saldos de cuenta del cliente. Y vemos que el tiempo de respuesta medio para la operación de actualización es bastante bueno, menos de un milisegundo. Vemos que los recursos del procesador (este es el gráfico superior derecho) también se consumen de manera uniforme y bastante pequeña.
El gráfico inferior derecho muestra cuánta memoria operativa y de disco recorremos en busca de nuestra línea deseada antes de actualizarla. Y el número de operaciones en la placa es de 2 por segundo, como decía al principio.
Y ahora tenemos una tragedia. Por alguna razón, se produce una transacción olvidada hace mucho tiempo. Las razones suelen ser todas banales:
- Una de las más comunes es que empezamos a acceder a un servicio externo en el código de la aplicación. Y este servicio no nos contesta. Es decir, abrimos una transacción, hicimos un cambio en la base de datos y pasamos de la aplicación a leer correo o a otro servicio dentro de nuestra infraestructura, y por alguna razón no nos contesta. Y nuestra sesión colgó en un estado: no se sabe cuándo se resolverá.
- La segunda situación es cuando ocurrió una excepción en nuestro código por alguna razón. Y no procesamos el cierre de la transacción en la excepción. Y tenemos una sesión pendiente con una transacción abierta.
- Y el último también es bastante común. Este es un código de mala calidad. Algunos marcos abren una transacción. Se cuelga, y puede que no sepas en la aplicación que lo tienes colgado.
¿Adónde llevan esas cosas?
Al hecho de que nuestras tablas e índices están comenzando a crecer dramáticamente. Este es exactamente el mismo efecto de hinchazón. Para la base de datos, esto se expresará en el hecho de que tendremos un aumento muy fuerte en el tiempo de respuesta de la base de datos, aumentará la carga en el servidor de la base de datos. Y como resultado, nuestra aplicación sufrirá. Porque si en su código gastó 10 milisegundos en una solicitud a la base de datos, 10 milisegundos en su lógica, entonces su función funcionó en 20 milisegundos. Y ahora tu situación será muy triste.
Y veamos qué pasa. El gráfico inferior izquierdo muestra que tenemos una transacción larga larga. Y si miramos el gráfico superior izquierdo, vemos que el tamaño de la tabla saltó de dos megas a 300 megas. Al mismo tiempo, la cantidad de datos en la tabla no ha cambiado, es decir, hay una cantidad bastante grande de basura.
La situación general en términos del tiempo de respuesta promedio del servidor también ha cambiado en varios órdenes de magnitud. Es decir, todas las solicitudes en el servidor comenzaron a ceder por completo. Y al mismo tiempo se lanzaron los procesos internos de Postgres frente al autovacuum, que están tratando de hacer algo y consumir recursos.
¿Qué le pasa a nuestro plato? Lo mismo. El tiempo de respuesta promedio en la tableta saltó varios órdenes de magnitud. Si específicamente en términos de recursos consumidos, vemos que la carga en el procesador ha aumentado considerablemente. Este es el gráfico superior derecho. Y ha aumentado porque el procesador tiene que pasar por un montón de líneas inútiles en busca de la que necesita. Este es el gráfico inferior derecho. Y como resultado, la cantidad de llamadas por segundo comenzó a disminuir mucho, porque la base de datos no tiene tiempo para procesar la misma cantidad de solicitudes.
Necesitamos volver a la vida. Nos subimos a Internet y descubrimos que las transacciones largas generan un problema. Encontramos y eliminamos esta transacción. Y todo nos va bien. Todo funciona como deberia.
Nos calmamos, pero al rato empezamos a notar que la aplicación no funciona como antes de la emergencia. Las solicitudes se procesan de todos modos más lentamente y mucho más lentamente. Una y media o dos veces más lento específicamente en mi ejemplo. La carga en el servidor también es mayor que antes del accidente.
Y la pregunta: "¿Qué pasa con la base en este momento?". Y con base hay una situación siguiente. En el gráfico de transacciones, puede ver que se ha detenido y que realmente no hay transacciones a largo plazo. Pero las dimensiones de la placa durante el accidente crecieron fatalmente. Y no ha disminuido desde entonces. El tiempo promedio en la base se ha estabilizado. Y las respuestas parecen ir adecuadamente con una velocidad aceptable para nosotros. Autovacuum se volvió más activo y comenzó a hacer algo con la tableta, porque necesita palear más datos.
En concreto, en el marcador de prueba, donde cambiamos los saldos: el tiempo de respuesta a la solicitud parece haber vuelto a la normalidad. Pero, de hecho, es una vez y media mayor.
Y por la carga en el procesador, vemos que la carga en el procesador no volvió al valor deseado antes del bloqueo. Y las razones se encuentran en el gráfico inferior derecho. Se puede ver que hay una búsqueda de cierta cantidad de memoria. Es decir, para buscar la línea deseada, gastamos los recursos del servidor de la base de datos al clasificar datos inútiles. El número de transacciones por segundo se ha estabilizado.
En general, bien, pero la situación es peor de lo que era. Degradación explícita de la base de datos como consecuencia de nuestra aplicación que trabaja con esta base de datos.
Y para entender lo que está pasando allí, si no estuviste en el informe anterior, ahora un poco de teoría. Teoría sobre el proceso interno. ¿Por qué autovacuum y qué hace?
Literalmente en pocas palabras para la comprensión. En algún momento tenemos una mesa. Tenemos filas en la tabla. Estas líneas pueden estar activas, en vivo, las necesitamos ahora. Están marcados en verde en la imagen. Y hay plazos que ya han funcionado, se han actualizado, han aparecido nuevas entradas en ellos. Y se marcan que ya no son interesantes para la base de datos. Pero yacen en la mesa debido a las peculiaridades de Postgres.
¿Por qué necesita un autoaspirador? Autovacuum llega en algún momento, llama a la base de datos y le pregunta: "Dame la identificación de la transacción más antigua que está actualmente abierta en la base de datos". La base de datos devuelve esta identificación. Y el autovacío, apoyándose en él, recorre las líneas de la tabla. Y si ve que algunas líneas han sido modificadas por transacciones mucho más antiguas, entonces tiene derecho a marcarlas como líneas que podemos reutilizar en el futuro escribiendo nuevos datos allí. Este es un proceso en segundo plano.
En este momento seguimos trabajando con la base de datos, seguimos haciendo algunos cambios en la tabla. Y sobre estas líneas, que podemos reutilizar, escribimos nuevos datos. Y de esta manera obtenemos un ciclo, es decir, algunas líneas antiguas muertas aparecen allí todo el tiempo, en lugar de ellas escribimos las nuevas líneas que necesitamos. Y este es el estado normal para que funcione PostgreSQL.
¿Qué pasó durante el accidente? ¿Cómo se llevó a cabo este proceso?
Teníamos un plato en alguna condición, algunos vivos, algunos plazos. El autovacío ha llegado. Le preguntó a la base de datos cuál es nuestra transacción más antigua, cuál es su identificación. Tengo esta identificación, que puede tener muchas horas, tal vez diez minutos. Depende de qué tan pesada sea la carga que tenga en la base de datos. Y fue a buscar líneas que pueda marcar como reutilizadas. Y no encontré tales líneas en nuestra mesa.
Pero en este momento seguimos trabajando con la mesa. Hacemos algo en él, lo actualizamos, cambiamos los datos. ¿Qué debe hacer la base de datos en este momento? No tiene más remedio que agregar nuevas líneas al final de la tabla existente. Y además a nosotros comienza a inflarse la dimensión de la mesa.
Realmente necesitamos líneas verdes para trabajar. Pero durante tal problema, resulta que el porcentaje de líneas verdes es extremadamente bajo en todo el volumen de la mesa.
Y cuando ejecutamos una consulta, la base de datos tiene que pasar por todas las líneas, tanto rojas como verdes, para encontrar la línea correcta. Y el efecto de inflar la tabla con datos inútiles se llama "hinchazón", que también consume nuestro espacio en disco. ¿Recuerdas, eran 2 MB, ahora son 300 MB? Ahora cambie megabytes a gigabytes y perderá todos los recursos de su disco con bastante rapidez.
¿Cuáles son las implicaciones para nosotros?
- En mi ejemplo, la tabla y el índice han crecido 150 veces. Algunos de nuestros clientes han tenido más casos fatales cuando el espacio en disco simplemente comenzó a agotarse.
- Las mesas nunca se encogerán por sí solas. Autovacuum en algunos casos puede cortar la cola de la mesa si solo hay líneas muertas. Pero dado que hay una rotación constante, una línea verde puede colgar al final y no actualizarse, y todo el resto se registrará en algún lugar al comienzo de la placa. Pero este es un evento tan improbable que su mesa en sí misma disminuirá de tamaño, por lo que no debe esperarlo.
- La base de datos necesita clasificar toda la pila de líneas inútiles. Y estamos desperdiciando recursos de disco, desperdiciando recursos de procesador y electricidad.
- Y esto afecta directamente a nuestra aplicación, porque si al principio gastamos 10 milisegundos en una solicitud, 10 milisegundos en nuestro código, durante el bloqueo comenzamos a gastar un segundo en una solicitud y 10 milisegundos en el código, es decir, una orden de disminución del rendimiento de la aplicación de magnitud. Y cuando se resolvió el accidente, comenzamos a gastar 20 milisegundos por solicitud, 10 milisegundos por código. Esto significa que todavía nos hundimos una vez y media en términos de rendimiento. Y todo esto se debe a una transacción que se colgó y, quizás, por nuestra culpa.
- Y la pregunta: "¿Cómo puedo recuperar todo?" Para que todo esté bien con nosotros y las solicitudes se ejecuten tan rápido como antes del accidente.
Para ello, existe un determinado ciclo de trabajo que se está realizando.
Primero necesitamos encontrar las tablas problemáticas que se han inflado. Entendemos que algunas tablas registran más activamente, otras menos activamente. Y para esto usamos la extensión . Al instalar esta extensión, puede escribir consultas para ayudarlo a encontrar tablas que estén lo suficientemente infladas.
Una vez que haya encontrado estas tablas, es necesario comprimirlas. Ya hay herramientas para esto. En nuestra empresa utilizamos tres herramientas. El primero es el VACUUM FULL incorporado. Es cruel, duro y despiadado, pero a veces es muy útil. и son utilidades de terceros para comprimir tablas. Y son más cuidadosos con la base de datos.
Se utilizan dependiendo de lo que sea más conveniente para usted. Pero hablaré de esto al final. Lo principal es que hay tres herramientas. Hay mucho de donde escoger.
Después de haber corregido todo, asegurándonos de que todo está bien, debemos saber cómo prevenir esta situación en el futuro:
- Es bastante fácil de prevenir. Debe controlar la duración de las sesiones en el servidor maestro. Sesiones particularmente peligrosas en el estado de transacción inactivo. Estos son aquellos que acaban de abrir una transacción, hicieron algo y se fueron, o simplemente colgaron, se perdieron en el código.
- Y para ustedes, como desarrolladores, es importante probar el código en el momento en que se presenten estas situaciones. Esto no es difícil de hacer. Esta será una verificación útil. Evitará muchos problemas "infantiles" asociados con transacciones largas.
En estos gráficos, quería mostrarles cómo cambiaron la tabla y el comportamiento de la base de datos después de pasar VACUUM FULL en la tabla en este caso. Esta no es mi producción.
El tamaño de la mesa volvió inmediatamente a su estado de funcionamiento normal de un par de megabytes. Esto no afectó mucho el tiempo de respuesta promedio en todo el servidor.
Pero específicamente en nuestra tabla de prueba, donde actualizamos los saldos de las cuentas, vemos que el tiempo promedio de respuesta a una solicitud para actualizar los datos en la tableta se redujo a los niveles previos al bloqueo. Los recursos consumidos por el procesador para ejecutar esta solicitud también cayeron a los niveles previos al bloqueo. Y el gráfico inferior derecho muestra que ahora encontramos exactamente la línea que necesitamos de inmediato, sin pasar por la pila de líneas muertas que había antes de que se comprimiera la tabla. Y el tiempo medio de consulta se mantuvo aproximadamente en el mismo nivel. Pero aquí tengo, más bien, el error de mi hardware.
Aquí es donde termina la primera historia. Ella es la más común. Y le pasa a todo el mundo, independientemente de la experiencia del cliente, de lo cualificados que sean los programadores. Tarde o temprano sucede.
La segunda historia, en la que repartimos la carga y optimizamos los recursos del servidor
- Hemos crecido y nos hemos convertido en chicos serios. Y entendemos que tenemos una réplica y nos vendría bien equilibrar la carga: escribir en el Master y leer de la réplica. Y normalmente esta situación se presenta cuando queremos elaborar algún tipo de informes o ETL. Y el negocio está muy feliz por ello. Realmente quiere una variedad de informes con un montón de análisis complejos.
- Los informes duran muchas horas, porque los análisis complejos no se pueden calcular en milisegundos. Nosotros, como tipos valientes, escribimos código. Hacemos en la aplicación de inserción que grabamos en el Máster, realizamos informes en la réplica.
- Distribuimos la carga.
- Todo funciona perfectamente. Estamos bien.
¿Y cómo es esta situación? Específicamente, en estos gráficos, también agregué la duración de las transacciones de la réplica durante la duración de la transacción. Todos los demás gráficos se refieren únicamente al servidor maestro.
En ese momento, mi tablón de informes había crecido. Hay más de ellos. Podemos ver que el tiempo de respuesta promedio del servidor es estable. Podemos ver que tenemos una transacción de ejecución prolongada en la réplica que se ejecuta durante 2 horas. Vemos el trabajo silencioso del autovacío, que procesa líneas muertas. Y estamos todos bien.
Específicamente, según la tableta de prueba, continuamos actualizando los saldos de las cuentas allí. Y también tenemos un tiempo de respuesta estable a pedido, consumo de recursos estable. Todo está bien con nosotros.
Todo está bien hasta el momento en que estos informes comienzan a dispararnos sobre un conflicto con la replicación. Y disparan a intervalos regulares.
Nos conectamos en línea y comenzamos a leer por qué sucede esto. Y encontramos una solución.
La primera solución es aumentar la latencia de replicación. Sabemos que nuestro informe dura 3 horas. Establezca el retraso de la replicación en 3 horas. Empezamos todo, pero aún seguimos teniendo problemas con el hecho de que los informes a veces son devueltos.
Queremos que todo sea perfecto. Vayamos más lejos. Y encontramos una configuración genial en Internet: hot_standby_feedback. Lo encendemos. Hot_standby_feedback nos permite mantener el autovacío ejecutándose en el Maestro. Por lo tanto, nos deshacemos por completo de los conflictos de replicación. Y todos trabajamos bien con los informes.
¿Y qué está pasando con el servidor Maestro en este momento? Y con el servidor Master, tenemos un desastre total. Ahora estamos viendo gráficos con ambas configuraciones activadas. Y vemos que la sesión en la réplica de alguna manera comenzó a influir en la situación en el servidor maestro. Sí impacta porque ha suspendido el autovacío que limpia las líneas muertas. El tamaño de nuestra mesa se ha disparado de nuevo. El tiempo promedio de ejecución de consultas en toda la base de datos también se disparó. Los autovacíos se apretaron un poco.
En concreto, en nuestra placa vemos que la actualización de datos en ella también saltó por los aires. El consumo de recursos del procesador también ha aumentado considerablemente. Nuevamente iteramos sobre una gran cantidad de líneas muertas e inútiles. Y el tiempo de respuesta en esta tableta, el número de transacciones ha disminuido.
¿Cómo se verá si no sabemos de lo que estaba hablando antes?
- Empezamos a buscar problemas. Si nos encontramos con problemas en la primera parte, sabemos que ese puede ser el motivo de una transacción larga y nos subimos al Máster. El problema es con el Maestro. Salchichas él. Está calentando, tiene un promedio de carga de menos de cien.
- Las solicitudes se ralentizan allí, pero no vemos transacciones a largo plazo allí. Y no entendemos lo que está pasando. No sabemos dónde mirar.
- Comprobación del hardware del servidor. Tal vez nuestra incursión se ha derrumbado. Tal vez quemamos la barra de memoria. Sí, cualquier cosa puede ser. Pero no, los servidores son nuevos, todo funciona bien.
- Todos corren: administradores, desarrolladores y el director. Nada ayuda.
- Y en algún momento, todo de repente comienza a corregirse.
En la réplica, en ese momento, la solicitud funcionó y se fue. Hemos recibido un informe. El negocio sigue feliz. Como veis, nuestra mesa ha vuelto a crecer y no va a disminuir. En el gráfico con las sesiones, dejé un trozo de esta transacción larga de la réplica, para que puedas evaluar cuánto tiempo pasa hasta que se estabiliza la situación.
La sesión se ha ido. Y solo después de un tiempo, el servidor llega más o menos en orden. Y el tiempo de respuesta promedio para las solicitudes en el servidor maestro vuelve a la normalidad. Porque, finalmente, el autovacío tuvo la oportunidad de limpiar, marque estos plazos. Y empezó a hacer su trabajo. Y qué rápido lo hace, así de rápido estaremos en orden.
En la tabla de prueba, donde actualizamos los saldos de las cuentas, vemos exactamente la misma imagen. El tiempo promedio de actualización de la cuenta también se está normalizando gradualmente. Los recursos consumidos por el procesador también se reducen. Y el número de transacciones por segundo vuelve a la normalidad. Pero de nuevo, volvemos a la normalidad, no a la que teníamos antes del accidente.
En cualquier caso, obtenemos una reducción en el rendimiento, como en el primer caso, una vez y media o dos veces, y en ocasiones incluso más.
Parece que lo hemos hecho todo bien. Distribuir la carga. El equipo no está inactivo. Según la mente, rompieron las solicitudes, pero aún así todo salió mal.
- ¿No habilitar hot_standby_feedback? Sí, no se recomienda encenderlo sin razones particularmente fuertes. Porque este giro afecta directamente al Servidor Maestro y suspende el trabajo del autovacío allí. Al encenderlo en alguna réplica y olvidarse de él, puede matar al Maestro y tener grandes problemas con la aplicación.
- ¿Aumentar max_standby_streaming_delay? Sí, para informes lo es. Si tiene un informe de tres horas y no desea que se bloquee debido a conflictos de replicación, simplemente aumente la demora. Un informe extenso nunca requiere datos que hayan ingresado a la base de datos en este momento. Si lo tiene durante tres horas, entonces lo está ejecutando durante un período de datos antiguo. Y usted, esas tres horas de retraso, esas seis horas de retraso, no jugarán ningún papel, pero recibirán informes constantemente y no sabrán los problemas con su caída.
- Naturalmente, debe controlar las sesiones largas en las réplicas, especialmente si decide habilitar hot_standby_feedback en una réplica. Porque podría ser cualquier cosa. Le dimos este comentario al desarrollador para que probara las solicitudes. Escribió una petición loca. Comenzó y fue a tomar té, y obtuvimos al Maestro establecido. O lanzamos la aplicación incorrecta allí. Las situaciones son variadas. Las sesiones en las réplicas deben controlarse con el mismo cuidado que en el maestro.
- Y si tiene consultas rápidas y largas sobre réplicas, en este caso es mejor dividirlas para distribuir la carga. Este es un enlace a streaming_delay. Para que sea rápido tener una réplica con un pequeño retraso en la replicación. Para las solicitudes de informes de ejecución prolongada, tenga una réplica que pueda retrasarse 6 horas, un día. Esta es una situación completamente normal.
Eliminamos las consecuencias de la misma manera:
- Encontramos mesas infladas.
- Y comprimimos con la herramienta más conveniente que nos convenga.
La segunda historia termina aquí. Pasemos a la tercera historia.
También bastante común para nosotros, en el que hacemos la migración.
- Cualquier producto de software crece. Los requisitos están cambiando. En cualquier caso, queremos desarrollar. Y sucede que necesitamos actualizar los datos de la tabla, es decir, ejecutar la actualización en términos de nuestra migración a la nueva funcionalidad que estamos implementando como parte de nuestro desarrollo.
- El antiguo formato de datos no se adapta. Digamos que ahora pasamos a la segunda tabla, donde tengo operaciones en estas cuentas. Y, digamos que estaban en rublos, y decidimos aumentar la precisión y hacerlo en kopeks. Y para esto necesitamos hacer una actualización: multiplicar el campo con el monto de la operación por cien.
- En el mundo actual, utilizamos herramientas de control de versiones de bases de datos automatizadas. Digamos . Registramos nuestra migración allí. Lo probamos en nuestra base de pruebas. Todo esta bien. La actualización se está ejecutando. Los bloques funcionan por un tiempo, pero obtenemos datos actualizados. Y podemos lanzar una nueva funcionalidad en esto. Todo probado y revisado. Todo confirmado.
- Realizó el trabajo planificado, realizó la migración.
Aquí está la migración con la actualización presentada frente a usted. Como tengo operaciones en cuentas, la placa era de 15 GB. Y como estamos actualizando cada línea, hemos duplicado la placa con la actualización, porque hemos sobrescrito cada línea.
Durante la migración, no pudimos hacer nada con esta etiqueta, porque todas las solicitudes se pusieron en cola y esperaron a que finalizara esta actualización. Pero aquí quiero llamar su atención sobre los números que están en el eje vertical. Es decir, tenemos un tiempo de solicitud promedio antes de la migración en la región de 5 milisegundos y una carga en el procesador, el número de operaciones de bloque para leer la memoria del disco es inferior a 7,5.
Migramos y volvimos a tener problemas.
La migración fue exitosa, pero:
- La antigua funcionalidad comenzó a ejecutarse por más tiempo.
- La mesa ha vuelto a crecer de tamaño.
- La carga en el servidor ha vuelto a ser más de lo que era.
- Y, por supuesto, todavía estamos jugando con la funcionalidad que funcionó bien, la mejoramos un poco.
Y esto es nuevamente hinchazón, que nuevamente estropea nuestras vidas.
Aquí demuestro que la mesa, al igual que los dos casos anteriores, no va a volver a los tamaños anteriores. La carga promedio en el servidor parece ser adecuada.
Y si pasamos a la tabla con cuentas, veremos que el tiempo promedio de solicitud se ha duplicado para esta tabla. La carga en el procesador y el número de líneas a clasificar en la memoria saltó por encima de 7,5, pero fue menor. Y saltó en el caso de los procesadores por 2 veces, en el caso de las operaciones de bloque por 1,5 veces, es decir, obtuvimos una degradación en el rendimiento del servidor. Y como resultado, la degradación del rendimiento de nuestra aplicación. Al mismo tiempo, el número de llamadas se mantuvo aproximadamente al mismo nivel.
Y aquí lo principal es entender cómo hacer este tipo de migraciones correctamente. Y necesitan ser hechos. Hacemos estas migraciones con bastante regularidad.
- Estas grandes migraciones no se realizan automáticamente. Siempre deben ser controlados.
- Necesita la supervisión de una persona bien informada. Si tiene un DBA en el equipo, deje que el DBA lo haga. Es su trabajo. Si no, que lo haga la persona más experimentada, que sepa trabajar con bases de datos.
- El nuevo esquema de la base de datos, incluso si actualizamos una columna, siempre lo preparamos por etapas, es decir, antes de que se implemente la nueva versión de la aplicación:
- Se añaden nuevos campos en los que escribiremos solo los datos actualizados.
- Transferimos datos del campo antiguo al campo nuevo en partes pequeñas. ¿Por qué estamos haciendo esto? Primero, siempre controlamos el proceso de este proceso. Sabemos que ya hemos transferido tantos lotes y nos quedan tantos.
- Y el segundo efecto positivo es que entre cada uno de esos lotes cerramos una transacción, abrimos una nueva, y esto hace posible que el autovacío funcione según la placa, para marcar plazos para la reutilización.
- Para las líneas que aparecerán durante el funcionamiento de la aplicación (todavía tenemos la aplicación anterior), agregamos un disparador que escribe nuevos valores en nuevos campos. En nuestro caso, se trata de una multiplicación por cien del valor anterior.
- Si somos completamente obstinados y queremos el mismo campo, luego de completar todas las migraciones y antes de lanzar la nueva versión de la aplicación, simplemente cambiamos el nombre de los campos. Los viejos en algún nombre inventado, y renombramos los nuevos campos a los viejos.
- Y solo después de eso lanzamos una nueva versión de la aplicación.
Y al mismo tiempo, no nos hincharemos ni cederemos en el rendimiento.
Este es el final de la tercera historia.
Y ahora un poco más sobre las herramientas que mencioné en la primera historia.
Antes de buscar bloat, debes instalar la extensión .
Para que no inventes solicitudes, ya hemos escrito estas solicitudes en nuestro trabajo. Puedes usarlos. Hay dos solicitudes aquí.
- El primero lleva bastante tiempo, pero te mostrará los valores exactos de bloat según la tabla.
- El segundo funciona más rápido y es muy efectivo cuando necesita evaluar rápidamente si hay una hinchazón o no en la tabla. Y también debe comprender que siempre hay una hinchazón en una tabla de Postgres. Esta es una característica de su modelo MVCC.
- Y un 20 % de hinchazón está bien para las mesas en la mayoría de los casos. Es decir, no debes preocuparte y comprimir esta tabla.
Descubrimos cómo identificar las tablas que están hinchadas con nosotros, además, cuando están hinchadas con datos inútiles.
Ahora sobre cómo arreglar la hinchazón:
- Si tenemos una placa pequeña y buenos discos, es decir, en una placa de hasta un gigabyte, es muy posible usar VACUUM FULL. Te quitará un bloqueo exclusivo durante unos segundos, y está bien, pero lo hará todo de forma rápida y dura. ¿Qué hace VACUUM FULL? Toma un bloqueo exclusivo en la tabla y reescribe las filas en vivo de las tablas antiguas a la nueva tabla. Y al final los reemplaza. Elimina archivos antiguos, sustituye los nuevos por los antiguos. Pero mientras dure su trabajo, tiene un bloqueo exclusivo sobre la mesa. Esto significa que no puedes hacer nada con esta tabla: ni escribir en ella, ni leerla, ni modificarla. Y VACUUM FULL requiere espacio adicional en disco para escribir datos.
- Siguiente herramienta . Por su principio, es muy similar a VACUUM FULL, porque también sobrescribe datos de archivos antiguos a nuevos y los reemplaza en la tabla. Pero al mismo tiempo, no toma un bloqueo exclusivo en la mesa al comienzo de su trabajo, sino que lo toma solo en el momento en que tiene datos listos para reemplazar los archivos. Tiene los mismos requisitos de recursos de disco que VACUUM FULL. Necesita espacio adicional en el disco, y esto a veces es crítico si tiene tablas de terabytes. Y es bastante voraz con el procesador, porque está trabajando activamente con E / S.
- La tercera utilidad es . Trata los recursos con más cuidado, porque funciona con principios ligeramente diferentes. La esencia principal de pgcompacttable es que mueve todas las filas activas al principio de la tabla con actualizaciones en la tabla. Y luego comienza el vacío en esta tabla, porque sabemos que tenemos filas vivas al principio y filas muertas al final. Y el vacío mismo corta esta cola, es decir, no requiere mucho espacio adicional en el disco. Y al mismo tiempo, todavía puede verse exprimido por los recursos.
Todo con herramientas.
Si encuentra interesante el tema de la hinchazón en términos de profundizar más, aquí hay algunos enlaces útiles para usted:
- es el informe de mi colega. Es general acerca de hacia dónde va el lugar de Postgres en el curso de su trabajo y vida. Y hay una pieza técnica muy grande y detallada para los administradores de bases de datos sobre la hinchazón.
- es un enlace a nuestro repositorio, donde almacenamos un montón de scripts útiles para comprobar el estado de la base de datos. Allí puede encontrar secuencias de comandos de búsqueda hinchadas.
- и enlaces a herramientas que le ayudarán a comprimir las placas.
- Esta es una publicación de mi colega. Allí analiza con bastante seriedad y técnicamente la hinchazón en detalle ya a un nivel cercano a los administradores.
Aquí traté de mostrar una historia de terror para los desarrolladores, porque son nuestros clientes directos de las bases de datos y deben entender a qué y a qué conducen las acciones. Espero haber tenido éxito. ¡Gracias por su atención!
preguntas
¡Gracias por el informe! Usted habló sobre cómo se pueden identificar los problemas. ¿Cómo se les puede advertir? Es decir, tuve una situación en la que las solicitudes se colgaban no solo porque recurrieron a algunos servicios externos. Fueron solo algunas uniones salvajes. Hubo algunas solicitudes pequeñas e inofensivas que se mantuvieron durante un día y luego comenzaron a hacer algún tipo de tontería. Es decir, es muy similar a lo que estás describiendo. ¿Cómo rastrearlo? Siéntese y mire constantemente, ¿qué solicitud está atascada? ¿Cómo se puede prevenir esto?
En este caso, esta es una tarea de los administradores de su empresa, no necesariamente del DBA.
soy administrador
PostgreSQL tiene una vista llamada pg_stat_activity que muestra las consultas pendientes. Y se puede ver cuánto tiempo se cuelga allí.
¿Tengo que venir cada 5 minutos y mirar?
Configura cron y comprueba. Si tienes una solicitud larga, escribe una carta y listo. Es decir, no es necesario mirar con los ojos, esto se puede automatizar. Recibirás una carta, respondes a ella. O puede disparar automáticamente.
¿Hay razones claras por las que esto está sucediendo?
He enumerado algunos. Otros ejemplos más complejos. Y puede haber una larga conversación.
¡Gracias por el informe! Quería aclarar sobre la utilidad pg_repack. Si no requiere un bloqueo exclusivo, entonces...
Ella hace un candado exclusivo.
... entonces podría perder datos. ¿No debería mi aplicación estar grabando algo en este momento?
No, funciona silenciosamente con la tabla, es decir, pg_repack primero transfiere todas las líneas vivas que hay. Naturalmente, hay algún tipo de registro en la tabla. Él simplemente lanza esta cola de caballo.
Es decir, ¿lo sigue haciendo al final?
Al final, requiere un bloqueo exclusivo para intercambiar estos archivos.
¿Será más rápido que VACUUM FULL?
VACUUM FULL, como comenzó, inmediatamente tomó un bloqueo exclusivo. Y hasta que no haga todo, no la dejará ir. Y pg_repack toma un bloqueo exclusivo solo al momento de reemplazar archivos. En este punto, no escribes allí, pero los datos no se perderán, todo estará en orden.
¡Hola! Hablaste del trabajo de autovacuum. Había un gráfico con celdas rojas, amarillas y verdes del registro. Es decir, los amarillos: los marcó como eliminados. Y como resultado, ¿puedes escribir algo nuevo en ellos?
Sí. Postgres no elimina filas. Él tiene tal especificidad. Si actualizamos la línea, marcamos la anterior como eliminada. La identificación de la transacción que cambió esta línea aparece allí y escribimos una nueva línea. Y tenemos sesiones que potencialmente pueden leerlos. En algún momento, se vuelven bastante viejos. Y la esencia del autovacío es que recorre estas líneas y las marca como innecesarias. Y allí puedes sobrescribir los datos.
Entiendo. Pero la pregunta no es sobre eso. no estuve de acuerdo Digamos que tenemos una mesa. Tiene campos de tamaño variable. Y si trato de insertar algo nuevo, es posible que simplemente no encaje en la celda anterior.
No, ahí en todo caso se actualiza toda la línea. Postgres tiene dos modelos de almacenamiento. Se selecciona del tipo de datos. Hay datos que se almacenan directamente en la tabla, y también hay datos de tos. Estas son grandes cantidades de datos: texto, json. Se almacenan en tabletas separadas. Y según estas tabletas pasa lo mismo con bloat, es decir, todo es igual. Solo se enumeran por separado.
¡Gracias por el informe! ¿Qué tan aceptable es usar solicitudes de tiempo de espera de estado de cuenta para limitar la duración?
Muy aceptable. Lo usamos en todas partes. Y como no tenemos servicios propios, damos soporte remoto, hay bastante variedad de clientes. Y todos están bastante satisfechos con esto. Es decir, tenemos trabajos en cron que verifican. Es que la duración de las sesiones se negocia con el cliente, ante lo cual no clavamos. Podría ser un minuto, podrían ser 10 minutos. Depende de la carga en la base y su propósito. Pero todos usamos pg_stat_activity.
¡Gracias por el informe! Estoy tratando de probar su informe para mis aplicaciones. Y parece que comenzamos una transacción en todas partes y la completamos explícitamente en todas partes. Si alguna excepción, entonces se produce la misma reversión. Y luego pensé. Después de todo, la transacción puede comenzar no explícitamente. Esto es una pista para la chica, supongo. Si solo hago una actualización de registro, ¿comenzará la transacción en PostgreSQL y solo finalizará cuando se desconecte la conexión?
Si está hablando ahora sobre el nivel de la aplicación, entonces depende del controlador que esté usando, del ORM que esté usando. Hay muchos ajustes allí. Si tiene habilitada la confirmación automática, entonces una transacción comienza allí y se cierra inmediatamente.
Es decir, ¿se cierra inmediatamente después de la actualización?
Depende de la configuración. Nombré una configuración. Esta es la confirmación automática. Ella es bastante común. Si está habilitado, entonces la transacción se abrió y se cerró. A menos que haya dicho explícitamente "iniciar transacción" y "finalizar transacción", pero simplemente haya iniciado una solicitud en la sesión.
¡Hola! ¡Gracias por el informe! Imagine que tenemos una base de datos que crece y crece y luego el servidor se queda sin espacio. ¿Hay alguna herramienta para solucionar esta situación?
El lugar en el servidor de una buena manera necesita ser monitoreado.
Por ejemplo, DBA fue a tomar té, estuvo en un resort, etc.
Cuando se crea un sistema de archivos, se crea al menos algo de espacio de reserva donde no se escriben datos.
¿Qué pasa si es completamente cero?
Allí se llama espacio reservado, es decir, se puede liberar, y dependiendo de qué tan grande se haya creado, se obtiene espacio libre. Por defecto, no sé cuántos hay. Y en otro caso, entregar discos para que tengas un lugar donde realizar una operación de recuperación. Puede eliminar alguna tabla que está garantizado que no necesitará.
¿No hay otras herramientas?
Siempre es artesanal. Y en el lugar se revela qué es mejor hacer ahí, porque hay datos que son críticos, hay no críticos. Y para cada base de datos y aplicación que trabaja con ella, depende del negocio. Siempre se decide en el acto.
¡Gracias por el informe! Tengo dos preguntas. Primero, mostró diapositivas donde se mostró que en el caso de transacciones colgadas, tanto la cantidad de espacio de tabla como el tamaño del índice crecen. Y más adelante en el informe había un montón de utilidades que empaquetan la tableta. ¿Y el índice?
También los empaquetan.
¿Pero el vacío no afecta al índice?
Algunos trabajan con un índice. Por ejemplo pg_rapack, pgcompacttable. El vacío recrea índices, los afecta. VACUUM FULL tiene la esencia de sobrescribirlo todo, es decir, funciona con todos.
Y la segunda pregunta. No entendí por qué los informes sobre las réplicas dependen tanto de la propia replicación. Me pareció que los informes son lectura y la replicación es escritura.
¿Qué causa un conflicto de replicación? Disponemos de un Máster sobre el que se realizan los procesos. Disponemos de autovacío. Autovacuum de hecho, ¿qué hace? Recorta algunas líneas viejas. Si en este momento tenemos una solicitud en la réplica que lee estas líneas antiguas, y en el maestro hubo una situación en la que el vacío automático marcó estas líneas como posibles para reescribirlas, entonces las sobrescribimos. Y recibimos un paquete de datos, cuando tenemos que reescribir las líneas que necesita la solicitud en la réplica, entonces el proceso de replicación esperará el tiempo de espera que configuró. Y luego PostgreSQL decidirá qué es más importante para él. Y la replicación es más importante para él que una solicitud, y disparará la solicitud para realizar estos cambios en la réplica.
Andrés, tengo una pregunta. Estos maravillosos gráficos que mostrasteis durante la presentación, ¿es fruto de algún trabajo de vuestra utilidad? ¿Cómo se hicieron los gráficos?
este es un servicio .
¿Es este un producto comercial?
Sí. Este es un producto comercial.
Fuente: habr.com