Ainsi, l'approche correcte est de d\u00e9sactiver totalement le NUMA.<\/strong>, par exemple, au red\u00e9marrage. Dans la plupart des cas, les gains sont si importants qu'il n'y a m\u00eame pas de question sur la meilleure option. <\/p>\n<\/p>\n
Il existe une autre option. Nous l'utilisons plus souvent que la premi\u00e8re, car lorsque nous assistons un client, red\u00e9marrer le serveur est un gros probl\u00e8me pour lui. Son entreprise tourne l\u00e0-dessus. Il rencontre des probl\u00e8mes \u00e0 cause du NUMA. Ainsi, nous essayons de d\u00e9sactiver de mani\u00e8re moins invasive que par un red\u00e9marrage, mais il faut \u00eatre prudent et v\u00e9rifier que cela a bien \u00e9t\u00e9 d\u00e9sactiv\u00e9. Car, comme l'exp\u00e9rience le montre, d\u00e9sactiver le NUMA sur le processus principal de PostgreSQL est une bonne id\u00e9e, mais il n'est pas du tout certain que cela fonctionnera. Il faut v\u00e9rifier et s'assurer que cela a bien \u00e9t\u00e9 d\u00e9sactiv\u00e9. <\/p>\n
<\/p>\n
Il y a un bon article de Robert Haas. C'est l'un des committers de PostgreSQL. Un des d\u00e9veloppeurs cl\u00e9s de tous les \u00e9l\u00e9ments de bas niveau. Et si vous suivez les liens de cet article, vous y trouverez plusieurs histoires color\u00e9es sur la fa\u00e7on dont le NUMA compliquait la vie des gens. Regardez, examinez la checklist pour les administrateurs syst\u00e8me sur ce qu'il faut configurer sur le serveur afin que notre base de donn\u00e9es fonctionne correctement. Ces param\u00e8tres doivent \u00eatre not\u00e9s et v\u00e9rifi\u00e9s, car sinon, cela ne se passera pas tr\u00e8s bien. <\/p>\n
<\/p>\n
Je tiens \u00e0 souligner que cela concerne tous les param\u00e8tres dont je vais parler. Mais g\u00e9n\u00e9ralement, les bases de donn\u00e9es sont configur\u00e9es en mode ma\u00eetre-esclave pour la tol\u00e9rance aux pannes. N'oubliez pas d'appliquer ces param\u00e8tres sur l'esclave, car \u00e0 un moment donn\u00e9, vous aurez une panne, et vous passerez en mode esclave, qui deviendra le ma\u00eetre. <\/p>\n
<\/p>\n
Dans une situation d'urgence, lorsque tout va mal, votre t\u00e9l\u00e9phone sonne sans cesse et votre sup\u00e9rieur arrive avec un gros b\u00e2ton, vous n'aurez pas le temps de v\u00e9rifier. Et les r\u00e9sultats peuvent \u00eatre assez d\u00e9sastreux.<\/p>\n
<\/p>\n
<\/p>\n
Le point suivant concerne les huge pages. Il est difficile de tester les huge pages s\u00e9par\u00e9ment, et cela n'a pas beaucoup de sens, bien qu'il existe des benchmarks qui peuvent le faire. Ils se recherchent facilement sur Internet. <\/p>\n
<\/p>\n
Quel est le but ? Vous avez un serveur pas tr\u00e8s cher, avec beaucoup de m\u00e9moire vive, par exemple, plus de 30 Go. Vous n'utilisez pas de huge pages. Cela signifie que vous avez certainement un surco\u00fbt li\u00e9 \u00e0 l'utilisation de la m\u00e9moire. Et ce surco\u00fbt n'est pas des plus agr\u00e9ables. <\/p>\n
<\/p>\n
<\/p>\n
Pourquoi cela ? Que se passe-t-il ? Le syst\u00e8me d'exploitation alloue de la m\u00e9moire par petits morceaux. C'est pratique, c'est historiquement comme \u00e7a. Et si on entre dans les d\u00e9tails, le syst\u00e8me d'exploitation doit traduire les adresses virtuelles en adresses physiques. C'est un processus qui n'est pas des plus simples, c'est pourquoi le syst\u00e8me d'exploitation met en cache le r\u00e9sultat de cette op\u00e9ration dans le Translation Lookaside Buffer (TLB).<\/p>\n
<\/p>\n
Et puisque le TLB est un cache, des probl\u00e8mes typiques de cache se posent dans cette situation. Tout d'abord, si vous avez beaucoup de m\u00e9moire vive et qu'elle est enti\u00e8rement allou\u00e9e par petits morceaux, alors ce tampon devient tr\u00e8s grand. Et si le cache est gros, il est plus lent \u00e0 rechercher. Le surco\u00fbt est important et consomme de l'espace, c'est-\u00e0-dire que quelque chose de non optimal consomme la m\u00e9moire vive. C'est un probl\u00e8me. <\/p>\n
<\/p>\n
Deux \u2013 plus le cache s'agrandit dans une telle situation, plus la probabilit\u00e9 de manquer de cache augmente. L'efficacit\u00e9 de ce cache diminue rapidement avec la taille croissante. C'est pourquoi les syst\u00e8mes d'exploitation ont mis au point une approche simple. Dans Linux, cela est utilis\u00e9 depuis longtemps. Dans FreeBSD, cela a r\u00e9cemment \u00e9t\u00e9 introduit. Mais parlons de Linux. Ce sont les huge pages.<\/p>\n
<\/p>\n
Il convient de noter ici que les huge pages, en tant qu'id\u00e9e, ont \u00e9t\u00e9 initialement soutenues par des communaut\u00e9s comprenant Oracle et IBM, c'est-\u00e0-dire que les producteurs de bases de donn\u00e9es ont bien pens\u00e9 que cela serait utile, notamment pour les bases de donn\u00e9es. <\/p>\n
<\/p>\n
<\/p>\n
Et comment cela s'int\u00e8gre-t-il avec PostgreSQL ? Tout d'abord, le noyau Linux doit avoir des huge pages activ\u00e9es.<\/p>\n
<\/p>\n
Deuxi\u00e8mement, elles doivent \u00eatre explicitement sp\u00e9cifi\u00e9es par le param\u00e8tre sysctl \u2013 combien il y en a. Les chiffres ici proviennent d'un ancien serveur. Vous pouvez estimer combien de buffers partag\u00e9s vous avez pour que les huge pages puissent y entrer. <\/p>\n
<\/p>\n
Et si vous avez enti\u00e8rement allou\u00e9 le serveur \u00e0 PostgreSQL, un bon point de d\u00e9part est de consacrer soit 25 % de la m\u00e9moire vive aux buffers partag\u00e9s, soit 75 %, si vous \u00eates s\u00fbr que votre base de donn\u00e9es pourra tenir dans ces 75 %. C'est le premier point de d\u00e9part. Et calculez, si vous avez 256 Go de m\u00e9moire vive, alors vous aurez 64 Go de buffers partag\u00e9s. Estimez \u00e0 peu pr\u00e8s avec une marge \u2013 quelle devrait \u00eatre cette valeur.<\/p>\n
<\/p>\n
Avant la version 9.2 (si je ne me trompe pas, depuis la version 8.2), il \u00e9tait possible d'int\u00e9grer PostgreSQL avec les huge pages \u00e0 l'aide d'une biblioth\u00e8que tierce. Et cela doit toujours \u00eatre fait. Tout d'abord, vous devez vous assurer que le noyau peut allouer correctement les huge pages. Et ensuite, l'application qui travaille avec elles doit pouvoir en profiter. Elle ne pourra pas y acc\u00e9der simplement. \u00c9tant donn\u00e9 que PostgreSQL allouait de la m\u00e9moire dans le style de system 5, cela pouvait \u00eatre fait avec libhugetlbfs \u2013 tel est le nom complet de la biblioth\u00e8que.<\/p>\n
<\/p>\n
Dans la version 9.3, les performances de PostgreSQL en mati\u00e8re de gestion de la m\u00e9moire ont \u00e9t\u00e9 am\u00e9lior\u00e9es, et la m\u00e9thode d'allocation de m\u00e9moire system 5 a \u00e9t\u00e9 abandonn\u00e9e. Tout le monde \u00e9tait ravi, car sinon, lorsque vous essayiez de lancer deux instances de PostgreSQL sur une seule machine, il signalait un manque de m\u00e9moire partag\u00e9e. Il disait qu'il fallait modifier sysctl. Et avec ce sysctl, il fallait \u00e9galement red\u00e9marrer, et ainsi de suite. En gros, tout le monde \u00e9tait content. Mais l'allocation de m\u00e9moire mmap a cass\u00e9 l'utilisation des huge pages. La plupart de nos clients utilisent de grands buffers partag\u00e9s. Et nous avons fortement recommand\u00e9 de ne pas passer \u00e0 la version 9.3, car cela entra\u00eenait un overhead significatif.<\/p>\n
<\/p>\n
Cependant, la communaut\u00e9 a port\u00e9 une attention particuli\u00e8re \u00e0 ce probl\u00e8me et a proc\u00e9d\u00e9 \u00e0 des modifications importantes dans la version 9.4. De plus, un param\u00e8tre a \u00e9t\u00e9 ajout\u00e9 dans postgresql.conf, permettant de l'activer, de le mettre sur on ou off.<\/p>\n
<\/p>\n
Le param\u00e8tre Try est le plus s\u00fbr. Au d\u00e9marrage de PostgreSQL, lorsqu'il alloue de la m\u00e9moire partag\u00e9e, il essaie de l'obtenir \u00e0 partir des huge pages. Si cela \u00e9choue, il revient \u00e0 l'allocation classique. Si vous \u00eates sous FreeBSD ou Solaris, vous pouvez mettre try, c'est toujours s\u00fbr. <\/p>\n
<\/p>\n
Si on le met sur on, il ne d\u00e9marre pas s'il ne parvient pas \u00e0 allouer des huge pages. C'est une question de pr\u00e9f\u00e9rences personnelles. Mais si vous optez pour try, assurez-vous que les allocations n\u00e9cessaires ont bien \u00e9t\u00e9 r\u00e9alis\u00e9es, car il y a beaucoup de marges d\u2019erreur. Maintenant, cette fonctionnalit\u00e9 ne fonctionne que sur Linux.<\/p>\n
<\/p>\n
Une petite remarque avant de continuer. Les transparent huge pages ne concernent pas encore PostgreSQL. Actuellement, il ne peut pas vraiment en profiter. Et pour les transparent huge pages, pour une charge de travail n\u00e9cessitant un grand morceau de m\u00e9moire partag\u00e9e, les avantages n'apparaissent qu'\u00e0 des volumes tr\u00e8s \u00e9lev\u00e9s. Si vous avez des t\u00e9raoctets de m\u00e9moire, cela peut \u00eatre significatif. Cependant, pour des applications plus courantes, o\u00f9 vous disposez de 32, 64, 128 ou 256 Go de m\u00e9moire sur une machine, les huge pages normaux sont suffisants, tandis que les transparent huge pages doivent simplement \u00eatre d\u00e9sactiv\u00e9s. <\/p>\n
<\/p>\n
<\/p>\n
Enfin, un dernier point concernant la m\u00e9moire, qui n'est pas directement li\u00e9 au d\u00e9bit, mais qui peut causer beaucoup de probl\u00e8mes. L'ensemble de la bande passante peut \u00eatre gravement affect\u00e9 si le serveur swap constamment. <\/p>\n
<\/p>\n
Et cela sera tr\u00e8s d\u00e9sagr\u00e9able \u00e0 plusieurs moments. Le principal probl\u00e8me est que dans les noyaux modernes, le comportement diff\u00e8re l\u00e9g\u00e8rement de celui des noyaux Linux plus anciens. C'est une situation assez d\u00e9licate, parce que, lorsque nous parlons de gestion de l'\u00e9change, cela se termine souvent par l'arriv\u00e9e tardive de l'OOM-killer. Et le fait que l'OOM-killer arrive en retard et mette fin \u00e0 PostgreSQL est d\u00e9sagr\u00e9able. Tout le monde en sera inform\u00e9, c'est-\u00e0-dire jusqu'au dernier utilisateur. <\/p>\n
<\/p>\n
<\/p>\n
Que se passe-t-il ? Vous avez beaucoup de m\u00e9moire vive, tout fonctionne bien. Mais pour une raison quelconque, le serveur se bloque dans l'\u00e9change et s'enlente \u00e0 cause de cela. On pourrait penser qu'il y a beaucoup de m\u00e9moire, mais cela arrive quand m\u00eame. <\/p>\n
<\/p>\n
<\/p>\n
Auparavant, nous recommandions de d\u00e9finir vm.swappiness \u00e0 z\u00e9ro, c'est-\u00e0-dire de d\u00e9sactiver l'\u00e9change. On pensait que 32 Go de m\u00e9moire vive et des buffers partag\u00e9s ad\u00e9quats repr\u00e9sentaient une \u00e9norme quantit\u00e9. La principale fonction de l'\u00e9change est de disposer d'un espace o\u00f9 jeter le r\u00e9sidu, si nous avons un plantage. Et cela ne s'est pas vraiment produit. Et que ferez-vous ensuite avec ce r\u00e9sidu ? C'est une t\u00e2che o\u00f9 il n'est pas tr\u00e8s clair pourquoi l'\u00e9change est n\u00e9cessaire, surtout d'une telle taille. <\/p>\n
<\/p>\n
Cependant, dans les versions plus modernes, \u00e0 savoir la troisi\u00e8me version des noyaux, le comportement a chang\u00e9. Si vous d\u00e9finissez l'\u00e9change \u00e0 z\u00e9ro, c'est-\u00e0-dire que vous l'\u00e9teignez, t\u00f4t ou tard, m\u00eame avec un certain reste de m\u00e9moire vive, l'OOM-killer viendra pour \u00e9liminer les consommateurs les plus intensifs. Parce qu'il pensera qu'avec cette charge de travail, il nous reste encore un peu et nous allons manquer, c'est-\u00e0-dire qu'il ne tuera pas un processus syst\u00e8me, mais quelque chose de moins important. Ce moins important sera un consommateur intensif de m\u00e9moire partag\u00e9e, en l'occurrence le postmaster. Et apr\u00e8s cela, il vaut mieux ne pas avoir \u00e0 restaurer la base de donn\u00e9es. <\/p>\n
<\/p>\n
Ainsi, maintenant par d\u00e9faut, autant que je me souvienne, la plupart des distributions sont autour de 6, c'est-\u00e0-dire \u00e0 quel moment commencer \u00e0 utiliser l'\u00e9change en fonction de la quantit\u00e9 de m\u00e9moire restante. Nous recommandons actuellement de d\u00e9finir vm.swappiness = 1, car cela le d\u00e9sactive pratiquement, mais ne provoque pas des effets tels que l'arriv\u00e9e inattendue de l'OOM-killer qui met tout cela fin.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Quoi de neuf ? Lorsque nous parlons de performance des bases de donn\u00e9es et que nous nous rapprochons progressivement des disques, tout le monde commence \u00e0 se rendre compte des difficult\u00e9s. Car la v\u00e9rit\u00e9 selon laquelle le disque est lent et la m\u00e9moire rapide est bien connue de tous depuis l'enfance. Et tout le monde sait qu'il y aura des probl\u00e8mes de performance disque dans une base de donn\u00e9es.<\/p>\n
<\/p>\n
Le principal probl\u00e8me de performance de PostgreSQL li\u00e9 aux pics de checkpoints ne vient pas du fait que le disque est lent. C'est plut\u00f4t \u00e0 cause du d\u00e9s\u00e9quilibre entre la bande passante de la m\u00e9moire et celle du disque. D'ailleurs, cet \u00e9quilibre peut \u00eatre rompu \u00e0 diff\u00e9rents niveaux. PostgreSQL n'est pas configur\u00e9, le syst\u00e8me d'exploitation n'est pas configur\u00e9, le mat\u00e9riel n'est pas r\u00e9gl\u00e9 et le mat\u00e9riel est incorrect. Et ce probl\u00e8me ne se manifeste que si tout fonctionne comme pr\u00e9vu, c'est-\u00e0-dire soit en l'absence de charge, soit avec des r\u00e9glages et du mat\u00e9riel bien choisis. <\/p>\n
<\/p>\n
<\/p>\n
Qu'est-ce que c'est et \u00e0 quoi \u00e7a ressemble ? En g\u00e9n\u00e9ral, les personnes qui travaillent avec PostgreSQL ont \u00e9t\u00e9 confront\u00e9es \u00e0 cela \u00e0 plusieurs reprises. Je vais expliquer. Comme je l'ai mentionn\u00e9, PostgreSQL effectue p\u00e9riodiquement des checkpoints pour transf\u00e9rer les pages sales de la m\u00e9moire partag\u00e9e vers le disque. Si nous avons un grand volume de m\u00e9moire partag\u00e9e, le checkpoint commence \u00e0 impacter intens\u00e9ment le disque, car il transf\u00e8re ces pages avec fsync. Elles arrivent dans le tampon du noyau et sont \u00e9crites sur les disques \u00e0 l'aide de fsync. Et si ce volume est important, nous pouvons observer un effet d\u00e9sagr\u00e9able, \u00e0 savoir une tr\u00e8s forte utilisation des disques.<\/p>\n
<\/p>\n
J'ai ici deux images. Je vais maintenant expliquer ce que c'est. Ce sont deux graphiques corr\u00e9l\u00e9s dans le temps. Le premier graphique - c'est l'utilisation du disque. Ici, elle atteint presque 90 % \u00e0 ce moment-l\u00e0. Si votre base de donn\u00e9es est li\u00e9e \u00e0 des disques physiques, avec un contr\u00f4leur RAID et que l'utilisation atteint 90 %, ce sont de mauvaises nouvelles. Cela signifie qu'un peu plus et nous atteindrons 100, ce qui arr\u00eatera les entr\u00e9es-sorties. <\/p>\n
<\/p>\n
Si vous avez un ensemble de disques, l'histoire est un peu diff\u00e9rente. Cela d\u00e9pend de la mani\u00e8re dont il est configur\u00e9, de la nature de l'ensemble, etc. <\/p>\n
<\/p>\n
Parall\u00e8lement, un graphique configur\u00e9 \u00e0 partir de la vue interne de Postgres montre comment se d\u00e9roule le checkpoint. En vert, on indique le nombre de buffers, c'est-\u00e0-dire ces pages sales qui ont \u00e9t\u00e9 transf\u00e9r\u00e9es \u00e0 ce moment-l\u00e0 pour la synchronisation lors de ce checkpoint. C'est l'essentiel \u00e0 savoir ici. Nous voyons qu'il y a beaucoup de pages arriv\u00e9es, et \u00e0 un moment donn\u00e9, nous avons atteint la limite, c'est-\u00e0-dire que nous avons beaucoup \u00e9crit, et il est \u00e9vident que le syst\u00e8me de disque est tr\u00e8s sollicit\u00e9. Nous constatons que le checkpoint a un impact significatif sur le disque. Id\u00e9alement, la situation devrait plut\u00f4t ressembler \u00e0 ceci, c'est-\u00e0-dire que nous avons moins d'\u00e9critures ici. Nous pouvons r\u00e9soudre cela par des r\u00e9glages, afin que cela reste ainsi \u00e0 l'avenir. Cela signifie que l'utilisation est faible, mais que nous \u00e9crivons quand m\u00eame quelque chose ici. <\/p>\n
<\/p>\n
Que faut-il faire pour r\u00e9soudre ce probl\u00e8me ? Si vous avez arr\u00eat\u00e9 les IO sous la base de donn\u00e9es, cela signifie que tous les utilisateurs qui essaient d'ex\u00e9cuter leurs requ\u00eates devront attendre. <\/p>\n
<\/p>\n
<\/p>\n
Si l'on examine cela du point de vue de Linux, si vous avez un bon mat\u00e9riel, que vous l'avez correctement configur\u00e9, et que vous avez bien r\u00e9gl\u00e9 PostgreSQL pour qu'il r\u00e9alise ces checkpoints moins fr\u00e9quemment, en les r\u00e9partissant dans le temps, vous tombez sur les param\u00e8tres par d\u00e9faut de Debian. Pour la plupart des distributions Linux, voici les valeurs typiques : vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Qu'est-ce que cela signifie ? \u00c0 partir du noyau 2.6, un d\u00e9mon de vidage est apparu, appel\u00e9 pdflush, en fonction de ce qui est utilis\u00e9, qui s'occupe de l'\u00e9jection des pages sales du buffer du noyau en arri\u00e8re-plan et de leur vidage, peu importe les circonstances, lorsque le vidage en arri\u00e8re-plan ne suffit pas. <\/p>\n
<\/p>\n
Quand se produit le vidage en arri\u00e8re-plan ? Lorsque 10 % de la m\u00e9moire vive totale du serveur est occup\u00e9e par des pages sales dans le buffer du noyau, une fonction sp\u00e9ciale est appel\u00e9e pour effectuer le vidage en arri\u00e8re-plan. Pourquoi est-elle en arri\u00e8re-plan ? Elle prend comme param\u00e8tre le nombre de pages \u00e0 vider. Elle peut, par exemple, vider N pages. Puis, pendant un certain temps, cet \u00e9l\u00e9ment se met en pause. Ensuite, il revient et vide un certain nombre de pages suppl\u00e9mentaires. <\/p>\n
<\/p>\n
C'est une histoire tr\u00e8s simple. C'est comme avec une piscine, lorsque quelque chose entre par un tuyau et sort par un autre. Notre checkpoint est arriv\u00e9, et s'il a envoy\u00e9 peu de pages sales pour le vidage, alors progressivement, le pgflush dans le buffer du noyau s'en d\u00e9barrassera \u00e9galement. <\/p>\n
<\/p>\n
Si ces pages sales continuent de s'accumuler, elles atteindront 20 %, apr\u00e8s quoi le syst\u00e8me d'exploitation priorisera l'\u00e9criture de ces donn\u00e9es sur le disque, car une coupure d'alimentation se produira, et tout ira mal pour nous. Nous perdrons ces donn\u00e9es, par exemple. <\/p>\n
<\/p>\n
Quelle est l'astuce ? L'astuce est que ces param\u00e8tres dans le monde moderne, 20 et 10 % de toute la m\u00e9moire vive de la machine, sont tout simplement monstrueux du point de vue de la bande passante de n'importe quelle syst\u00e8me de disque que vous avez.<\/strong> <\/p>\n<\/p>\n
Imaginez que vous avez 128 Go de m\u00e9moire vive. 12,8 Go se retrouvent dans votre syst\u00e8me de disque. Peu importe le cache que vous avez ou le tableau que vous utilisez, ils ne supporteront pas cela. <\/p>\n
<\/p>\n
<\/p>\n
C'est pourquoi nous recommandons de configurer ces chiffres imm\u00e9diatement en fonction des capacit\u00e9s de votre contr\u00f4leur RAID.<\/strong> J'ai ici une recommandation pour un contr\u00f4leur disposant de 512 Mo de cache. <\/p>\n<\/p>\n
Tout est tr\u00e8s simple. On peut d\u00e9finir vm.dirty_background en octets. Ces r\u00e9glages annulent les deux pr\u00e9c\u00e9dents. Soit le ratio par d\u00e9faut, soit ceux qui sont activ\u00e9s en octets fonctionneront. Mais en tant que consultant DBA travaillant avec diff\u00e9rents clients, j'essaie de prendre des pr\u00e9cautions, donc si c'est en octets, alors c'est en octets. Personne n'a garanti qu'un bon administrateur ne rajoutera pas de m\u00e9moire au serveur, ne le red\u00e9marrera pas, et que le chiffre restera le m\u00eame. Il suffit de calculer ces chiffres pour \u00eatre s\u00fbr que tout y rentre. <\/p>\n
<\/p>\n
Que se passe-t-il si vous ne rentrez pas ? Il est indiqu\u00e9 qu'un quelconque syst\u00e8me de flushing est effectivement arr\u00eat\u00e9, mais en r\u00e9alit\u00e9 c'est une figure de style. Le syst\u00e8me d'exploitation a un gros probl\u00e8me : il a beaucoup de pages sales, donc c'est l'IO g\u00e9n\u00e9r\u00e9 par vos clients qui est effectivement arr\u00eat\u00e9, c\u2019est-\u00e0-dire qu'une application SQL veut envoyer une requ\u00eate \u00e0 la base de donn\u00e9es, elle attend. Tout I\/O vers celle-ci a la plus basse priorit\u00e9, car la base est occup\u00e9e par le checkpoint. Et quand cela se terminera, est totalement incertain. Et quand vous atteignez le flushing non de fond, cela signifie que tout votre IO est occup\u00e9 par cela. Et tant que ce n'est pas termin\u00e9, vous ne pourrez rien faire. <\/p>\n
<\/p>\n
Il y a aussi deux points importants qui sortent du cadre de cette pr\u00e9sentation. Ces r\u00e9glages doivent correspondre aux r\u00e9glages dans postgresql.conf, c'est-\u00e0-dire les r\u00e9glages de checkpoints. Et votre syst\u00e8me de disque doit \u00eatre correctement configur\u00e9. Si vous avez un cache sur RAID, il doit \u00eatre \u00e9quip\u00e9 d'une batterie.<\/strong> Les gens ach\u00e8tent des RAID avec un bon cache sans batterie. Si vous avez des SSD en RAID, ils doivent \u00eatre serveur, et il doit y avoir des condensateurs.<\/strong> Voici une liste de contr\u00f4le d\u00e9taill\u00e9e. Ce lien contient mon rapport sur la mani\u00e8re de configurer la performance des disques dans PostgreSQL. Toutes ces listes de contr\u00f4le y figurent. <\/p>\n<\/p>\n
<\/p>\n
Qu'est-ce qui peut encore compliquer la vie ? Ce sont deux param\u00e8tres. Ils sont relativement nouveaux. Ils peuvent \u00eatre activ\u00e9s par d\u00e9faut dans diff\u00e9rentes applications. Et ils peuvent compliquer la vie tout autant s'ils sont mal configur\u00e9s. <\/p>\n
<\/p>\n
<\/p>\n
Il y a deux \u00e9l\u00e9ments relativement nouveaux. Ils apparaissent d\u00e9j\u00e0 dans les trois noyaux. C'est sched_migration_cost en nanosecondes et sched_autogroup_enabled, qui est un. <\/p>\n
<\/p>\n
Et comment cela complique-t-il la vie ? Qu'est-ce que sched_migration_cost ? Le planificateur de Linux peut migrer un processus d'un CPU \u00e0 un autre. Et pour PostgreSQL, qui ex\u00e9cute des requ\u00eates, la migration vers un autre CPU n'est pas certaine. Du point de vue du syst\u00e8me d'exploitation, lorsque vous basculez entre openoffice et le terminal, cela peut \u00eatre bon, mais pour une base de donn\u00e9es, c'est tr\u00e8s mauvais.<\/strong> Par cons\u00e9quent, une politique raisonnable consiste \u00e0 d\u00e9finir un migration_cost \u00e0 une valeur \u00e9lev\u00e9e, au moins plusieurs milliers de nanosecondes.<\/strong> <\/p>\n<\/p>\n
Que cela signifiera-t-il pour le planificateur ? Il consid\u00e8rera qu'au cours de ce temps, ce processus est toujours chaud. C'est-\u00e0-dire, si vous avez une longue transaction qui traite quelque chose, le planificateur va le comprendre. Il consid\u00e9rera que tant que ce d\u00e9lai n'est pas \u00e9coul\u00e9, il n'est pas n\u00e9cessaire de migrer ce processus. Si le processus effectue une t\u00e2che, il ne sera pas migr\u00e9 et continuera \u00e0 s'ex\u00e9cuter sur le CPU qui lui a \u00e9t\u00e9 attribu\u00e9. Et le r\u00e9sultat est excellent. <\/p>\n
<\/p>\n
Le deuxi\u00e8me point concerne autogroup. C'est une bonne id\u00e9e pour des charges de travail sp\u00e9cifiques qui n'ont rien \u00e0 voir avec les bases de donn\u00e9es modernes - regrouper les processus par terminal virtuel \u00e0 partir duquel ils ont \u00e9t\u00e9 lanc\u00e9s. C'est pratique pour certaines t\u00e2ches. En pratique, PostgreSQL est un syst\u00e8me multi-processus avec un m\u00e9canisme de pr\u00e9-allocation, qui se lance \u00e0 partir d'un terminal unique. Vous avez un verrou d'\u00e9criture, un point de contr\u00f4le, et toutes vos requ\u00eates clients sont regroup\u00e9es sur un seul planificateur, sur un seul CPU. Elles attendront alors d'\u00eatre lib\u00e9r\u00e9es, s'emp\u00eachant mutuellement de le monopoliser trop longtemps. Cette situation est compl\u00e8tement inappropri\u00e9e en cas de charge \u00e9lev\u00e9e, il est donc n\u00e9cessaire de la d\u00e9sactiver.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Mon coll\u00e8gue Alexe\u00ef Lesovski a effectu\u00e9 des tests avec un simple pgbench, augmentant l'ordre de grandeur du migration_cost et d\u00e9sactivant l'autogroup. La diff\u00e9rence sur du mat\u00e9riel de mauvaise qualit\u00e9 a atteint presque 10 %.<\/strong>Il y a une discussion dans la mailing list de Postgres o\u00f9 des utilisateurs partagent les r\u00e9sultats sur la fa\u00e7on dont de tels changements affectent la vitesse des requ\u00eates. Cela a eu un impact sur 50 %.<\/strong>De telles histoires sont assez fr\u00e9quentes.<\/p>\n<\/p>\n
<\/p>\n
Et enfin, parlons de la politique d'\u00e9conomie d'\u00e9nergie. Heureusement, Linux peut maintenant \u00eatre utilis\u00e9 sur un ordinateur portable. Il est cens\u00e9 \u00eatre efficace en termes de consommation d'\u00e9nergie. Mais il s'av\u00e8re soudainement que cela peut \u00e9galement \u00eatre appliqu\u00e9 sur un serveur. <\/p>\n
<\/p>\n
De plus, si vous louez des serveurs aupr\u00e8s d'un h\u00e9bergeur, ces derniers ne s'inqui\u00e8tent pas de vous assurer une meilleure performance. Leur objectif est de faire en sorte que leur mat\u00e9riel soit utilis\u00e9 de la mani\u00e8re la plus efficace possible. Par cons\u00e9quent, ils peuvent par d\u00e9faut activer le mode \u00e9conomie d'\u00e9nergie sur le syst\u00e8me d'exploitation. h\u00e9bergement<\/a> Si vous utilisez ce genre de configuration sur un serveur avec une base de donn\u00e9es sous une charge intensive, votre choix doit \u00eatre acpi_cpufreq + performance. M\u00eame avec ondemand, vous rencontrerez d\u00e9j\u00e0 des probl\u00e8mes.<\/p>\n<\/p>\n
Intel_pstate est un peu diff\u00e9rent comme pilote. Actuellement, la pr\u00e9f\u00e9rence va \u00e0 celui-ci, consid\u00e9r\u00e9 comme plus r\u00e9cent et mieux fonctionnant.<\/strong> <\/p>\n<\/p>\n
Par cons\u00e9quent, le gouverneur doit \u00eatre exclusivement performance. Ondemand, powersave et tout le reste ne vous concernent pas.<\/p>\n
<\/p>\n
Les r\u00e9sultats d'un explain analyze sur PostgreSQL peuvent varier de plusieurs ordres de grandeur si vous activez powersave, car pratiquement, le CPU sera planifi\u00e9 de mani\u00e8re totalement impr\u00e9visible sous votre base. <\/p>\n
<\/p>\n
Ces r\u00e9glages peuvent \u00eatre activ\u00e9s par d\u00e9faut. Regardez attentivement si cela n'a pas \u00e9t\u00e9 activ\u00e9 par d\u00e9faut. Cela pourrait vraiment poser un gros probl\u00e8me.<\/p>\n
<\/p>\n
Ces param\u00e8tres pourraient \u00eatre activ\u00e9s par d\u00e9faut. V\u00e9rifiez attentivement qu'ils ne sont pas activ\u00e9s par d\u00e9faut. Cela pourrait r\u00e9ellement \u00eatre un gros probl\u00e8me. <\/p>\n
<\/p>\n
<\/p>\n
Et pour terminer, je tiens \u00e0 remercier les membres de notre \u00e9quipe DBA de PosgreSQL-Consulting, notamment Max Bogouk et Alexey Lesovsky, qui rencontrent des difficult\u00e9s chaque jour dans ce domaine. Pour nos clients, nous nous effor\u00e7ons de faire en sorte que tout fonctionne de mani\u00e8re optimale. C'est un peu comme les consignes de s\u00e9curit\u00e9 a\u00e9rienne. Tout y est \u00e9crit avec le sang. Chacun de ces boulons a \u00e9t\u00e9 d\u00e9couvert au cours de divers probl\u00e8mes. Je suis heureux de les partager avec vous.<\/p>\n
<\/p>\n
Questions :<\/p>\n
<\/p>\n
Merci ! Par exemple, si une entreprise souhaite \u00e9conomiser et h\u00e9berger \u00e0 la fois la base de donn\u00e9es et la logique applicative sur un m\u00eame serveur, ou si elle suit la tendance moderne des architectures microservices, o\u00f9 PostgreSQL est ex\u00e9cut\u00e9 dans un conteneur. Quel est le truc ? Les param\u00e8tres sysctl affectent globalement tout le noyau. Je n'ai jamais entendu dire que sysctl \u00e9tait virtualis\u00e9 de mani\u00e8re \u00e0 fonctionner s\u00e9par\u00e9ment dans un conteneur. Il n'y a que les cgroups et l\u00e0, il n'y a un contr\u00f4le que sur une partie. Comment peut-on vivre avec \u00e7a ? Ou si vous souhaitez des performances, lancez PostgreSQL sur un serveur physique distinct et configurez-le ?<\/em><\/p>\n<\/p>\n
Nous avons r\u00e9pondu \u00e0 votre question de trois mani\u00e8res diff\u00e9rentes. S'il ne s'agit pas d'un serveur physique que l'on peut configurer, d\u00e9tendez-vous, tout fonctionnera bien sans ces r\u00e9glages. Si vous \u00eates soumis \u00e0 une telle charge qu'il faille proc\u00e9der \u00e0 ces ajustements, vous passerez au serveur physique bien avant d'atteindre ces r\u00e9glages.<\/p>\n
<\/p>\n
Quel est le probl\u00e8me ? Si c'est une machine virtuelle, vous rencontrerez probablement de nombreux probl\u00e8mes, comme le fait qu'il y a une latence disque souvent incoh\u00e9rente sur la plupart des machines virtuelles. M\u00eame si la bande passante des disques est bonne, une seule transaction d'entr\u00e9e-sortie qui \u00e9choue, n'impactant pas beaucoup la bande passante moyenne, qui se produit au moment d'un checkpoint ou lors de l'\u00e9criture dans le WAL, peut gravement affecter la base de donn\u00e9es. Et vous remarquerez cela bien avant de vous heurter \u00e0 ces probl\u00e8mes. <\/p>\n
<\/p>\n
Si vous avez NGINX h\u00e9berg\u00e9 sur le m\u00eame serveur, vous rencontrerez le m\u00eame probl\u00e8me. Il se battra pour la m\u00e9moire partag\u00e9e. Et vous n'arriverez pas \u00e0 ces probl\u00e8mes d\u00e9crits ici.<\/p>\n
<\/p>\n
Cependant, d'un autre c\u00f4t\u00e9, certains de ces param\u00e8tres seront tout de m\u00eame pertinents pour vous. Par exemple, avec sysctl, d\u00e9finissez dirty_ratio pour qu'il ne soit pas aussi extr\u00eame - dans tous les cas, cela aidera. Quoi qu'il en soit, vous aurez des interactions avec le disque. Et cela se fera selon un sch\u00e9ma incorrect. Ces param\u00e8tres que j'ai montr\u00e9s sont par d\u00e9faut. De toute fa\u00e7on, il vaut mieux les modifier. <\/p>\n
<\/p>\n
Et il peut y avoir des probl\u00e8mes avec NUMA. VmWare, par exemple, fonctionne bien avec NUMA avec des param\u00e8tres exactement oppos\u00e9s. Il faut donc choisir \u2013 serveur physique ou non. <\/p>\n
<\/p>\n
J'ai une question concernant Amazon AWS. Ils ont des images pr\u00e9configur\u00e9es. L'une d'elles s'appelle Amazon RDS. Y a-t-il des param\u00e8tres personnalis\u00e9s pour leur syst\u00e8me d'exploitation ?<\/em><\/p>\n<\/p>\n
Il y a des param\u00e8tres, mais ce sont d'autres r\u00e9glages. Ici, nous configurons le syst\u00e8me d'exploitation en fonction de la mani\u00e8re dont la base de donn\u00e9es va l'utiliser. L\u00e0-bas, il existe des param\u00e8tres qui d\u00e9finissent la direction dans laquelle nous devons aller, un certain shaping. C'est-\u00e0-dire que nous avons besoin de ces ressources, nous allons les consommer maintenant. Apr\u00e8s cela, Amazon RDS attache ces ressources, et la performance chute. Il y a des r\u00e9cits o\u00f9 des gens commencent \u00e0 bidouiller cela. Parfois, m\u00eame avec un certain succ\u00e8s. Mais cela n'a rien \u00e0 voir avec les r\u00e9glages du syst\u00e8me d'exploitation. C'est un peu du hacking dans le cloud. C'est une autre histoire.<\/p>\n
<\/p>\n
Pourquoi les Transparent huge pages ne donnent-ils pas d'effet par rapport aux Huge TLB ?<\/em><\/p>\n<\/p>\n
Ils n'en donnent pas. Cela peut \u00eatre expliqu\u00e9 de plusieurs mani\u00e8res. Mais en fait, ils ne le font tout simplement pas. Quelle est l'histoire de PostgreSQL ? Lors de son d\u00e9marrage, il alloue un grand morceau de m\u00e9moire partag\u00e9e. Qu'ils soient transparents ou non \u2013 c'est compl\u00e8tement secondaire. Le fait qu'ils soient allou\u00e9s au d\u00e9marrage explique tout. Et si la m\u00e9moire est tr\u00e8s grande et qu'il faut r\u00e9organiser le segment shared_memory, alors Transparent huge pages sera pertinent. Avec PostgreSQL, il est simplement allou\u00e9 en un grand morceau au d\u00e9marrage et puis il ne se passe rien de particulier. On peut bien s\u00fbr les utiliser, mais il y a un risque d'obtenir une shared_memory corrompue lorsqu'il va r\u00e9allouer quelque chose. PostgreSQL n'en est pas conscient.<\/p>\n
Source : habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0420\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0434\u043e\u043a\u043b\u0430\u0434\u0430 2015 \u0433\u043e\u0434\u0430 \u0418\u043b\u044c\u0438 \u041a\u043e\u0441\u043c\u043e\u0434\u0435\u043c\u044c\u044f\u043d\u0441\u043a\u043e\u0433\u043e "Linux tuning to improve PostgreSQL performance" Disclaimer: \u0417\u0430\u043c\u0435\u0447\u0443 \u0447\u0442\u043e \u0434\u043e\u043a\u043b\u0430\u0434 \u044d\u0442\u043e\u0442 \u0434\u0430\u0442\u0438\u0440\u043e\u0432\u0430\u043d \u043d\u043e\u044f\u0431\u0440\u0435\u043c 2015 \u0433\u043e\u0434\u0430 \u2014 \u043f\u0440\u043e\u0448\u043b\u043e \u0431\u043e\u043b\u044c\u0448\u0435 4 \u043b\u0435\u0442 \u0438 \u043f\u0440\u043e\u0448\u043b\u043e \u043c\u043d\u043e\u0433\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u043c\u0430\u044f \u0432 \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0432\u0435\u0440\u0441\u0438\u044f 9.4 \u0443\u0436\u0435 \u043d\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442\u0441\u044f. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 4 \u0433\u043e\u0434\u0430 \u0432\u044b\u0448\u043b\u043e 5 \u043d\u043e\u0432\u044b\u0445 \u0440\u0435\u043b\u0438\u0437\u043e\u0432 PostgreSQL \u0432\u044b\u0448\u043b\u043e \u0438 15 \u0432\u0435\u0440\u0441\u0438\u0439 \u044f\u0434\u0440\u0430 Linux. \u0415\u0441\u043b\u0438 \u043f\u0435\u0440\u0435\u043f\u0438\u0441\u044b\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84083,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84082","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Optimisation](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n