En cours d’installation d’un serveur BlueMind pour la fourniture de service mail pour un futur C.H.A.T.O.N.S Cherbourgeois , sous une VM Debian 8 (KVM sous Proxmox), j’ai trouvé une incompatibilité entre le serveur Postgres et l’agent Zabbix 3.4
En creusant un peu, les valeurs d’allocation mémoire me semblent erronées
root@duchess:/# sysctl -a | grep -E "shmall|shmmax"
kernel.shmall = 18446744073692774399
kernel.shmmax = 300000
root@duchess:/# ipcs -lm
------ Limites de la mémoire partagée --------
nombre maximal de segments = 4096
taille maximale de segment (kilooctet) = 292
total de mémoire partagée maximal (kilooctet) = 18014398442373116
taille minimale de segment (octet) = 1
root@duchess:/#
Faute de temps, je ne peux creuser le problème maintenant.
Je suppute une interaction entre Prostgres et l’agent Zabbix, ce dernier est tombé après l’installation de Bluemind.
Mais cela peut venir d’une mauvaise interaction avec mon superviseur Proxmox …
Je vais donc procéder à une installation sous un Ubuntu 16.04 LTS
Et je ne manquerais pas de vous tenir informer de l’évolution
Je ne pense que le problème soit lié à postgresql, la version utilisée maintenant (9.6) ne nécessite plus de devoir toucher à ces paramètres, je pencherai plus sur le template zabbix qui serait mal paramétré.
merci de ton retour.
J’ai le même soucis sous Xenial
Effectivement tu as raisons, les valeurs sont inhibé dans /etc/sysctl.d/30-postgresql-shm.conf
Je vais donc creuser coté Client Zabbix … .
apm@duchess:~$ grep kernel /etc/sysctl.d/*
/etc/sysctl.d/10-console-messages.conf:kernel.printk = 4 4 1 7
/etc/sysctl.d/10-kernel-hardening.conf:# These settings are specific to hardening the kernel itself from attack
/etc/sysctl.d/10-kernel-hardening.conf:# When an attacker is trying to exploit the local kernel, it is often
/etc/sysctl.d/10-kernel-hardening.conf:# helpful to be able to examine where in memory the kernel, modules,
/etc/sysctl.d/10-kernel-hardening.conf:# and data structures live. As such, kernel addresses should be treated
/etc/sysctl.d/10-kernel-hardening.conf:# of "0" allows all users to see the kernel addresses. A value of "1"
/etc/sysctl.d/10-kernel-hardening.conf:kernel.kptr_restrict = 1
/etc/sysctl.d/10-magic-sysrq.conf:# interpreted by the kernel to help with debugging. The kernel will respond
/etc/sysctl.d/10-magic-sysrq.conf:# debugging dumps of processes: kernel.sysrq = 10
/etc/sysctl.d/10-magic-sysrq.conf:kernel.sysrq = 176
/etc/sysctl.d/10-ptrace.conf:kernel.yama.ptrace_scope = 1
/etc/sysctl.d/10-zeropage.conf:# Protect the zero page of memory from userspace mmap to prevent kernel
/etc/sysctl.d/10-zeropage.conf:# NULL-dereference attacks against potential future kernel security
/etc/sysctl.d/10-zeropage.conf:# vulnerabilities. (Added in kernel 2.6.23.)
/etc/sysctl.d/10-zeropage.conf:# While this default is built into the Ubuntu kernel, there is no way to
/etc/sysctl.d/10-zeropage.conf:# restore the kernel default if the value is changed during runtime; for
/etc/sysctl.d/30-postgresql-shm.conf:#kernel.shmmax = 33554432
/etc/sysctl.d/30-postgresql-shm.conf:#kernel.shmall = 2097152
/etc/sysctl.d/99-sysctl.conf:#kernel.domainname = example.com
/etc/sysctl.d/99-sysctl.conf:#kernel.printk = 3 4 1 3
/etc/sysctl.d/99-sysctl.conf:kernel.shmmax=300000
apm@duchess:~$
Je viens de faire un test d’installation à Blanc de paquet BM … .
Je n’ai pas vu de modification des valeurs, je creuse donc encore afin de reproduire le phénomène et trouver la cause
Trouvé,
kernel.shmmax=300000
est bien configuré lors du setup de la DB … .
Sur le long terme qu’elle est l’impact si je remets la valeur par défaut de l’OS
[question c… mais pas sous l’influence d’un bon calva de 25 ans (au moins) … . Bienvenu en dans le Nord-Cotentin ]
Tchin, Arnaud peux-tu passer mes amitiés à toute l’équipe , crdt Poustiquet]
