Questa è una buona specifica! Devi avere un sito particolarmente trafficato?
Sei sicuro che non ci sia stato alcun ribake?
Quante immagini vengono pubblicate al minuto?
La preparazione delle miniature è in gran parte codice di base e richiede un’ulteriore elaborazione obbligatoria delle immagini.
Questo sarebbe il caso per qualsiasi plugin o componente del tema di questa natura.
Abbiamo disattivato il plugin per circa 24 ore, quindi lo abbiamo riattivato per 24 ore.
Di seguito incollo le note del nostro altro amministratore.
Il plugin sta causando un rallentamento nell’esecuzione dei processi pianificati.
Più processi ci sono in coda, più la CPU fatica a tenere il passo.
Quindi, ciò che accade è che il server vede molto traffico, ma le cose sembrano normali per un po’ finché i processi non iniziano ad accumularsi.
Alla fine, la CPU fatica a tenere il passo e l’utilizzo aumenta e diminuisce man mano che completa i processi arretrati.
Ecco perché in precedenza abbiamo visto oltre 3000 processi in arretrato.
In circostanze normali, non ci sono mai più di 5 processi. ma quasi sempre ce ne sono 0 perché nessun processo dovrebbe essere in arretrato, dovrebbero essere elaborati immediatamente.
L’immagine allegata mostra i processi correnti che si stanno accumulando. Al momento si aggira intorno ai 30-35 processi in arretrato.
Tutti i processi sono nuovi dall’ultimo post nel sidecar.
Non riesco ancora a capire perché, ma questo accade solo quando il plugin è attivo.
Ultima ora delle risorse sulla CPU
ultime 24 ore, indicando approssimativamente dove il plugin è stato abilitato (Vedi l’andamento verso l’alto dopo il picco)
Sembra che il pattern sia più lungo di 24 ore per essere notato, ma il plugin causa un utilizzo generale delle risorse nell’80-90+% per la maggior parte del tempo.
Una volta che lo disattiveremo, noteremo che nelle successive 24 ore il server avrà una media del 60-75% e i processi non si accumuleranno.
Inoltre, quando lo vorremo, ho modificato app.yml per avere 16 worker unicorn. quando vorremo ricostruire, penso che dovremmo disabilitare il plugin e avere 16 worker unicorn. Osserveremo le prestazioni del server durante quel periodo e adegueremo il valore dei worker a ciò che riteniamo sia meglio.
Negli ultimi 7 giorni
rosso = abilitato
blu = disabilitato
Dopo aver riattivato il plugin, la CPU sta aumentando. Sono meno sicuro che i conteggi dei processi siano un problema importante. Ho notato che i conteggi dei processi aumentano con più worker unicorn. Penso che il numero non sia correlato.
Vedo ancora il problema del plugin che trattiene risorse.
Non sono ancora sicuro al 100%, ma sono molto fiducioso che il plugin sia un problema.
plugin + 16 worker: blocca il server
16 worker senza plugin - funziona bene
plugin + 8 worker - lento ma funziona
grafico dopo aver disattivato il plugin
Ciao,
Sono l’altro amministratore che ha preso appunti.
Non vedo più i processi come parte del problema.
Purtroppo non conosco molto bene il funzionamento interno di Discourse per sapere quale potrebbe essere la causa. So solo quello che vedo attualmente.
Si può riassumere dicendo che il sito è generalmente lento quando è abilitato con 8 worker e va quasi giù con 16 worker.
Con il plugin disattivato, il sito funziona perfettamente e con abbastanza worker è molto veloce.
Questo mi porta a credere che ci sia qualcosa nel plugin che rallenta il sito, sia per le risorse o per qualcosa che viene bloccato in operazioni di I/O o asincrone, forse.
Per favore, controlla la tua coda sidekiq. Vedi molti processi in coda e quali sono i nomi dei processi?
Sono sicuro che si tratta solo di un arretrato di produzione di miniature che si risolverà una volta che tutte le immagini saranno state elaborate.
Questo è un processo principale.
Puoi rimuovere in sicurezza il plugin sidecar se non hai bisogno delle sue funzionalità aggiuntive e utilizzare solo il Theme Component.
Puoi confermare che il problema persiste con il Theme Component attivo ma non con il plugin sidecar?
Se non hai mai avuto installato il plugin sidecar, il problema deve essere nel core.
Se hai bisogno di aiuto con la tua analisi, puoi assumere Pavilion.
Accolgo con favore segnalazioni indipendenti di questo problema.
Solo per confermare: un aumento dei processi di ridimensionamento delle immagini ad alto utilizzo di CPU è previsto quando si abilita qualsiasi componente tematico di anteprima dell’elenco degli argomenti 
. Core genera le anteprime “su richiesta” per il primo utente che visualizza un dato argomento in un elenco di argomenti.
Come menzionato da @merefield, dovrebbe stabilizzarsi una volta che tutte le anteprime sono state generate per gli argomenti elencati di frequente.
Aumentare il numero di worker probabilmente non è una buona idea: cercare di fare più lavoro in parallelo su una macchina con limitazioni di CPU peggiorerà i sintomi. È meglio mantenere i numeri dei worker normali in modo che i processi possano mettersi in coda ed essere elaborati senza sovraccaricare la macchina.
Nell’interfaccia utente di Sidekiq, probabilmente vorrai guardare le schede “Busy” (Occupati) e “Queued” (In coda). I processi “Scheduled” (Pianificati) sono quelli programmati per un orario specifico nel futuro, quindi è molto improbabile che causino problemi di prestazioni.
Sembra fantastico in anteprima, ma nella realtà è completamente diverso. Cosa sto sbagliando?
Molti temi di “conversione totale” non sono supportati. Sospetto che FKB Pro abbia le proprie sovrascritture che si scontrano con questo componente. Temo di non poter supportare questo scenario.
Questo componente del tema è pensato per essere utilizzato come blocco di costruzione all’interno di un tema che non cerca di coprire tutte le basi.
Se desideri una barra laterale destra con anteprime dell’elenco degli argomenti, prova Right Side Blocks in combinazione.
C’è un piccolo problema di CSS/spaziatura tra l’intestazione dell’argomento e l’icona del link in primo piano.
Aggiunta una funzionalità sperimentale:
Ora funziona abbastanza bene, ancora dietro un’impostazione:
Questo è reattivo alla larghezza, quindi appare in modalità Tiles (masonry) solo quando l’area dell’elenco è abbastanza ampia.
Demo qui: https://www.starzen.space/
NB L’imbottitura in eccesso in basso a destra è un problema noto e necessario a causa del renderer masonry che per motivi di prestazioni (è veloce!) renderizza le cose alla riga della griglia più vicina. Una volta (!) che implementeranno il masonry nativo in CSS grid, lo rifattorizzerò per renderlo più gradevole.
NB#2 Lo screenshot contiene anche alcuni controlli dal componente tema Discourse Bars (la barra laterale è nascosta). Topic List Previews funziona molto bene con Discourse Bars.
Un’immagine per YouTube appare nella home page.
Potrebbe essere anche per Twitter?
Non è in alcun modo limitato a YouTube.
Espone qualunque sia la miniatura. Se l’incorporamento di Twitter crea una miniatura, allora sì.
Potresti dirmi quali impostazioni dovrei scegliere per renderlo come in questa immagine?
Lo voglio nella forma di un elenco di miniature come in questa immagine.
immagine allineata a sinistra
Rimuovi le route da questa impostazione:
Altrimenti verranno visualizzate come “Tiles”. Se desideri zero route in formato “Tiles”, rimuovi tutte queste righe, ma potresti voler considerare le Tiles su dispositivi mobili (nel qual caso mantieni quelle con *-mobile).
Va benissimo ora, grazie 
C’è un’impostazione nel plugin sidecar associato (elencato nell’OP):
Ma senza il plugin potresti voler provare le impostazioni native:
Non guardo questa cosa da un po’! 
Sto giocando con le impostazioni che hai menzionato, ma non funziona.
È interessante notare che ci sono troppi pochi riassunti su un argomento e troppi sull’altro.
Il carattere deve essere entro un certo limite di caratteri.
Installa il plugin sidecar, usa quell’impostazione.
Suppongo che tu debba eseguire un nuovo rebake del post per rifare il riepilogo dell’argomento.
