PostAlerter job si blocca/va in OOM ultimamente

Da quando FEATURE: new watched_precedence_over_muted setting (#22252) · discourse/discourse@9cf981f · GitHub (presumibilmente!) abbiamo code Sidekiq che si riempiono/OOM con processi PostAlert bloccati:

Dato che questo commit ha già avuto una regressione simile (FIX: error when CategoryList tried to find relevant topics by lis2 · Pull Request #22339 · discourse/discourse · GitHub) è piuttosto sospetto - proveremo ora a tornare a un commit precedente a quello menzionato e riferiremo i risultati.

2 Mi Piace

Spostandosi verso il basso a 4f7f9ef87cbcd574144f657dd43b7e705d98ff8e ha effettivamente risolto i worker bloccati di PostAlert sidekiq e le preoccupazioni relative all’OOM: i pochi job di PostAlert che vengono accodati ora completano in pochi secondi, non minuti.

2 Mi Piace

Ping @kris.kotlarek

1 Mi Piace

Ho appena visto che FIX: improve performance of post alerter job (#22378) · discourse/discourse@7a204e7 · GitHub è stato inviato - proverò più tardi se questa è una correzione per questo problema.

2 Mi Piace

Sì, si spera che questo risolva il problema. Ho testato questa soluzione su 3 forum e una nuova query è stata sempre molto più veloce e non ha intasato i server.
Grazie per aver segnalato questo problema e fammi sapere se continui a riscontrare problemi.

4 Mi Piace

Purtroppo, anche con queste modifiche, i processi PostAlert richiedono ancora molto più tempo del previsto e bloccano completamente i worker Sidekiq durante l’elaborazione. :frowning:

(abbiamo oltre 10 milioni di righe utente e alcune categorie disattivate per impostazione predefinita, quindi ci sono molti silenziamenti configurati!)

Revertire i tre commit che hanno recentemente toccato questo processo e riavviare il container, nel frattempo, fa sì che i processi vengano completati correttamente.

3 Mi Piace

Grazie, ci darò un’altra occhiata

Ho appena unito un altro tentativo di migliorare le prestazioni di questo job:

L’ho testato su alcune istanze e ha funzionato bene, ma erano più piccole della tua.

Se continua a fallire con questo commit, potresti fornirmi il report EXPLAIN ANALYSE? Script per generarlo:

topic = Topic.last
user_option_sql_fragment =
  if SiteSetting.watched_precedence_over_muted
    <<~SQL
    INTERSECT
    SELECT user_id FROM user_options WHERE user_options.watched_precedence_over_muted IS false
    SQL
  else
    <<~SQL
    EXCEPT
    SELECT user_id FROM user_options WHERE user_options.watched_precedence_over_muted IS true
    SQL
  end
user_ids_sql = <<~SQL
  (
    SELECT user_id FROM category_users WHERE category_id = #{topic.category_id.to_i} AND notification_level = #{CategoryUser.notification_levels[:muted]}
    UNION
    SELECT user_id FROM tag_users tu JOIN topic_tags tt ON tt.tag_id = tu.tag_id AND tt.topic_id = #{topic.id} WHERE tu.notification_level = #{TagUser.notification_levels[:muted]}
    EXCEPT
    SELECT user_id FROM topic_users tus WHERE tus.topic_id = #{topic.id} AND tus.notification_level = #{TopicUser.notification_levels[:watching]}
  )
  #{user_option_sql_fragment}
SQL
sql = User.where!("id IN (#{user_ids_sql})").to_sql

sql_with_index = <<SQL
EXPLAIN ANALYZE #{sql};
SQL
result = ActiveRecord::Base.connection.execute("#{sql_with_index}")
puts sql_with_index
result.each do |r|
  puts r.values
end

Mi aiuterebbe a trovare un indice mancante o a capire quale parte di questa query è così lenta.

3 Mi Piace

Questo cambiamento sembra aver riportato i processi PostAlert alla loro normale durata e non bloccare le istanze Sidekiq. Evvai!

3 Mi Piace

Questo argomento è stato chiuso automaticamente dopo 3 giorni. Non sono più consentite nuove risposte.