- A volte il DB viene bloccato a causa di alcune query e ci è stato detto che dobbiamo ottimizzare PostgreSQL, qualche idea su come raggiungere questo obiettivo?
Nella schermata sottostante sono le nostre risorse DB
- CPU: 4 vcpu
- Memoria: 22 GB
1 Mi Piace
Ciao a tutti, sto lavorando su questo con @Abdelrahman_MoHamed. Recentemente abbiamo migrato un sito con circa 500.000 argomenti e 3,5 milioni di utenti a Discourse. Siamo self-hosted su GCP. Durante questo processo, il nostro partner che ci ha assistito con la migrazione ha menzionato che potrebbe avere senso ottimizzare Postgres per ottenere prestazioni adeguate dal DB. La nostra supposizione era che il DB sarebbe arrivato ottimizzato per Discourse “out of the box” (forse lo è?). Tuttavia, data la loro (la proposta del partner) suggerimento, volevamo approfondire qui.
In breve, questi sono alcuni modi comuni per ottimizzare Postgres per un DB con i numeri qui pubblicati?
Grazie in anticipo per l’aiuto!
1 Mi Piace
Hai prove più dettagliate che il DB sia il fattore limitante, o la causa di questi carichi della CPU? Ad esempio, l’output di ps o top.
Se si tratta del DB, immagino ci sia un modo per chiedergli su quali query sta lavorando.
Tali dettagli potrebbero essere utili.
1 Mi Piace
Grazie @Ed_S, aggiungeremo presto altri dati qui. Per ora stiamo solo monitorando le cose. Apprezzo la risposta.
1 Mi Piace
quella sembra una combinazione strana… 22 GB di memoria ma solo 4 vcpu? Troppa memoria, ma potenzialmente pochi core.
normalmente avresti un server con molti più vcpu per GB
questo perché il web serving è molto parallelo e per ogni unicorn serve solo circa 1 GB.
Ogni Unicorn può girare su un core diverso, credo.
Questo forse è il motivo per cui raggiungi il 100% di utilizzo della CPU così facilmente.
Ti consiglio di considerare di passare a una configurazione 16/16 o anche 8/8 e vedere se le cose migliorano.
È consentito un piccolo passo laterale? Gli unicorni sono simili ai worker di PHP? Alcuni documenti hanno cercato di spiegare che gli unicorni sono in realtà server HTTP con propri worker che consegnano richieste a Ruby, ed è per questo che è totalmente diverso. Ma entrambi gestiscono richieste HTTP consentendo più richieste simultanee e quindi più worker PHP e più unicorni necessitano di più RAM — e per me i due sono praticamente uguali.
Giusto o terribilmente sbagliato? Vorrei capire il principio ora, perché so perché, quando e come regolare i worker PHP, ma gli unicorni sono solo creature mistiche e magiche per me.
sì, penso che sia un paragone giusto
1 Mi Piace
Correlato: Come può un amministratore scoprire se ha troppo pochi o troppi unicorni per il proprio traffico web?
Correlato: Come può un amministratore scoprire se ha molta più RAM di quella di cui ha bisogno?
La mia comprensione è che il numero di unicorni sia generalmente scalato in base al numero di CPU, ma non è necessario che sia così, se, ad esempio, la configurazione dell’host è cambiata dalla configurazione iniziale.
La quantità di RAM dovrebbe scalare in base a quanto è necessaria. Non so se un enorme import di molti post e utenti significhi necessariamente più RAM necessaria - la domanda sarebbe, quanta parte del database viene acceduta per servire ogni richiesta web, o ogni attività regolare?
Per me, un’esplosione di 10 minuti di utilizzo massimo della CPU, su uno sfondo di utilizzo molto basso, non indicherebbe un problema. (Sarebbe un problema se significasse che un forum molto trafficato e critico in termini di tempo, come ad esempio un forum sportivo/di scommesse, avesse dei ritardi nel servire le pagine nei momenti di massimo interesse. Ma il mio forum non è critico in termini di tempo o prestazioni.)
Non so come si potrebbe tabulare l’intervallo dei tempi di risposta recenti, ma questo potrebbe essere un buon dato da esaminare. Sia dal lato del web-serving che dal lato del database.
1 Mi Piace