Esistono delle guide (o argomenti qui sul forum) che offrono consigli per ottimizzare le prestazioni di un server che ospita siti Discourse?
Ho eseguito ./Discourse-set, che ha impostato un quarto della RAM (a 4096 MB) e aggiunto 8 worker di Unicorn. Tuttavia, c’è qualcos’altro che possiamo fare o che possiamo modificare?
Il server dispone di 64 GB di RAM ECC e due SSD da 512 GB NVMe (in un array RAID). Guardando l’output di top, vengono utilizzati solo circa 5 GB di memoria, con 57392484 avail Mem. Il server esegue anche altri siti non Docker, ma non consumano molte risorse e MySQL è già ottimizzato per un database di grandi dimensioni da 2 GB. I valori di carico medio sono generalmente inferiori a 1,0 (solitamente intorno a 0,50 fino a 1,0, con occasionali superamenti). Non sono stati segnalati problemi, ma spero di sfruttare al meglio le risorse del server.
Mi chiedo se iniziare raddoppiando db_shared_buffers… e cosa dire di #db_work_mem: "40MB", che al momento è commentato.
Tutte le informazioni e i consigli sono apprezzati
Ci sono stati (o ci sono) alcuni argomenti sulla messa a punto. La maggior parte di quelli di successo, credo (eccetto questo), fornisce dettagli precisi sulle risorse disponibili, db_shared_buffers e altre impostazioni, e quali siano i problemi, magari con l’output di htop o altri strumenti. Quanto è grande il tuo database? Che problema stai riscontrando? (Potresti voler iniziare un nuovo argomento)
Grazie! Finora nessun problema. Ho solo notato un elevato utilizzo della memoria, ma non è un forum affollato. Sono solo abituato a pensare in modo proattivo e a controllare quali risorse venivano utilizzate di più. Questo è solo su un VPS da 3 GB con 6 core a 3,5 GHz. Non è lento, anzi è molto veloce, ma vedo che l’utilizzo della memoria potrebbe diventare un problema futuro e sono curioso di sapere cosa posso ottimizzare.
Farò qualche altra lettura sulle applicazioni Ruby on Rails in generale e sull’ottimizzazione. Grazie ancora.
A seconda di quale misura di “utilizzo” intendi, potrebbe essere normale. Ma con 3 GB, probabilmente non c’è molto da ottimizzare, poiché se eseguissi ./discourse-setup le sue stime sono probabilmente sufficienti.
free -h
total used free shared buff/cache available
Mem: 2.9Gi 1.8Gi 167Mi 100Mi 1.0Gi 895Mi
Swap: 1.0Gi 587Mi 436Mi
Disponibile è di circa 900M. Non è ancora un problema. Ma un problema non mi ha portato qui. Vorrei sapere cosa fare se/quando la memoria disponibile diventerà un problema in futuro. Oltre ad aggiungere più memoria, ovviamente.
A questo livello, l’unica cosa da fare sarà aggiungere più RAM. Se hai 8 o 16 GB, ci sono alcune cose da fare. Al massimo, potresti voler aggiungere un altro GB di swap, ma probabilmente andrà bene.
Se avessi eseguito ./discourse-setup, avrebbe creato un file di swap da 2 GB. Potresti riscontrare problemi quando esegui una ricostruzione.
Ok, sono riuscito quasi a raddoppiare la memoria disponibile modificando l’impostazione predefinita dell’installazione da: UNICORN_WORKERS: 8
a UNICORN_WORKERS: 4
Poi: sudo ./launcher rebuild app
Ora sto configurando il monitoraggio di PostgreSQL e vedrò cosa succede lì.
C’è sempre un momento in cui una risorsa diventa un collo di bottiglia. Ma il tuo server attualmente mi sembra pesantemente sovradimensionato.
Utilizzerai più memoria quando avrai più processi Unicorn.
Avrai bisogno di più processi Unicorn quando avrai più traffico sul tuo sito.
Vedo tutti i processi Unicorn che utilizzano lo 0,0% di CPU e solo worker[0] sembra fare qualcosa.
Hai ridotto la memoria eseguendo meno Unicorn. Va bene, perché tanto non sembravi usarli. Ma la memoria disponibile è in realtà una cosa negativa. Stai ottimizzando per la variabile sbagliata.
La memoria inutilizzata non ti serve a nulla. Significa che stai pagando per qualcosa che comunque non stai utilizzando. Se hai sempre 2 GB disponibili*, potresti ridurre le dimensioni del tuo server e risparmiare qualche soldo.
*) La ricostruzione di Discourse consumerà più memoria, quindi devi verificare quanta memoria è disponibile durante la ricostruzione. In pratica, non scendere sotto i 2 GB totali e/o assicurati di avere abbastanza swap, come ha già detto Pfaffman.
Non è corretto. La memoria “libera” che non fa nulla è negativa. Ma la memoria “disponibile” è memoria utilizzata dal sistema che può essere facilmente liberata ed è una cosa positiva.
O ufficialmente:
Memoria disponibile: Stima di quanta memoria è disponibile per l’avvio di nuove applicazioni, senza swapping.
Fonte: man free
Come da screenshot qui sotto, la memoria libera è quasi invariata. Quindi quasi tutta la memoria del sistema è in uso. Tuttavia, il sistema effettuerà meno swapping ora perché c’è più memoria disponibile che può essere liberata quando necessario.
Suppongo che un male qui significhi che costa, ma non dà nulla. Questo è un modo di pensare abbastanza comune, perché quando si hanno bisogno di più risorse, queste saranno anche più costose — e la RAM è una parte costosa in quell’equazione.
E se non hai troppi soldi da buttare via, è semplicemente stupido pagare troppo (espressione pubblicitaria finlandese, nessuna offesa )
Sì, esattamente, per quanto riguarda la memoria libera. Tuttavia, “la memoria disponibile è in realtà una cosa negativa”… è proprio quello a cui mi riferivo.
)