Discourse en RDS causa periódicamente muchas esperas Lock:relation para sesiones de creación de GIN index

Instalación
1

Periódicamente vemos que la creación de un índice GIN en post_search_data resulta en muchos Lock:relations en el análisis de rendimiento. Matar la sesión que crea este índice libera todas las sesiones bloqueadas. Lo interesante es que el índice utiliza "concurrently", que se supone que no es una operación de bloqueo. También es interesante por qué lo antepone con temp.

CREATE INDEX CONCURRENTLY temp_idx_recent_regular_post_search_data  ON post_search_data USING GIN(search_data) WHERE NOT private_message AND post_id >= 12431619

También he intentado reducir idle_in_transaction_session_timeout a 10 minutos (inicialmente estaba configurado a 1 día), pero no hizo ninguna diferencia. ¿Alguien más ha tenido un problema así? Si es así, ¿cómo lo manejaron?

Nuestra versión es Discourse 2.7.0 y la versión de Postgres es 13.8. La aplicación y la base de datos no están en docker, sino alojadas individualmente (ec2, rds).

2

No podré ayudarte con el problema específico que planteas, pero ¿hay alguna razón por la que estés usando una versión tan antigua de Discourse? Cuanto más esperes, más probable es que tengas problemas al actualizar. Lo ideal es que siempre estés en la última versión. Además, las actualizaciones incluyen ocasionalmente correcciones de seguridad.

1 me gusta
3

Estoy administrando un sitio en ecs con rds y no he notado ningún problema, pero es una versión actualizada. Es difícil adivinar cuál podría ser el problema sin más detalles de su configuración.

En general, cuando alguien tiene un problema con una versión muy antigua, la primera respuesta es actualizar.

2 Me gusta
4

Entendido. Gracias por tus comentarios.

1 me gusta