Ciao, come ho menzionato nei post precedenti, sto facendo delle prove della mia migrazione da Drupal a Discourse per avere tutte le soluzioni pronte prima di disattivare il vecchio sito per migrare i dati di produzione con i suoi circa 2 milioni di post. Quello che ho imparato è che su un VPS abbastanza veloce con 3 core vCPU, il processo di importazione richiede un’eternità, circa 48 ore. E poi probabilmente dovrò fare ulteriore pulizia con attività rake e/o rails c, e per qualsiasi cosa che richieda un rake posts:rebake ci vorranno altre 20 ore circa.
Non capisco veramente i fondamenti della toolchain Ruby. Ma se aggiungo più core CPU al lavoro, ridurrà significativamente il tempo necessario per completare uno qualsiasi di questi processi? Ad esempio, un comando bundle o un comando rake sarà in grado di dividere il suo lavoro tra le CPU disponibili, o i core aggiuntivi sono principalmente utili per eseguire processi concorrenti multipli quando più utenti accedono al sito web?
Sono fuori tema, ma quando stavo lavorando alla migrazione di un forum con lo stesso numero di post, ho modificato lo script di importazione per importare solo 1/100 o 1/1000 argomenti e post.
È un modo più veloce per vedere se la tua importazione è affidabile e se sono necessarie modifiche o debug.
@Canapin In realtà ti ringrazio molto per averlo menzionato, mi piacerebbe davvero sapere come hai fatto. Ho desiderato fare la stessa cosa, ma ho scartato l’idea perché ho presunto che avrei incontrato incongruenze nel database con un’importazione parziale. Quindi ho finito per creare un forum di test Drupal scheletrico su cui testare. Ma preferirei testare una copia del DB di produzione.
Sono principalmente preoccupato per la migrazione finale definitiva della produzione; dovrò mettere offline il vecchio forum o almeno renderlo di sola lettura, e sembra che ci vorranno almeno 48 ore di inattività nel migliore dei casi, a meno che non si raddoppino i core della CPU per dimezzare il tempo?
I processi che richiedono molto tempo per il ripristino sono effettivamente multi-thread. Un’avvertenza è che 2x le CPU quasi mai equivalgono a 2x le prestazioni.
Un altro punto è che di solito i processi per rake posts:rebake e il grosso del lavoro del forum stesso per recuperare e ottimizzare il contenuto possono avvenire con il forum attivo. Ciò potrebbe ridurre il tempo necessario per avere il forum spento o in sola lettura e offrire un’esperienza in qualche modo degradata.
La mia raccomandazione sarebbe: prima, testa. Esegui la migrazione, vedi quanto tempo ci vuole e come appare il forum senza tutti i rebake attivi. Se è abbastanza buono, pianifica la migrazione per finire intorno all’orario di minor traffico del tuo forum, in questo modo guadagni circa 4-10 ore di migrazione senza che molte persone si lamentino.
Purtroppo non l’ho scritto e ho dimenticato… Ma se conosci la programmazione non dovrebbe essere molto difficile.
Potrei aver modificato i valori di BATCH_SIZE e offset tra le altre cose per alterare il ciclo e farlo saltare batch di post o qualcosa del genere…
Non posso riprovare ora perché non ho più forum da importare, ma farò un breve tutorial la prossima volta perché penso che sia piuttosto utile.
Sì, le CPU contano, quindi prendi un VPS più grande ed esegui più istanze di sidekiq per il rebaking e l’elaborazione delle immagini, andrà più veloce
Quando il tuo import è completamente completato, è sempre una buona idea eseguire un backup/ripristino, ti darà prestazioni migliori del database.
Queste due cose insieme: prendi un grande VPS per l’importazione e quando hai finito spostalo su un VPS di produzione più piccolo (usando backup e ripristino).
In generale, un’importazione non richiederà il rebaking dei post in seguito.
Grazie mille Richard per la risposta. Quindi quale/i di questi?
UNICORN_WORKERS
UNICORN_SIDEKIQS
DISCOURSE_SIDEKIQ_WORKERS
Interessante, non avevo mai visto questa raccomandazione prima. Riduce la frammentazione o qualcosa del genere?
Sì, inizialmente stavo per provare a correggere alcuni problemi di [QUOTE] e la conversione da Textile a Markdown con regexp_replace() nella console Postgres e poi rebakare tutti i post, perché i comandi rake posts:remap erano semplicemente troppo lenti. Ma poi ho scoperto che il flavor di regexp che Postgres usa non è compatibile con PCRE, e ci sono troppe anomalie inaspettate per potersi fidare. Quindi proverò a far passare i post attraverso Pandoc durante il processo di importazione, il che dovrebbe permettermi di mettere online il sito importato in uno stato presentabile e poi correggere cose più piccole come le parole chiave delle emoji con rake posts:remap.
Penso che sia stato Sam o Jeff a darmi questo consiglio molti anni fa. Non riesco più a trovarlo. Forse dovremmo verificare se è ancora una buona idea e/o vale la pena fare lo sforzo
Per caso qualcuno potrebbe condividere con me alcuni suggerimenti sul modo più veloce per rieseguire uno script di importazione e farlo reimportare i dati? Sto cercando di modificare alcune sostituzioni di testo nello script di importazione e, quando non ci riesco, devo eliminare il database di Discourse e rieseguire ./launcher rebuild import, il che richiede parecchio tempo. Vorrei apportare modifiche al mio script di importazione e farlo ripartire dall’inizio (sto usando un piccolo database mockup scheletrico del mio sito in questo momento, quindi è molto veloce eseguire l’importatore).
Hmmm. Sto testando un’altra importazione dei dati del mio forum di produzione, questa volta su un VPS abbastanza potente con 8 core virtuali e 16 GB di RAM. Ho impostato: UNICORN_SIDEKIQS=4 DISCOURSE_SIDEKIQ_WORKERS=20 UNICORN_WORKERS=16
Con queste impostazioni non sembra sfruttare tutti i core durante la fase di import_topics:
Anche se è interessante che il grafico della CPU fosse bloccato a oltre il 600% (quindi ~6 core su 8 utilizzati al 100%) durante la fase di user_import.
Ho anche notato questa variabile d’ambiente: RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 sarebbe troppo piccola?
Penso che durante lo stato di creazione dell’utente ci siano più azioni gestite in modo asincrono da Sidekiq.
Gran parte dell’importazione, sfortunatamente, non beneficerà della parallelizzazione; dovresti ottimizzare per la velocità della CPU single-core.
Teoricamente, potresti eseguire diversi blocchi dell’importazione degli argomenti in parallelo, ma ciò richiederebbe una notevole refactorizzazione dell’importatore e la garanzia che tutto venga elaborato in ordine. Non vale la pena per un’attività una tantum con poche iterazioni.
Ho seguito una combinazione di queste due guide [1][2] per l’importazione con accesso a un altro container Docker che esegue una copia del database del forum di origine in MySQL. Ma mi sono reso conto che invece di creare un container import separato, posso semplicemente utilizzare un singolo container app e aggiungere il mysql-dep.tempate ad esso:
Questo mi permette di avere un’istanza Discourse funzionante mentre lo script di importazione è in esecuzione. Ci sono svantaggi nell’aprire il forum al pubblico non appena tutti gli utenti e le categorie sono stati importati, e semplicemente informare gli utenti con un banner che ci vorranno alcuni giorni prima che sia completamente popolato? Sto pensando che almeno potrei aprirlo dopo che tutti gli argomenti e i post sono stati importati, ma prima che vengano importati i messaggi privati, poiché solo l’importazione dei messaggi privati richiederà circa 24 ore.
