Hemos estado experimentando sobrecarga de CPU recientemente.
Hemos logrado identificarla en una consulta que se ejecuta continuamente durante horas (ver abajo).
La tarea en ejecución es postmaster; una vez que todas se eliminan, la CPU se reduce hasta que se reconstruye cada cinco minutos.
SELECT “users”.“id”, ARRAY_AGG(ARRAY [uccm.id, c_msg.id]) AS memberships_with_unread_messages
FROM “users”
INNER JOIN “user_options” ON “user_options”.“user_id” = “users”.“id”
INNER JOIN user_chat_channel_memberships uccm ON uccm.user_id = users.id
INNER JOIN chat_channels cc ON cc.id = uccm.chat_channel_id
INNER JOIN chat_messages c_msg ON c_msg.chat_channel_id = uccm.chat_channel_id
LEFT OUTER JOIN chat_mentions c_mentions ON c_mentions.chat_message_id = c_msg.id
WHERE “user_options”.“chat_enabled” = TRUE
AND “user_options”.“chat_email_frequency” = 1
AND (users.last_seen_at < ‘2023 - 11 - 15 09:54:26.931723’)
AND (c_msg.deleted_at IS NULL AND c_msg.user_id <> users.id)
AND (c_msg.created_at > ‘2023 - 11 - 08 10:09:26.931848’)
AND ((uccm.last_read_message_id IS NULL OR c_msg.id > uccm.last_read_message_id) AND
(uccm.last_unread_mention_when_emailed_id IS NULL OR c_msg.id > uccm.last_unread_mention_when_emailed_id) AND
(uccm.user_id = c_mentions.user_id AND uccm.following IS true AND
cc.chatable_type = ‘Category’
¿Alguien puede ayudar o sugerir una solución?
Más información:
ejecutando 3.2.0.beta4-dev, pero esto ha estado sucediendo durante al menos unos meses
Aquí hay una lista de plugins que tenemos instalados:
Trabajé en otra consulta similar y esa corrección fue local para esa consulta, por lo que probablemente no ayudará aquí. Aún así, vale la pena actualizar a la última versión, puede haber otras optimizaciones.
Tuvimos un cliente que activó las menciones a @all en el chat, con dos canales de 16k usuarios. ¡Eso fue divertido!
Después de 19 menciones a todos, rápidamente lo desactivaron de nuevo. 12 horas después, su (potente) sistema todavía tenía una alta carga de CPU.
El problema se resolvió al eliminar los 320k registros infractores de la tabla de menciones
delete from chat_mentions
where chat_message_id in (
(select chat_message_id
from chat_mentions
group by chat_message_id having count(*) > 100)
);
pero todavía nos preguntábamos por qué esto estaba causando tantos problemas.
Todavía se estaban ejecutando varias instancias de esta consulta.
Como las filas ya no estaban, un explain no arrojó buenos resultados, pero está claro que estaba haciendo un trabajo pesado. Todos los índices están en su lugar.
También hemos visto que los mensajes de chat desaparecen durante unos minutos antes de volver a aparecer.
En general, creo que hay mucho que mejorar en el chat, aunque me gusta totalmente la dirección que está tomando. Mi principal preocupación es cómo un chat puede causar esencialmente una sobrecarga que no se detiene. Desactivamos la capacidad de mencionar y eso tampoco funcionó.
¿Hay alguna forma de evitar que vuelva la consulta que mencioné? @andrei@JammyDodger
Hola @sok777 , gracias por dar seguimiento. Tenemos a varios ingenieros investigando esto y nos pondremos en contacto contigo aquí una vez que tengamos una actualización. ¡Agradecemos tu paciencia mientras tanto!
Tuvimos un mensaje con @all que eliminamos. Sin embargo, esto no ha resuelto el problema. La consulta sigue volviendo cada 5 minutos y está tardando una eternidad, hasta el punto de que hay una cola de muchas otras consultas.
Una vez que deshabilitamos el chat, la carga de la CPU bajó al 15%. Una locura.
La única razón por la que esa consulta puede tardar es por las muchas entradas en la tabla chat_mentions. ¿Has probado la consulta genérica que publiqué? Quizás no sea @all, sino otro grupo grande el que se menciona.
La consulta problemática escanea todas las menciones de chats en los últimos 7 días.
También deberías detener todas las instancias existentes de la consulta.
Sí, los matamos pero siguen volviendo.
Revisamos todas las menciones por encima de 100 y no teníamos ninguna. No estoy seguro de por qué más podría suceder.
Me parece que hay un problema fundamental con la consulta, pero podría estar equivocado.
@sok777 Necesitaré un poco de tu ayuda con esto. Me gustaría ver el plan de consulta que utiliza Postgres en tu sitio. ¿Podrías ejecutar esto en tu base de datos y compartir los resultados:
EXPLAIN VERBOSE SELECT "users"."id", ARRAY_AGG(ARRAY [uccm.id, c_msg.id]) AS memberships_with_unread_messages
FROM "users"
INNER JOIN "user_options" ON "user_options"."user_id" = "users"."id"
INNER JOIN "group_users" ON "group_users"."user_id" = "users"."id"
INNER JOIN "groups" ON "groups"."id" = "group_users"."group_id"
INNER JOIN user_chat_channel_memberships uccm ON uccm.user_id = users.id
INNER JOIN chat_channels cc ON cc.id = uccm.chat_channel_id
INNER JOIN chat_messages c_msg ON c_msg.chat_channel_id = uccm.chat_channel_id
LEFT OUTER JOIN chat_mentions c_mentions ON c_mentions.chat_message_id = c_msg.id
WHERE "user_options"."chat_enabled" = TRUE
AND "user_options"."chat_email_frequency" = 1
AND (users.last_seen_at < '2023-11-27 08:00:00.0000000')
AND (c_msg.deleted_at IS NULL AND c_msg.user_id <> users.id)
AND (c_msg.created_at > '2023-11-20 08:00:00.0000000')
AND ((uccm.last_read_message_id IS NULL OR c_msg.id > uccm.last_read_message_id) AND
(uccm.last_unread_mention_when_emailed_id IS NULL OR c_msg.id > uccm.last_unread_mention_when_emailed_id) AND
(
(uccm.user_id = c_mentions.user_id AND uccm.following IS true AND cc.chatable_type = 'Category') OR
(cc.chatable_type = 'DirectMessage')
)
)
GROUP BY users.id, uccm.user_id
ORDER BY "users"."id" ASC
LIMIT 1000;
