PostgreSQL massimizza le prestazioni SSD


19

Avrò un enorme database PostgreSQL 9.3 con molte tabelle con oltre 100 milioni di voci per tabella. Questo database sarà fondamentalmente di sola lettura (una volta riempito tutte le tabelle necessarie e creato gli indici non più operazioni di scrittura sul DB) e l'accesso per singolo utente (eseguo e eseguo il benchmark di più query da localhost), poiché verrà utilizzato il DB solo a scopo di ricerca. Le query utilizzeranno sempre JOIN su campi DB interi.

Probabilmente comprerò un SSD (256-512 GB) per questo scopo. Non ho mai usato un SSD per un DB prima, quindi c'è qualcosa di cui dovrei avere paura? Posso mettere l'intero DB sull'unità SSD o solo sugli indici? Sono necessari consigli / tutorial specifici per la messa a punto di PostgreSQL per gli SSD? Nota che ho una buona workstation con un i7 e 32Gb di RAM, quindi forse puoi offrire qualche consiglio anche lì.

Risposte:


16

quindi c'è qualcosa di cui dovrei avere paura?

Non avere backup. Come qualsiasi dispositivo di archiviazione, può morire. Mantieni backup.

Se il caricamento dei dati richiederà secoli, eseguirò il backup del db di sola lettura una volta eseguito il caricamento dei dati, interrompendolo e copiandolo. In questo modo se qualcosa andasse storto sarebbe più facile ricrearlo in seguito.

Posso mettere l'intero DB sull'unità SSD o solo sugli indici?

Se si adatta, conservare l'intero DB.

In caso contrario, inserire un tablespace sull'unità SSD e utilizzarlo per archiviare gli indici e il numero di tabelle fortemente interrogate che si adatteranno.

Sono necessari consigli / tutorial specifici per la messa a punto di PostgreSQL per gli SSD?

La maggior parte dei vantaggi degli SSD riguarda i carichi di scrittura OLTP. Il vantaggio principale per i carichi di sola lettura è la ricerca rapida, e lo ha fatto Slardiere.

Potresti voler impostare effective_io_concurrency = 5o qualcosa per riflettere il fatto che gli SSD possono fare letture casuali veloci e fortemente pipeline ... ma influisce solo sulle scansioni dell'indice bitmap e in pratica lo random_page_costincorpora già.

Per un carico di sola lettura non fa molta differenza.

Per il caricamento iniziale dei dati, vedere:

Nota che ho una buona workstation con un i7 e 32Gb di RAM, quindi forse puoi offrire qualche consiglio anche lì.

Impostare un grande maintenance_work_memper il caricamento dei dati. Userei almeno 8GB.

Impostare un grande work_memper il lavoro di interrogazione. La dimensione appropriata dipende un po 'dalla complessità della query. Inizia con 500MBe sali da lì.

Aumenta il tuo checkpoint_segments(in modo massiccio) per il caricamento iniziale dei dati.

Ricorda di disabilitare l'overcommit della VM! (vedi il manuale PostgreSQL: http://www.postgresql.org/docs/current/static/kernel-resources.html )


22

A proposito degli SSD, il consiglio principale è di abbassare "random_page_cost" su 1 (uguale a "seq_page_cost") in postgresql.conf, oltre alle altre impostazioni abituali.


Forse entrambi i valori dovrebbero essere inferiori a 1.0, come da postgresql.org/docs/11/… : "È possibile aumentare o ridurre entrambi i valori insieme per modificare l'importanza dei costi di I / O del disco rispetto ai costi della CPU, che sono descritti dal seguenti parametri ".
Kirill Bulygin il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.