Het optimaliseren van een grote Discourse Multisite: Database en Sidekiq knelpunten

Installatie Hosting
1

Ik zoek deskundige begeleiding bij het optimaliseren van een Discourse multisite-installatie. Ik heb één web VM en een aparte database VM bij een grote cloudprovider. Hoewel beide machines redelijke specificaties hebben, merk ik dat mijn systeem wordt overweldigd door een groot aantal achtergrondtaken, wat de database lijkt te belasten.

Mijn huidige app.yml-configuratie is:

  • UNICORN_WORKERS: 4
  • UNICORN_SIDEKIQS: 4
  • DISCOURSE_SIDEKIQ_WORKERS: 10
  • DISCOURSE_DB_POOL: 8

Op basis van mijn waarnemingen is de knelpunt niet het bereiken van een harde verbindingslimiet, maar eerder het grote aantal taken dat tegelijkertijd om databasebronnen concurreert. De wachtrijen in Sidekiq lopen constant vol, waardoor de site traag aanvoelt, zelfs voor basale administratieve taken.

Ik zoek een algemene aanpak om het systeem af te stemmen op stabiliteit en prestaties. Specifiek wil ik de best practices begrijpen voor:

  • Sidekiq Concurrency: Hoe moeten DISCOURSE_SIDEKIQ_WORKERS worden geschaald in een multisite-omgeving om een hoog taakvolume te verwerken zonder de database te belasten?
  • Scheiding van Wachtrijen: Wordt het aanbevolen om aparte Sidekiq-processen te draaien om verschillende wachtrijen te verwerken (bijv. critical vs. low prioriteit)? Dit zou ervoor zorgen dat zware taken geen dringendere taken blokkeren.

Ik zoek geen oplossing die een grote architecturale verandering vereist of een overstap naar een andere webserver op dit moment, omdat ik het proces zo eenvoudig en risicoarm mogelijk wil houden. Ik hoop advies te krijgen over een veilige en effectieve weg vooruit.

Bedankt!

3 likes
2

Discourse zou automatisch moeten kunnen aanpassen op basis van uw systeembronnen. Houd er rekening mee dat het veilig is om het script ./discourse-setup opnieuw uit te voeren als u onlangs uw systeembronnen heeft verhoogd. Het script kan zich aanpassen aan de verhoogde bronnen en uw .yml dienovereenkomstig aanpassen.

2 likes
3

Sounds like you need fewer?

I’m pretty sure that it already knows to prioritize the high priority jobs.

2 likes
4

@itsbhanusharma @pfaffman Bedankt voor jullie hulp en input hierover! Ik waardeer het dat jullie beiden de tijd hebben genomen om jullie expertise te delen.

4 likes
5

If the database is the bottleneck, have you considered moving to larger instance type for your cloud database?

1 like
6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.