Comment définir shmall, shmmax, shmmin, etc… en général et pour postgresql


11

J'ai utilisé la documentation de PostgreSQL pour définir par exemple cette configuration:

>>> 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

extrait de sysctl.conf , calculé par mes soins :

kernel.shmall = 1079204
kernel.shmmax = 4420419584

postgresql.conf non par défaut , calculé par moi:

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

Est-ce approprié? Si non (ou pas nécessairement), dans quel cas serait-ce approprié?

Nous avons noté de belles améliorations de performances avec cette configuration, comment l'amélioreriez-vous?

Comment calculer les paramètres de gestion de la mémoire du noyau?

Quelqu'un peut-il expliquer comment les régler vraiment à partir de zéro?


C'est beaucoup de questions, et vous ne nous avez pas dit quel est votre problème actuel (le cas échéant), ou quel est votre modèle d'utilisation. Il pourrait être utile d'obtenir un livre sur les performances de PostgreSQL.
hmallett

Mon problème est que je ne suis pas convaincu d'avoir fait les bons réglages. Je pense que les options de gestion de la mémoire du noyau ne sont pas spécifiques à PostgreSQL et je ne suis pas sûr que PostgreSQL soit le mieux placé pour parler de ces options. Bien sûr, ils sont largement mentionnés dans tout article sur les performances de PostgreSQL, mais ce sont des options Linux et j'ai hâte de vraiment comprendre comment les régler en général.
jpic

Réponses:


11

J'ai répondu à ceci pour une autre question ici:

Git ne parvient pas à pousser avec l'erreur «out of memory»

Je ne réponds pas à toutes vos questions ici, mais à la question dans votre titre:

Comment définir shmall, shmmax, shmmni, etc… en général et pour postgresql

Avec certaines distributions du noyau, certains paramètres empêchent le noyau d'allouer de la mémoire maximale à un seul processus:

Définir les paramètres du noyau

Modifiez le /etc/sysctl.conffichier pour inclure les lignes appropriées à votre système d'exploitation:

# 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

Si votre processus dépasse les limites, le noyau le tuera malgré la mémoire maximale signalée comme étant disponible sur votre système.

Remarque: soyez prudent avec ces paramètres. Vous ne voulez probablement pas utiliser les paramètres de cet exemple car je les ai extraits d'un serveur de notre environnement.

Quelques notes supplémentaires à mentionner:

Pour mettre à jour et tester les paramètres du noyau avec sysctl, utilisez les commandes suivantes:

Liste les paramètres actuels:

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

Désactivez Linux sécurisé en modifiant le /etc/selinux/configfichier, en vous assurant que l'indicateur SELINUX est défini comme suit.

SELINUX=disabled

Est-ce approprié? Si non (ou pas nécessairement), dans quel cas serait-ce approprié?

Les paramètres du noyau sont généralement définis de manière plus stricte dans les environnements de centre de données lorsque les fournisseurs de services Internet ne souhaitent pas qu'un seul processus client monopolise toutes les ressources sur un serveur partagé.

Vous n'avez généralement pas à définir les paramètres de mémoire du noyau, sauf si vous avez un processus qui est tué par le noyau en raison de la famine des ressources.

Dans certains cas, les postgres peuvent également allouer plus de mem à des tailles de page spécifiques que ce qui est disponible dans la mémoire partagée:

* 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!

Des erreurs telles que l'exemple ci-dessus peuvent être résolues en modifiant vos paramètres de ressources du noyau. Les paramètres et méthodes recommandés pour déterminer les paramètres des ressources sont décrits en détail ici:

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

Cependant, vous n'avez vraiment pas besoin de toucher à ces paramètres, sauf si vous rencontrez des situations de famine liée aux processus postgres. Ces situations se produisent, le plus souvent, dans des environnements partagés ou des serveurs avec peu de ressources qui leur sont allouées.

Quelqu'un peut-il expliquer comment les régler vraiment à partir de zéro?

En ce qui concerne le réglage Postgres, vous devriez lire ceci:

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


1
"Remarque: soyez prudent avec ces paramètres. Vous ne voudrez probablement pas utiliser les paramètres de cet exemple car je les ai extraits d'un serveur de notre environnement." Comment dois-je les calculer pour mes environnements?
jpic

1
Hey jpic, j'ai mis à jour pour fournir plus de détails concernant les paramètres du noyau.
Jason Huntley

2

Oh!! Je trouve ici un merveilleux outil pour calculer la configuration optimus mem de notre serveur postgresql.

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


Cet outil n'est pas sur le point de calculer la configuration optimus, il vous donne un point de départ pour régler votre serveur, car il vous donne une réponse basée principalement sur vos paramètres matériels. La taille de la base de données, le nombre de requêtes et les tailles sont également importants pour régler les paramètres de configuration.
EAmez

1

Ces configurations de noyau sont globales et non spécifiques au processus, il est donc approprié de les définir sysctl.conf.


La question est de déterminer les valeurs des paramètres de gestion de la mémoire partagée du noyau, le "comment", pas le "où" ... Merci pour l'effort fourni dans votre réponse.
jpic

oui. là où c'est trivial. comment est la viande de celui-ci.
Henley Chiu

0

Eh bien, cela dépend de ce qui s'exécute sur le serveur, s'il s'agit d'un serveur PostgreSQL pur, PostgreSQL est le bon endroit pour rechercher ces paramètres.
Si vous exécutez d'autres applications / services qui ont des besoins de mémoire spécifiques, vous devrez trouver un paramètre optimal entre ces différentes applications.

Si vous constatez une augmentation des performances sur la base de données et aucune perte de performances sur d'autres applications, je ne m'inquiéterais pas de cela.

En règle générale, les bases de données sont les plus sensibles aux paramètres de mémoire, car elles sont aussi très probablement le goulot d'étranglement sur les performances des applications, il est logique d'optimiser votre système pour la base de données.


Comment "trouver un réglage optimal entre ces différentes applications"? Je n'ai pas de problème de performances, je cherche la manière canonique de configurer les paramètres du noyau de mémoire partagée, comment un vrai pro le ferait-il? Supposons que quelqu'un vous gère un serveur en cours d'exécution avec une poignée de services et vous paie pour définir uniquement les paramètres de gestion de la mémoire, que feriez-vous?
jpic

Il n'y a pas de règle d'or, il suffit de regarder ce que dit le vendeur et de le tester. Si plusieurs applications s'exécutent sur la même machine, essayez d'optimiser l'application la plus gourmande en mémoire, dans la plupart des cas, la base de données. Mais en plus de regarder les suggestions des fournisseurs et de les tester, il n'y a pas de bonne solution
Sibster

Je sais qu'il n'y a pas de règle d'or. J'espérais peut-être que la prime motiverait quelqu'un qui comprend parfaitement cela à écrire des instructions. Mais je pense que personne ne comprend vraiment vraiment cela après tout - puisque personne n'est en mesure de donner une explication simple.
jpic
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.