{“content”:“Sto cercando una guida esperta per ottimizzare una configurazione multisito di Discourse. Ho una singola VM web e una VM di database separata su un importante provider cloud. Sebbene entrambe le macchine abbiano specifiche decenti, sto scoprendo che il mio sistema viene sopraffatto da un gran numero di processi in background, il che sembra mettere sotto stress il database.\n\nLa mia attuale configurazione app.yml è:\n\n* UNICORN_WORKERS: 4\n* UNICORN_SIDEKIQS: 4\n* DISCOURSE_SIDEKIQ_WORKERS: 10\n* DISCOURSE_DB_POOL: 8\n\nSulla base delle mie osservazioni, il collo di bottiglia non è il raggiungimento di un limite di connessione rigido, ma piuttosto l’enorme volume di lavori che competono contemporaneamente per le risorse del database. Le code in Sidekiq sono costantemente in coda, il che rende il sito lento, anche per le attività amministrative di base.\n\nSto cercando un approccio generico per ottimizzare il sistema per stabilità e prestazioni. In particolare, vorrei capire le migliori pratiche per:\n\n* Concorrenza Sidekiq: Come dovrebbero essere dimensionati DISCOURSE_SIDEKIQ_WORKERS in un ambiente multisito per gestire un elevato volume di lavori senza mettere sotto stress il database?\n* Separazione delle code: È consigliabile eseguire processi Sidekiq separati per gestire diverse code (ad esempio, priorità critica vs. bassa)? Ciò garantirebbe che i lavori pesanti non blocchino quelli più urgenti.\n\nNon sto cercando una soluzione che richieda una modifica architettonica importante o il passaggio a un diverso web server in questo momento, poiché voglio mantenere il processo il più semplice e a basso rischio possibile. Spero di ricevere consigli su un percorso sicuro ed efficace.\n\nGrazie!”,“target_locale”:“it”}
Discourse dovrebbe essere in grado di adattarsi automaticamente in base alle risorse del tuo sistema. Tieni presente che è sicuro rieseguire lo script ./discourse-setup se hai recentemente aumentato le risorse del tuo sistema. Lo script può adattarsi alle risorse aumentate e regolare il tuo .yml di conseguenza.
Sembra che tu ne abbia bisogno di meno?
Sono abbastanza sicuro che sappia già dare priorità ai lavori ad alta priorità.
@itsbhanusharma @pfaffman Grazie per il vostro aiuto e il vostro contributo! Apprezzo entrambi per aver dedicato del tempo a condividere la vostra esperienza.
Se il database è il collo di bottiglia, hai considerato di passare a un tipo di istanza più grande per il tuo database cloud?
Questo argomento è stato chiuso automaticamente 30 giorni dopo l’ultima risposta. Non sono più consentite nuove risposte.