Low Hit Postgres Cache Ratio - dimensione dei dati o qualcos'altro?

Question

Ho appena aggiornato il mio database Heroku postgres dal piano di Kappa (800 MB di RAM, postgres 9.1) al piano Ronin (1.7 GB di RAM, postgres 9.2), ma le prestazioni si sono ridotte.

Seguendo la guida here, ho controllato e il tasso di hit della cache è persino inferiore a quello con il nostro database Kappa (ora ~ 57%, precedentemente ~ 69%). La nostra progettazione di app dovrebbe essere decentemente accettabile, poiché abbiamo visto un tasso di hit della cache di circa il 99% prima.

La raccomandazione è che il set di dati dovrebbe essere in grado di adattarsi alla memoria, il che non dovrebbe essere un problema ora - la nostra dimensione dei dati è di 1,27 GB (almeno la maggior parte dovrebbe adattarsi).

La frequenza di risposta della cache bassa a causa della dimensione dei dati o c'è qualcos'altro che posso esaminare? O è semplicemente un caso di cache del database non completamente riscaldata? (sono passati quasi 2 giorni)

Answer 1

Se si dispone di molta memoria e non si esegue molto altro sul db, una cosa che potrebbe cambiare è shared_buffers. Quello che fanno i buffer condivisi è che memorizzano nella cache i dati usati di frequente in modo da massimizzarli quando non tutto il database si adatta alla memoria.

Sfortunatamente questa cache non funziona bene come la cache del SO. Se i dati saranno facilmente adattarsi in memoria, assicurarsi che effective_cache_size è abbastanza alta, e quindi provare riducendoshared_buffers

Si noti che questa non è una bacchetta magica. La dimensione appropriata di shared_buffers dipende da quanti dati hai, da quanto spazio occupa, dai tuoi tipi di query, da quanta memoria sta andando verso cose come ordinamenti e simili. Ci si può aspettare di giocare di tanto in tanto per trovare il punto debole per la configurazione e il database corrente.