Ah, capisco, questo avrà difficoltà con quella query. Dopo aver aggiornato all’ultima versione, potresti estrarre la query dal mini_profiler ed eseguire un explain analyze su di essa, condividendo poi il risultato con noi?
Su Meta (RDS db.r6g.large 30GB) appare così:
Proverò a eseguire di nuovo explain analyze, ma non siamo riusciti a completare con successo quella query.
Aggiornamento: questo commit non ha apportato alcuna modifica. Il database continua a lavorare costantemente oltre il 95% dopo l’aggiornamento, uccidendo tutte le vecchie query in esecuzione. Con la beta4, per questo forum, il carico era stabile tra il 20-30%. Abbiamo già eseguito un auto-vacuum e una reindicizzazione dello schema.
Come possiamo disabilitare questa funzionalità? Non sembra corretto dover passare a un’istanza di database più grande per risolvere il problema; sembra esserci qualcosa di sbagliato nel modo in cui viene calcolata questa query, dato che funzionava perfettamente prima di questo aggiornamento.
La query è riuscita a completarsi dopo circa 21 minuti
Da notare inoltre che siamo su PG 10.17, poiché sembra che i nostri output differiscano notevolmente.
Abbiamo applicato una patch temporanea al problema reindirizzando tutte le rotte */private-messages-all/* verso */private-messages/*. Il risultato è che “tutte le caselle di posta” mostra lo stesso contenuto di “Personale”, ma almeno non dobbiamo più gestire un utilizzo della CPU al 100% in modo costante.
Codice della patch:
# name: discourse-private-messages-perf-hotfix
# version: 0.0.1
# authors:
# Prepend to override existing routes
Discourse::Application.routes.prepend do
scope path: nil, constraints: { format: /(json|html|\*\/\*)/ } do
scope "/topics", username: RouteFormat.username do
# Reroute all */private-messages-all/* routes to go to */private-messages/* instead (personal messages)
# Former is expensive, latter is cheap, potentially saves significant database CPU usage
get "private-messages-all/:username" => "list#private_messages", as: "topics_private_messages_override", defaults: { format: :json }
get "private-messages-all-sent/:username" => "list#private_messages_sent", as: "topics_private_messages_sent_override", defaults: { format: :json }
get "private-messages-all-new/:username" => "list#private_messages_new", as: "topics_private_messages_new_override", defaults: { format: :json }
get "private-messages-all-unread/:username" => "list#private_messages_unread", as: "topics_private_messages_unread_override", defaults: { format: :json }
get "private-messages-all-archive/:username" => "list#private_messages_archive", as: "topics_private_messages_archive_override", defaults: { format: :json }
end
end
end
Utilizzo della CPU del database del nostro forum dopo aver distribuito la patch sopra:
@tgxworld Dovresti dare un’altra occhiata a ciò che fanno le rotte */private-messages-all/*: è chiaro che c’è qualcosa che non va nell’implementazione, non è abbastanza efficiente per database di forum di grandi dimensioni. O l’implementazione non utilizza l’indice di database corretto o la generazione delle query produce query estremamente costose (in particolare su PSQL 10, non sono sicuro per le versioni 12/13).
L’attuale implementazione ha di fatto reso il nostro forum inutilizzabile, aumentando l’utilizzo della CPU da circa il 15% a un costante 100% e causando prestazioni lente in tutte le altre funzionalità del forum. Non vedo alcun motivo per cui le query per le caselle di posta personali/gruppo richiedano <50ms mentre quelle per “tutte le caselle di posta” impieghino oltre 20 minuti per completarsi.
Puoi utilizzare il dump di analisi pubblicato da @forkythetoy poco sopra per vedere l’esecuzione di oltre 20 minuti precedente.
@Falco Ho appena notato che hai unito la nostra discussione qui, ma sembra che si tratti in realtà di un endpoint diverso. Questo rapporto di bug riguarda l’endpoint private-message-topic-tracking-state, mentre stiamo parlando di */private-messages-all/*. Questo potrebbe essere all’origine di alcuni malintesi qui, mi scuso per questo. (Inizialmente ho collegato a questo, il che potrebbe aver avviato la confusione)
L’endpoint private-message-topic-tracking-state è veloce sul nostro forum, quindi non si tratta di questo per noi.
Per noi, questa query impiega circa 200-300 ms di tempo di database. Un po’ più del previsto, ma comunque entro i limiti normali, sì.
Tuttavia, stiamo utilizzando Postgres 13.
@Hooksmith Ho una correzione in lavorazione
@Hooksmith @forkythetoy Sarete in grado di aggiornare a PG 13? Questa è la versione minima richiesta da Discourse al momento. Inoltre, mi è più difficile confrontare i piani di esecuzione delle query quando queste non vengono eseguite con la stessa versione di PG.
Ho dovuto annullare questa modifica perché le prestazioni della nuova query differiscono troppo tra gli utenti.
@blattersturm Stai ancora riscontrando che le prestazioni del tracciamento dello stato dell’argomento sono lente?
Non sono sicuro, non ho fatto un aggiornamento da alcuni giorni. Ci sono commit da integrare per vedere se ci sono stati miglioramenti?
No, non è cambiato nulla, ma se puoi fornirmi un EXPLAIN ANALYZE della query, mi sarebbe molto utile.
Tieni presente che abbiamo temporaneamente ripristinato le caselle di posta generali a causa di problemi di prestazioni.
Questo argomento è stato automaticamente chiuso dopo 14 giorni. Non sono più consentite nuove risposte.
