osm-fr
Paramétrages des kernel
En investiguant sur les freeze d'osm11 je pense qu'il y a du tuning à revoir au niveau du kernel :
- [x] Désactiver les transparent huge pages
- [ ] Toujours s'assurer que vm.zone_reclaim_mode à 0
- [ ] kernel.sched_migration_cost_ns à 5000000
- [ ] kernel.sched_autogroup_enabled à 0
- [ ] Allouer des huges pages selon les instances pg installées
- [ ] S'assurer d'avoir le swappiness bas
^ j'ai corrigé, il s'agissait d'osm11.
Les paramètres du kernel sont "vanilla", tels qu'installés à l'origine par proxmox/buster.
Je n'ai rien contre leur tuning, au contraire. Au préalable, il faudrait peut être juste vérifier sur le forum proxmox si il y a des raisons pour les valeurs actuelles ou pas...
J'imagine que ce sont les valeurs par defaut. Pour les THP c'est une recommendation courante de les désactiver.
Explication très claire sur les THP ici: https://blog.nelhage.com/post/transparent-hugepages/
Le réglage optimal semble être "madvise" où seules les apps qui ont besoin des huge page les utiliseront... dommage que ce ne soit pas le réglage par défaut. A remonter côté proxmox, où je n'ai rien trouvé à ce sujet dans le forum.
Tu es sûr que ce n'est pas la config par défaut ?
Je lis ça sur osm11, et j'ai vu la même valeur l'autre jour:
$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
Effectivement, bizarre, bizarre, ça ne me dit absolument rien... donc à remettre en madvise, valeur qu'on a sur osm25..28
Même en madvise, j'ai déjà eu des gros soucis de perf avec certaines applis dans du LXC un peu chargé.
En l'occurrence c'était PHP, chaque appel à madvise prenait pas loin d'1 seconde, et il en fait un paquet à chaque requête. Ça donnait un nextcloud complètement inutilisable tellement il rame et bouffe du CPU.
Le problème est décrit ici et semble s'appliquer à d'autres soft : https://stackoverflow.com/a/49653273
Solution : complètement désactiver les Transparent Huge Pages si on n'en a pas besoin.
Ok, je me mélange, donc madvise c'est encore trop et donc il faudrait passer à never partout si je comprends bien. Ce qui est surprenant c'est qu'on a eu des freeze que sur osm11, mais bon c'est là où on a des usages importants en RAM (PG sur osm165, renderd sur osm166).
Le thread sur stackoverflow fait aussi référence à des container LXC et ZFS... notre cas ici pour osm166...
J'ai fait un simple echo never > /sys/kernel/mm/transparent_hugepage/enabled sur osm11 pour voir ce que ça change et observer si au niveau des graphes munin on a des changements à partir de 10H UTC...
Disons que madvise limite les dégâts, seules les applications qui utilisent madvise seront touchées.
À noter : j'avais observé ce problème sur Debian stretch en noyau 4.9, ça a pu être corrigé dans les noyaux plus récents. Ça arrivait après quelques jours / semaines d'uptime et typiquement quand le système était un peu juste en RAM.
On parle du gros trou vendredi après-midi j'imagine ? http://munin.openstreetmap.fr/osm11.openstreetmap.fr/osm11.openstreetmap.fr/index.html#system
Par contre il me semble que désactiver les THP ne touche pas aux pages actuellement allouées (ça se vérifie avec la ligne AnonHugePages dans /proc/meminfo). C'est pour ça qu'on conseille généralement de le désactiver au boot en passant transparent_hugepage=never au noyau.
On n'a pas de huge page actuellement sur osm11:
AnonHugePages: 0 kB
Pour l'activer au boot, est-ce qu'une solution plus propre ne serait pas de passer par le paquet sysfsutils, en rajoutant ceci dans /etc/sysfs.conf ?
kernel/mm/transparent_hugepage/enabled = never
Concernant les autres paramètres, j'ai créé un fichier /etc/sysctl.d/osmfr-tuning.conf sur osm11 avec ce contenu:
vm.swappiness = 1
vm.zone_reclaim_mode = 0
kernel.sched_migration_cost_ns = 5000000
kernel.sched_autogroup_enabled = 0
(ces valeurs étaient en fait déjà actives, sauf pour kernel.sched_autogroup_enabled et kernel.sched_migration_cost_ns)
@anayrat: concernant "Allouer des huges pages selon les instances pg installées", comment ça peut se configurer ?
@anayrat: concernant "Allouer des huges pages selon les instances pg installées", comment ça peut se configurer ?
Il faut spécifier le nombre de pages à allouer avec
vm.nr_overcommit_hugepages = 150
Là c'est pour réserver 150* 4Kb d'hugepages. On peut aussi faire avec vm.nr_hugepages mais dans ce cas les pages sont vraiment allouées même si personne ne s'en sert.
Après sur la quantité ça dépend du nombre d'instances et de la taille des shared_buffers de chaque instance. Un moyen simple de savoir c'est de mettre huge_pages à on dans postgresql.conf, pg n'arrivera pas à démarrer mais il te dira quelle quantité il a cherché à allouer.