Come impostare shmall, shmmax, shmmin, ecc ... in generale e per postgresql


11

Ho usato la documentazione di PostgreSQL per impostare ad esempio questa configurazione:

>>> cat /proc/meminfo 
MemTotal:       16345480 kB
MemFree:         1770128 kB
Buffers:          382184 kB
Cached:         10432632 kB
SwapCached:            0 kB
Active:          9228324 kB
Inactive:        4621264 kB
Active(anon):    7019996 kB
Inactive(anon):   548528 kB
Active(file):    2208328 kB
Inactive(file):  4072736 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:              3432 kB
Writeback:             0 kB
AnonPages:       3034588 kB
Mapped:          4243720 kB
Shmem:           4533752 kB
Slab:             481728 kB
SReclaimable:     440712 kB
SUnreclaim:        41016 kB
KernelStack:        1776 kB
PageTables:        39208 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     8172740 kB
Committed_AS:   14935216 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      399340 kB
VmallocChunk:   34359334908 kB
HardwareCorrupted:     0 kB
AnonHugePages:    456704 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       12288 kB
DirectMap2M:    16680960 kB

>>> ipcs -l          

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 4316816
max total shared memory (kbytes) = 4316816
min seg size (bytes) = 1

------ Semaphore Limits --------
max number of arrays = 128
max semaphores per array = 250
max semaphores system wide = 32000
max ops per semop call = 32
semaphore max value = 32767

------ Messages Limits --------
max queues system wide = 31918
max size of message (bytes) = 8192
default max size of queue (bytes) = 16384

estratto di sysctl.conf , calcolato da me:

kernel.shmall = 1079204
kernel.shmmax = 4420419584

postgresql.conf non predefiniti , calcolati da me:

max_connections = 60            # (change requires restart)
shared_buffers = 4GB            # min 128kB
work_mem = 4MB              # min 64kB
wal_sync_method = open_sync     # the default is the first option
checkpoint_segments = 16        # in logfile segments, min 1, 16MB each
checkpoint_completion_target = 0.9  # checkpoint target duration, 0.0 - 1.0
effective_cache_size = 6GB

È appropriato? In caso contrario (o non necessariamente), in quale caso sarebbe appropriato?

Abbiamo notato dei miglioramenti delle prestazioni con questa configurazione, come la miglioreresti?

Come calcolare i parametri di gestione della memoria del kernel?

Qualcuno può spiegare come impostarli davvero da zero?


Sono molte domande e non ci hai detto qual è il tuo problema attuale (se presente) o quale sia il tuo modello di utilizzo. Potrebbe valere la pena ottenere un libro sulle prestazioni di PostgreSQL.
hmallett,

Il mio problema è che non sono convinto di aver effettuato le impostazioni giuste. Penso che le opzioni di gestione della memoria del kernel non siano specifiche di PostgreSQL, inoltre non sono sicuro che PostgreSQL sia il posto migliore per parlare di queste opzioni. Certo, sono ampiamente menzionati in qualsiasi articolo sulle prestazioni di PostgreSQL, ma quelle sono opzioni Linux e non vedo l'ora di capire davvero come regolarle in generale.
jpic,

Risposte:


11

Ho risposto a questa domanda per un'altra domanda qui:

Git non riesce a spingere con errore 'memoria insufficiente'

Non sto rispondendo a tutte le tue domande qui, ma la domanda nel tuo titolo:

Come impostare shmall, shmmax, shmmni, ecc ... in generale e per postgresql

Con alcune distribuzioni del kernel, ci sono impostazioni che impediscono al kernel di allocare memoria massima a un singolo processo:

Imposta i parametri del kernel

Modifica il /etc/sysctl.conffile per includere le righe appropriate al tuo sistema operativo:

# Red Hat Enterprise Linux 3.0 and CentOS 3.x 
kernel.shmmax = 2147483648
kernel.shmmni = 4096
kernel.shmall = 2097152
kernel.shmmin = 1
kernel.shmseg = 10

# semaphores: 
semmsl, semmns, semopm, semmni kernel.sem = 250 32000 100 128
fs.file-max = 65536

# Red Hat Enterprise Linux 4.0 and CentOS 4.x 
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.shmall = 2097152

Se il processo supera i limiti, il kernel interromperà il processo nonostante la memoria massima indicata sia disponibile sul sistema.

Nota: fare attenzione con queste impostazioni. Probabilmente non vorrai usare le impostazioni in quell'esempio mentre le estraevo da un server nel nostro ambiente.

Alcune note extra da menzionare:

Per aggiornare e testare le impostazioni del kernel con sysctl, usare i seguenti comandi:

Elenca le impostazioni correnti:

sysctl -A | grep shm
sysctl -w kernel.shmmax=<value> to write in sysctl.conf
sysctl -p /etc/sysctl.conf to read/reload the values from sysctl.conf

Disabilita linux sicuro modificando il /etc/selinux/configfile, assicurandoti che il flag SELINUX sia impostato come segue.

SELINUX=disabled

È appropriato? In caso contrario (o non necessariamente), in quale caso sarebbe appropriato?

Le impostazioni del kernel sono generalmente definite in modo più rigoroso negli ambienti di datacenter quando i provider ISP non vogliono che un singolo processo del cliente registri tutte le risorse su un server condiviso.

Di solito non è necessario impostare i parametri di memoria del kernel a meno che non si abbia un processo che viene ucciso dal kernel a causa della fame di risorse.

In alcuni casi, Postgres può anche allocare più mem a dimensioni di pagina specifiche rispetto a quelle disponibili nella memoria condivisa:

* The PostgreSQL server failed to start. Please check the log output:
2011-11-04 05:06:26 UTC FATAL: could not create shared memory segment: Invalid
argument
2011-11-04 05:06:26 UTC DETAIL: Failed system call was shmget(key=5432001, size
=161849344, 03600).
2011-11-04 05:06:26 UTC HINT: This error usually means that PostgreSQL’s reques
t for a shared memory segment exceeded your kernel’s SHMMAX parameter. You can
either reduce the request size or reconfigure the kernel with larger SHMMAX. To
reduce the request size (currently 161849344 bytes), reduce PostgreSQL’s shared
_buffers parameter (currently 19200) and/or its max_connections parameter (curre
ntly 53).
If the request size is already small, it’s possible that it is less than
your kernel’s SHMMIN parameter, in which case raising the request size or recon
figuring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared memo
ry configuration.
…fail!

Errori come l'esempio sopra, possono essere risolti modificando le impostazioni delle risorse del kernel. Le impostazioni e i metodi consigliati, per determinare le impostazioni delle risorse, sono descritti in dettaglio qui:

http://www.postgresql.org/docs/9.1/static/kernel-resources.html

Tuttavia, in realtà non è necessario toccare queste impostazioni a meno che non si verifichino situazioni di fame di risorse correlate al processo di postgres. Queste situazioni si verificano, molto spesso, in ambienti o server condivisi con poche risorse allocate a loro.

Qualcuno può spiegare come impostarli davvero da zero?

Per quanto riguarda la messa a punto di Postgres, dovresti leggere questo:

http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server


1
"Nota: stai attento con queste impostazioni. Probabilmente non vorrai usare le impostazioni in quell'esempio mentre le estraevo da un server nel nostro ambiente." Come devo calcolarli per i miei ambienti?
jpic,

1
Ehi jpic, ho aggiornato per fornire maggiori dettagli sulle impostazioni del kernel.
Jason Huntley,

2

Oh!! Trovo qui uno strumento meraviglioso per calcolare la configurazione mem ottimus del nostro server postgresql.

http://pgtune.leopard.in.ua/


Questo strumento non sta per calcolare la configurazione di optimus, ti dà un punto di partenza per ottimizzare il tuo server, in quanto ti dà una risposta basata principalmente sulle tue impostazioni hardware. Anche le dimensioni del database, il numero di query e dimensioni sono importanti per ottimizzare i parametri di configurazione.
EAmez,

1

Le configurazioni del kernel sono globali, non specifiche del processo, quindi è opportuno impostarle sysctl.conf.


La domanda riguarda la determinazione dei valori dei parametri di gestione della memoria condivisa del kernel, il "come", non il "dove" ... Grazie per l'impegno profuso nella risposta.
jpic,

Sì. là dove è banale. come è la carne di esso.
Henley Chiu,

0

Bene dipende da cos'altro è in esecuzione sul server, se questo è un server PostgreSQL puro, PostgreSQL è il posto giusto per cercare queste impostazioni.
Se si eseguono altre applicazioni / servizi con esigenze di memoria specifiche, sarà necessario trovare un'impostazione ottimale tra queste diverse applicazioni.

Se stai vedendo un aumento delle prestazioni nel database e nessuna perdita di prestazioni su altre applicazioni, non mi preoccuperei di questo.

Generalmente i database sono i più sensibili alle impostazioni di memoria, poiché sono anche molto probabilmente i colli di bottiglia nelle prestazioni delle applicazioni, ha senso ottimizzare il sistema per il DB.


Come "trovare un'impostazione ottimale tra queste diverse applicazioni"? Non ho problemi di prestazioni, sto cercando il modo canonico di configurare le impostazioni del kernel di memoria condivisa, come farebbe un vero professionista? Supponiamo che qualcuno ti gestisca un server in esecuzione con una manciata di servizi e ti paghi per configurare solo le impostazioni di gestione della memoria, cosa faresti?
jpic,

Non esiste una regola d'oro, basta guardare ciò che dice il venditore e testarlo. Se si hanno più applicazioni in esecuzione sullo stesso computer, provare a ottimizzare per l'applicazione che richiede più memoria, nella maggior parte dei casi il DB. Ma oltre a guardare i suggerimenti del fornitore en testarli non esiste una soluzione unica giusta
Sibster

So che non esiste una regola d'oro. Speravo che forse la generosità avrebbe motivato qualcuno che lo capiva davvero a scrivere alcune indicazioni. Ma penso che nessuno lo capisca davvero del tutto, dal momento che nessuno è in grado di dare una spiegazione semplice.
jpic,
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.