Réglage Linux pour améliorer les performances de PostgreSQL. Ilya Kosmodemyansky

Transcription du rapport 2015 d'Ilya Kosmodemyansky « Réglage Linux pour améliorer les performances de PostgreSQL »

Avertissement : je note que ce rapport est daté de novembre 2015 - plus de 4 ans se sont écoulés et beaucoup de temps s'est écoulé. La version 9.4 évoquée dans le rapport n'est plus prise en charge. Au cours des 4 dernières années, 5 nouvelles versions de PostgreSQL ont été publiées et 15 versions du noyau Linux ont été publiées. Si vous réécrivez ces passages, vous vous retrouverez avec un rapport différent. Mais nous considérons ici le réglage fondamental de Linux pour PostgreSQL, qui est toujours d'actualité aujourd'hui.

Je m'appelle Ilya Kosmodemyansky. Je travaille chez PostgreSQL-Consulting. Et maintenant je vais parler un peu de ce qu'il faut faire avec Linux par rapport aux bases de données en général et PostgreSQL en particulier, car les principes sont assez similaires.

De quoi allons-nous parler ? Si vous communiquez avec PostgreSQL, vous devez dans une certaine mesure être un administrateur UNIX. Qu'est-ce que ça veut dire? Si nous comparons Oracle et PostgreSQL, alors dans Oracle, vous devez être 80 % administrateur de base de données DBA et 20 % administrateur Linux.

Avec PostgreSQL, c'est un peu plus compliqué. Avec PostgreSQL, vous devez mieux comprendre le fonctionnement de Linux. Et en même temps, courez un peu après la locomotive, car dernièrement, tout a été plutôt bien mis à jour. Et de nouveaux noyaux sont publiés, de nouvelles fonctionnalités apparaissent, les performances s'améliorent, etc.

Pourquoi parle-t-on de Linux ? Pas du tout parce que nous sommes à la conférence Linux Peter, mais parce que dans les conditions modernes, l'un des systèmes d'exploitation les plus justifiés pour utiliser les bases de données en général et PostgreSQL en particulier est Linux. Parce que FreeBSD évolue malheureusement dans une direction très étrange. Et il y aura des problèmes à la fois avec les performances et avec bien d’autres choses. Les performances de PostgreSQL sous Windows constituent généralement un problème sérieux distinct, basé sur le fait que Windows n'a pas la même mémoire partagée qu'UNIX, alors que PostgreSQL est entièrement lié à cela, car il s'agit d'un système multi-processus.

Et je pense que tout le monde est moins intéressé par les exotiques comme Solaris, alors allons-y.

Une distribution Linux moderne propose plus de 1 000 options syctl, selon la manière dont vous construisez le noyau. En même temps, si nous regardons les différents écrous, nous pouvons ajuster quelque chose de plusieurs manières. Il existe des paramètres du système de fichiers sur la façon de les monter. Si vous avez des questions sur comment le démarrer : que faut-il activer dans le BIOS, comment configurer le matériel, etc.

Il s'agit d'un très gros volume qui peut être discuté sur plusieurs jours, et non dans un court rapport, mais je vais maintenant me concentrer sur les choses importantes, comment éviter ces commissions qui sont garanties pour vous empêcher de bien utiliser votre base de données sous Linux si vous ne les corrigez pas. Et en même temps, un point important est que de nombreux paramètres par défaut ne sont pas inclus dans les paramètres corrects pour la base de données. Autrement dit, par défaut, cela fonctionnera mal ou pas du tout.

Quelles cibles de réglage traditionnelles existe-t-il sous Linux ? Je pense que puisque vous traitez tous de l'administration Linux, il n'est pas particulièrement nécessaire d'expliquer ce que sont les cibles.

Vous pouvez régler :

• CPU.
• Mémoire.
• Stockage.
• Autre. Nous en reparlerons à la fin pour une collation. Même, par exemple, des paramètres tels que la politique d'économie d'énergie peuvent affecter les performances de manière très imprévisible et pas des plus agréables.

Quelles sont les spécificités de PostgreSQL et de la base de données en général ? Le problème est qu’il est impossible de modifier n’importe quel écrou individuellement et de constater que nos performances se sont considérablement améliorées.

Oui, de tels gadgets existent, mais une base de données est une chose complexe. Il interagit avec toutes les ressources dont dispose le serveur et préfère interagir au maximum. Si vous regardez les recommandations actuelles d'Oracle sur la façon d'utiliser un système d'exploitation hôte, ce sera comme la blague sur ce cosmonaute mongol : nourrir le chien et ne toucher à rien. Donnons toutes les ressources à la base de données, la base de données elle-même réglera tout.

En principe, dans une certaine mesure, la situation est exactement la même avec PostgreSQL. La différence est que la base de données n'est pas encore capable de prendre toutes les ressources pour elle-même, c'est-à-dire quelque part au niveau Linux, vous devez tout régler vous-même.

L'idée principale n'est pas de sélectionner une seule cible et de commencer à la régler, par exemple la mémoire, le processeur ou quelque chose comme ça, mais d'analyser la charge de travail et d'essayer d'améliorer le débit autant que possible afin que la charge que les bons programmeurs l'ont créée pour nous, y compris nos utilisateurs.

Voici une photo pour expliquer de quoi il s'agit. Il existe un tampon du système d'exploitation Linux, une mémoire partagée et des tampons partagés PostgreSQL. PostgreSQL, contrairement à Oracle, fonctionne directement uniquement via le tampon du noyau, c'est-à-dire que pour qu'une page du disque entre dans sa mémoire partagée, elle doit passer par le tampon du noyau et revenir, exactement la même situation.

Les disques vivent sous ce système. J'ai dessiné cela sous forme de disques. En fait, il peut y avoir un contrôleur RAID, etc.

Et ces entrées-sorties se produisent d’une manière ou d’une autre à travers cette matière.

PostgreSQL est une base de données classique. Il y a une page à l'intérieur. Et toutes les entrées et sorties se font à l’aide de pages. Nous élevons des blocs en mémoire avec des pages. Et si rien ne se passe, on se contente de les lire, puis petit à petit ils disparaissent de ce cache, des buffers partagés et finissent à nouveau sur le disque.

Si nous remplaçons quelque chose quelque part, la page entière est marquée comme sale. Je les ai marqués ici en bleu. Et cela signifie que cette page doit être synchronisée avec le stockage en bloc. Autrement dit, lorsque nous l'avons sali, nous avons fait une entrée dans WAL. Et à un moment merveilleux, un phénomène appelé point de contrôle est survenu. Et l'information a été enregistrée dans ce journal selon laquelle il était arrivé. Et cela signifie que toutes les pages sales qui se trouvaient ici à ce moment-là dans ces tampons partagés ont été synchronisées avec le disque de stockage en utilisant fsync via le tampon du noyau.

Pourquoi cela est-il fait ? Si nous perdions la tension, nous n'obtiendrons pas la situation dans laquelle toutes les données seraient perdues. La mémoire persistante, dont tout le monde nous a parlé, est jusqu'à présent dans la théorie des bases de données - c'est un avenir brillant, pour lequel nous aspirons bien sûr et nous l'aimons, mais pour l'instant, ils vivent dans moins 20 ans. Et bien sûr, tout cela doit être surveillé.

Et la tâche de maximiser le débit consiste à affiner toutes ces étapes afin que tout se déplace rapidement. La mémoire partagée est essentiellement un cache de pages. Dans PostgreSQL, nous avons envoyé une requête de sélection ou quelque chose du genre, il a récupéré ces données du disque. Ils se sont retrouvés dans des tampons partagés. Par conséquent, pour que cela fonctionne mieux, il doit y avoir beaucoup de mémoire.

Pour que tout cela fonctionne bien et rapidement, vous devez configurer correctement le système d'exploitation à toutes les étapes. Et choisissez un matériel équilibré, car si vous avez un déséquilibre à un endroit, vous pouvez alors créer beaucoup de mémoire, mais elle ne sera pas entretenue à une vitesse suffisante.

Et passons en revue chacun de ces points.

Pour que ces pages circulent plus rapidement, vous devez réaliser les éléments suivants :

• Premièrement, vous devez travailler plus efficacement avec la mémoire.
• Deuxièmement, cette transition lorsque les pages de la mémoire vont vers le disque devrait être plus efficace.
• Et troisièmement, il doit y avoir de bons disques.

Si vous disposez de 512 Go de RAM sur le serveur et que tout cela se retrouve sur un disque dur SATA sans aucun cache, alors l'ensemble du serveur de base de données se transforme non seulement en une citrouille, mais en une citrouille avec une interface SATA. Vous y tomberez directement. Et rien ne vous sauvera.

Concernant le premier point concernant la mémoire, il y a trois choses qui peuvent rendre la vie très difficile.

Le premier d’entre eux est NUMA. NUMA est une chose conçue pour améliorer les performances. En fonction de la charge de travail, différentes choses peuvent être optimisées. Et dans sa nouvelle forme actuelle, ce n'est pas très bon pour les applications telles que les bases de données qui utilisent intensivement les tampons partagés du cache de pages.

En un mot. Comment savoir si quelque chose ne va pas avec NUMA ? Vous avez une sorte de coup désagréable, tout à coup un processeur est surchargé. En même temps, vous analysez les requêtes dans PostgreSQL et constatez qu'il n'y a rien de similaire. Ces requêtes ne devraient pas être aussi gourmandes en CPU. Vous pouvez attraper ça pendant longtemps. Il est plus facile d'utiliser la bonne recommandation dès le début sur la façon de configurer NUMA pour PostgreSQL.

Que se passe-t-il réellement ? NUMA signifie Accès à la mémoire non uniforme. À quoi ça sert? Vous disposez d'un processeur, à côté se trouve sa mémoire locale. Et ces interconnexions de mémoire peuvent extraire la mémoire d’autres processeurs.

Si tu cours numactl --hardware, alors vous obtiendrez une si grande feuille. Il y aura entre autres un champ de distances. Il y aura des chiffres - 10-20, quelque chose comme ça. Ces chiffres ne sont rien de plus que le nombre de sauts pour récupérer cette mémoire distante et l'utiliser localement. En principe, une bonne idée. Cela accélère considérablement les performances sous une gamme de charges de travail.

Imaginez maintenant que vous ayez un processeur essayant d'abord d'utiliser sa mémoire locale, puis essayant d'extraire une autre mémoire via une interconnexion pour quelque chose. Et ce processeur récupère l'intégralité de votre cache de pages PostgreSQL - c'est tout, quelques gigaoctets. Vous obtenez toujours le pire des cas, car sur le processeur, il y a généralement peu de mémoire dans ce module lui-même. Et toute la mémoire desservie passe par ces interconnexions. Cela s'avère lent et triste. Et votre processeur qui dessert ce nœud est constamment surchargé. Et le temps d'accès à cette mémoire est mauvais, lent. C'est la situation que vous ne souhaitez pas si vous l'utilisez pour une base de données.

Par conséquent, une option plus correcte pour la base de données serait que le système d'exploitation Linux ne sache pas du tout ce qui s'y passe. Pour qu’il accède à la mémoire comme il le fait.

Pourquoi donc? Il semblerait que ce soit l'inverse. Cela se produit pour une raison simple : nous avons besoin de beaucoup de mémoire pour le cache des pages - des dizaines, des centaines de gigaoctets.

Et si nous allouions tout cela et y mettons nos données en cache, alors le gain de l'utilisation du cache sera nettement supérieur au gain d'un accès aussi délicat à la mémoire. Et nous bénéficierons ainsi d'un bénéfice incomparable par rapport au fait que nous accéderons à la mémoire plus efficacement en utilisant NUMA.

Par conséquent, il existe actuellement deux approches, jusqu'à ce qu'un avenir radieux arrive et que la base de données elle-même ne soit pas en mesure de déterminer sur quels processeurs elle fonctionne et d'où elle doit extraire quelque chose.

Par conséquent, la bonne approche consiste à désactiver complètement NUMA., par exemple, lors du redémarrage. Dans la plupart des cas, les gains sont d'un tel ordre de grandeur que la question de savoir lequel est le meilleur ne se pose pas du tout.

Il existe une autre option. Nous l'utilisons plus souvent que le premier, car lorsqu'un client vient nous demander de l'aide, redémarrer le serveur est un gros problème pour lui. Il y a une entreprise. Et ils rencontrent des problèmes à cause de NUMA. Par conséquent, nous essayons de le désactiver de manière moins invasive que le redémarrage, mais veillez à vérifier qu'il est désactivé. Parce que, comme le montre l'expérience, c'est bien que nous désactivions NUMA sur le processus PostgreSQL parent, mais il n'est pas du tout nécessaire que cela fonctionne. Nous devons vérifier et voir qu'elle s'est vraiment éteinte.

Il y a un bon article de Robert Haas. C'est l'un des committers PostgreSQL. L'un des principaux développeurs de tous les abats de bas niveau. Et si vous suivez les liens de cet article, ils décrivent plusieurs histoires colorées sur la façon dont NUMA a rendu la vie difficile aux gens. Regardez, étudiez la liste de contrôle de l'administrateur système de ce qui doit être configuré sur le serveur pour que notre base de données fonctionne bien. Ces paramètres doivent être notés et vérifiés, sinon ce ne sera pas très bon.

Veuillez noter que cela s'applique à tous les paramètres dont je vais parler. Mais généralement, les bases de données sont collectées en mode maître-esclave pour la tolérance aux pannes. N'oubliez pas de faire ces réglages sur l'esclave car un jour vous aurez un accident et vous basculerez sur l'esclave et il deviendra le maître.

Dans une situation d'urgence, lorsque tout va très mal, que votre téléphone sonne constamment et que votre patron arrive en courant avec un gros bâton, vous n'aurez pas le temps de penser à vérifier. Et les résultats peuvent être assez désastreux.

Le point suivant concerne les pages énormes. Les pages volumineuses sont difficiles à tester séparément, et cela ne sert à rien, bien qu'il existe des benchmarks qui peuvent le faire. Ils sont faciles à rechercher sur Google.

À quoi ça sert? Vous disposez d'un serveur pas très cher avec beaucoup de RAM, par exemple plus de 30 Go. Vous n'utilisez pas de pages énormes. Cela signifie que vous avez certainement une surcharge en termes d'utilisation de la mémoire. Et ce surcoût est loin d’être des plus agréables.

Pourquoi donc? Alors que se passe-t-il? Le système d'exploitation alloue la mémoire par petits morceaux. C’est tellement pratique, c’est comme ça que ça s’est passé historiquement. Et si l’on rentre dans les détails, l’OS doit traduire les adresses virtuelles en adresses physiques. Et ce processus n'est pas le plus simple, donc le système d'exploitation met en cache le résultat de cette opération dans le Translation Lookaside Buffer (TLB).

Et comme le TLB est un cache, tous les problèmes inhérents à un cache se posent dans cette situation. Premièrement, si vous disposez de beaucoup de RAM et que tout est alloué en petits morceaux, alors ce tampon devient très volumineux. Et si le cache est volumineux, la recherche est plus lente. Les frais généraux sont sains et prennent eux-mêmes de l'espace, c'est-à-dire que la RAM est consommée par quelque chose d'incorrect. Cette fois.

Deuxièmement, plus le cache s'agrandit dans une telle situation, plus il est probable que vous ayez des échecs de cache. Et l’efficacité de ce cache diminue rapidement à mesure que sa taille augmente. Par conséquent, les systèmes d’exploitation ont proposé une approche simple. Il est utilisé sous Linux depuis longtemps. Il est apparu dans FreeBSD il n'y a pas si longtemps. Mais nous parlons de Linux. Ce sont des pages énormes.

Et ici, il convient de noter que les pages énormes, en tant qu'idée, ont été initialement poussées par des communautés comprenant Oracle et IBM, c'est-à-dire que les fabricants de bases de données pensaient fermement que cela serait également utile pour les bases de données.

Et comment peut-on lier cela à PostgreSQL ? Premièrement, les pages volumineuses doivent être activées dans le noyau Linux.

Deuxièmement, ils doivent être explicitement spécifiés par le paramètre sysctl - combien il y en a. Les numéros ici proviennent d'un ancien serveur. Vous pouvez calculer le nombre de tampons partagés dont vous disposez afin que des pages volumineuses puissent y tenir.

Et si l'intégralité de votre serveur est dédiée à PostgreSQL, alors un bon point de départ est d'allouer soit 25 % de la RAM aux tampons partagés, soit 75 % si vous êtes sûr que votre base de données rentrera définitivement dans ces 75 %. Premier point de départ. Et considérez que si vous disposez de 256 Go de RAM, vous disposerez en conséquence de 64 Go de gros tampons. Calculez approximativement avec une certaine marge - à quoi ce chiffre devrait être fixé.

Avant la version 9.2 (si je ne me trompe pas, depuis la version 8.2), il était possible de connecter PostgreSQL avec des pages volumineuses à l'aide d'une bibliothèque tierce. Et cela devrait toujours être fait. Tout d'abord, vous avez besoin que le noyau soit capable d'allouer correctement des pages volumineuses. Et, deuxièmement, pour que l'application qui fonctionne avec eux puisse les utiliser. Il ne sera pas utilisé uniquement de cette façon. Puisque PostgreSQL a alloué de la mémoire dans le style système 5, cela pourrait être fait en utilisant libhugetlbfs - c'est le nom complet de la bibliothèque.

Dans la version 9.3, les performances de PostgreSQL ont été améliorées lors du travail avec la mémoire et la méthode d'allocation de mémoire du système 5 a été abandonnée. Tout le monde était très content, car sinon, vous essayez d'exécuter deux instances PostgreSQL sur une seule machine, et il dit que je n'ai pas assez de mémoire partagée. Et il dit que sysctl doit être corrigé. Et il existe un tel système qu'il faut encore redémarrer, etc. En général, tout le monde était content. Mais l'allocation de mémoire mmap a interrompu l'utilisation de pages volumineuses. La plupart de nos clients utilisent de grands tampons partagés. Et nous avons fortement déconseillé de passer à la version 9.3, car là, les frais généraux ont commencé à être calculés en bons pourcentages.

Mais la communauté a prêté attention à ce problème et dans la version 9.4, elle a très bien retravaillé cet événement. Et dans la version 9.4, un paramètre est apparu dans postgresql.conf dans lequel vous pouvez activer try, on ou off.

Essayer est l’option la plus sûre. Lorsque PostgreSQL démarre, lorsqu'il alloue de la mémoire partagée, il essaie de récupérer cette mémoire sur les pages volumineuses. Et si cela ne fonctionne pas, la sélection normale revient. Et si vous avez FreeBSD ou Solaris, vous pouvez essayer, c'est toujours sûr.

Si cette option est activée, il ne démarre tout simplement pas s'il ne parvient pas à sélectionner parmi les pages volumineuses. Ici, il s’agit déjà de savoir qui et quoi est le plus gentil. Mais si vous avez essayé, vérifiez que vous avez vraiment mis en évidence ce dont vous avez besoin, car il y a beaucoup de place à l'erreur. Actuellement, cette fonctionnalité ne fonctionne que sous Linux.

Encore une petite note avant d'aller plus loin. Les énormes pages transparentes ne concernent pas encore PostgreSQL. Il ne peut pas les utiliser normalement. Et avec des pages transparentes énormes pour une telle charge de travail, lorsqu'une grande partie de la mémoire partagée est nécessaire, les avantages ne viennent qu'avec de très gros volumes. Si vous disposez de téraoctets de mémoire, cela peut entrer en jeu. Si nous parlons d'applications plus quotidiennes, lorsque vous disposez de 32, 64, 128, 256 Go de mémoire sur votre machine, alors les pages énormes habituelles sont OK, et nous désactivons simplement Transparent.

Et la dernière chose à propos de la mémoire n'est pas directement liée au fruit, elle peut vraiment gâcher votre vie. L'ensemble du débit sera grandement affecté par le fait que le serveur change constamment.

Et cela sera très désagréable à bien des égards. Et le principal problème est que les noyaux modernes se comportent légèrement différemment des anciens noyaux Linux. Et c'est assez désagréable de marcher sur cette chose, car quand on parle d'une sorte de travail avec swap, cela se termine par l'arrivée intempestive du OOM-killer. Et le tueur de MOO, qui n'est pas arrivé à temps et a abandonné PostgreSQL, est désagréable. Tout le monde le saura, c'est-à-dire jusqu'au dernier utilisateur.

Ce qui se passe? Vous y disposez d'une grande quantité de RAM, tout fonctionne bien. Mais pour une raison quelconque, le serveur se bloque lors du swap et ralentit à cause de cela. Il semblerait qu'il y ait beaucoup de mémoire, mais cela arrive.

Auparavant, nous conseillions de définir vm.swappiness sur zéro, c'est-à-dire de désactiver le swap. Auparavant, il semblait que 32 Go de RAM et les tampons partagés correspondants représentaient une quantité énorme. Le but principal de l'échange est d'avoir un endroit pour jeter la croûte si nous tombons. Et ce n'était plus particulièrement épanouissant. Et puis qu'est-ce que tu vas faire de cette croûte ? Il s’agit d’une tâche pour laquelle il n’est pas très clair pourquoi un échange est nécessaire, surtout d’une telle taille.

Mais dans les versions plus modernes, c'est-à-dire les troisièmes versions du noyau, le comportement a changé. Et si vous définissez le swap sur zéro, c'est-à-dire le désactivez, alors tôt ou tard, même s'il reste de la RAM, un tueur de MOO viendra à vous pour tuer les consommateurs les plus intensifs. Parce qu'il considérera qu'avec une telle charge de travail, il nous reste encore un peu de travail et nous sauterons dessus, c'est-à-dire non pas pour définir le processus du système, mais pour définir quelque chose de moins important. Ce moins important sera le consommateur intensif de mémoire partagée, à savoir le maître de poste. Et après cela, ce serait bien si la base n'avait pas besoin d'être restaurée.

Par conséquent, si je me souviens bien, la valeur par défaut est désormais la plupart des distributions autour de 6, c'est-à-dire à quel moment devriez-vous commencer à utiliser le swap en fonction de la quantité de mémoire restante. Nous recommandons maintenant de définir vm.swappiness = 1, car cela le désactive pratiquement, mais ne donne pas les mêmes effets qu'avec un OOM-killer qui est arrivé de manière inattendue et a tout tué.

Et après? Quand on parle de performances des bases de données et qu’on s’oriente progressivement vers les disques, tout le monde commence à se prendre la tête. Parce que la vérité selon laquelle le disque est lent et la mémoire rapide est familière à tout le monde depuis l'enfance. Et tout le monde sait que la base de données aura des problèmes de performances de disque.

Le principal problème de performances de PostgreSQL associé aux pics de points de contrôle ne se produit pas car le disque est lent. Cela est probablement dû au fait que la mémoire et la bande passante du disque ne sont pas équilibrées. Cependant, ils peuvent ne pas être équilibrés à différents endroits. PostgreSQL n'est pas configuré, le système d'exploitation n'est pas configuré, le matériel n'est pas configuré et le matériel est incorrect. Et ce problème ne se produit pas seulement si tout se passe comme il se doit, c'est-à-dire soit s'il n'y a pas de charge, soit si les paramètres et le matériel sont bien sélectionnés.

Qu'est-ce que c'est et à quoi ça ressemble ? Habituellement, les personnes qui travaillent avec PostgreSQL se sont penchées sur cette question plus d'une fois. Je vais t'expliquer. Comme je l'ai dit, PostgreSQL effectue périodiquement des points de contrôle pour vider les pages sales de la mémoire partagée sur le disque. Si nous disposons d'une grande quantité de mémoire partagée, le point de contrôle commence à avoir un impact intense sur le disque, car il vide ces pages avec fsync. Il arrive dans le tampon du noyau et est écrit sur les disques à l'aide de fsync. Et si le volume de cette activité est important, alors on peut observer un effet désagréable, à savoir une très grande utilisation des disques.

Ici, j'ai deux photos. Je vais maintenant expliquer ce que c'est. Ce sont deux graphiques corrélés dans le temps. Le premier graphique est l'utilisation du disque. Ici, il atteint actuellement près de 90 %. Si vous rencontrez une panne de base de données avec des disques physiques, avec une utilisation du contrôleur RAID à 90 %, alors c'est une mauvaise nouvelle. Cela signifie qu'un peu plus et il atteindra 100 et les E/S s'arrêteront.

Si vous disposez d’une baie de disques, c’est une histoire légèrement différente. Cela dépend de la façon dont il est configuré, de quel type de baie il s'agit, etc.

Et en parallèle, un graphique de la vue interne de Postgres est configuré ici, qui indique comment le point de contrôle se produit. Et la couleur verte ici montre combien de tampons, ces pages sales, sont arrivées à ce moment-là à ce point de contrôle pour la synchronisation. Et c’est la principale chose que vous devez savoir ici. Nous voyons que nous avons beaucoup de pages ici et à un moment donné nous atteignons le tableau, c'est-à-dire que nous avons écrit et écrit, ici le système de disque est clairement très occupé. Et notre point de contrôle a un impact très fort sur le disque. Idéalement, la situation devrait ressembler davantage à ceci, c'est-à-dire que nous avons eu moins d'enregistrements ici. Et nous pouvons le corriger avec les paramètres pour que cela continue à être ainsi. Autrement dit, le recyclage est faible, mais quelque part nous écrivons quelque chose ici.

Que faut-il faire pour surmonter ce problème ? Si vous avez arrêté IO sous la base de données, cela signifie que tous les utilisateurs venus répondre à leurs demandes attendront.

Si vous regardez du point de vue de Linux, si vous avez pris du bon matériel, l'avez configuré correctement, configuré PostgreSQL normalement pour qu'il effectue ces points de contrôle moins souvent, les répartit dans le temps entre eux, alors vous entrez dans les paramètres Debian par défaut. Pour la plupart des distributions Linux, voici l'image : vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Qu'est-ce que ça veut dire? Un démon de rinçage est apparu à partir du noyau 2.6. Pdglush, selon qui utilise lequel, est engagé dans la suppression en arrière-plan des pages sales du tampon du noyau et dans la suppression lorsqu'il est nécessaire de supprimer les pages sales quoi qu'il arrive, lorsque la suppression en arrière-plan n'aide pas.

Quand vient le fond ? Lorsque 10 % de la RAM totale disponible sur le serveur est occupée par des pages sales dans le tampon du noyau, une fonction d'annulation spéciale est appelée en arrière-plan. Pourquoi est-ce un arrière-plan ? En tant que paramètre, il prend en compte le nombre de pages à radier. Et, disons, il efface N pages. Et pendant un moment, cette chose s'endort. Et puis elle revient et copie encore quelques pages.

C'est une histoire extrêmement simple. Le problème ici est comme dans le cas d’une piscine : lorsqu’elle se déverse dans un tuyau, elle s’écoule dans un autre. Notre point de contrôle est arrivé et s'il a envoyé quelques pages sales à supprimer, alors progressivement, tout sera soigneusement résolu à partir du tampon du noyau pgflush.

Si ces pages sales continuent à s'accumuler, elles s'accumulent jusqu'à 20 %, après quoi la priorité du système d'exploitation est d'écrire le tout sur le disque, car l'alimentation tombera en panne et tout ira mal pour nous. Nous perdrons ces données, par exemple.

C'est quoi le truc? Le truc, c'est que ces paramètres dans le monde moderne représentent 20 et 10 % de la RAM totale qui se trouve sur la machine, ils sont absolument monstrueux en termes de débit de n'importe quel système de disque dont vous disposez.

Imaginez que vous disposez de 128 Go de RAM. 12,8 Go arrivent dans votre système de disque. Et quel que soit le cache dont vous disposez, quelle que soit la baie dont vous disposez, ils ne dureront pas aussi longtemps.

Par conséquent, nous vous recommandons d'ajuster immédiatement ces chiffres en fonction des capacités de votre contrôleur RAID. J'ai immédiatement fait ici une recommandation pour un contrôleur doté de 512 Mo de cache.

Tout est considéré comme très simple. Vous pouvez mettre vm.dirty_background en octets. Et ces réglages annulent les deux précédents. Soit le ratio est par défaut, soit ceux avec des octets sont activés, alors ceux avec des octets fonctionneront. Mais comme je suis consultant DBA et que je travaille avec différents clients, j'essaie de tirer la paille et donc, si en octets, alors en octets. Personne n'a donné aucune garantie qu'un bon administrateur n'ajouterait pas plus de mémoire au serveur, ne le redémarrerait pas et que le chiffre resterait le même. Calculez simplement ces chiffres pour que tout y rentre avec une garantie.

Que se passe-t-il si vous n'êtes pas à votre place ? J'ai écrit que tout rinçage est effectivement stoppé, mais en fait c'est une figure de style. Le système d'exploitation a un gros problème - il a beaucoup de pages sales, donc les E/S générées par vos clients sont effectivement arrêtées, c'est-à-dire que l'application est venue envoyer une requête SQL à la base de données, elle attend. Toute entrée/sortie est de la priorité la plus basse, car la base de données est occupée par un point de contrôle. Et quand elle aura fini, on ne sait absolument pas. Et lorsque vous avez réalisé un vidage sans arrière-plan, cela signifie que toutes vos E/S sont occupées par celui-ci. Et jusqu'à la fin, vous ne ferez rien.

Il y a ici deux autres points importants qui dépassent la portée de ce rapport. Ces paramètres doivent correspondre aux paramètres de postgresql.conf, c'est-à-dire les paramètres des points de contrôle. Et votre système de disque doit être correctement configuré. Si vous disposez d'un cache sur un RAID, il doit alors disposer d'une batterie. Les gens achètent du RAID avec un bon cache sans batterie. Si vous avez des SSD en RAID, alors ils doivent être ceux du serveur, il doit y avoir des condensateurs. Voici une liste de contrôle détaillée. Ce lien contient mon rapport sur la façon de configurer un disque de performances dans PostgreSQL. Il y a toutes ces listes de contrôle là-bas.

Qu’est-ce qui peut rendre la vie très difficile ? Ce sont deux paramètres. Ils sont relativement nouveaux. Par défaut, ils peuvent être inclus dans différentes applications. Et ils peuvent rendre la vie tout aussi difficile s'ils ne sont pas allumés correctement.

Il y a deux choses relativement nouvelles. Ils sont déjà apparus dans les troisièmes noyaux. Il s'agit de sched_migration_cost en nanosecondes et de sched_autogroup_enabled, qui en est un par défaut.

Et comment gâchent-ils votre vie ? Qu'est-ce que sched_migration_cost ? Sous Linux, le planificateur peut migrer un processus d'un processeur à un autre. Et pour PostgreSQL, qui exécute des requêtes, la migration vers un autre CPU n'est absolument pas claire. Du point de vue du système d'exploitation, lorsque vous basculez Windows entre OpenOffice et Terminal, cela peut être une bonne chose, mais pour une base de données, c'est très mauvais. Par conséquent, une politique raisonnable consiste à définir migration_cost sur une valeur élevée, au moins plusieurs milliers de nanosecondes.

Qu'est-ce que cela signifie pour le planificateur ? On considérera que pendant ce temps le procédé est encore chaud. Autrement dit, si vous avez une transaction de longue durée qui fait quelque chose depuis longtemps, le planificateur le comprendra. Il supposera que jusqu'à ce que ce délai soit écoulé, il n'est pas nécessaire de migrer ce processus n'importe où. Si en même temps le processus fait quelque chose, il ne sera migré nulle part, il fonctionnera silencieusement sur le processeur qui lui a été alloué. Et le résultat est excellent.

Le deuxième point est l'autogroupe. Il existe une bonne idée pour les charges de travail spécifiques qui ne sont pas liées aux bases de données modernes : il s'agit de regrouper les processus en fonction du terminal virtuel à partir duquel ils sont lancés. C'est pratique pour certaines tâches. En pratique, PostgreSQL est un système multi-processus avec un préfork qui s'exécute à partir d'un seul terminal. Vous disposez d'un rédacteur de verrous, d'un point de contrôle et toutes vos demandes client seront regroupées dans un seul planificateur, par processeur. Et ils y attendront à l'unisson qu'il soit libre, pour s'immiscer les uns dans les autres et l'occuper plus longtemps. C'est une histoire qui est totalement inutile dans le cas d'une telle charge et qui doit donc être désactivée.

Mon collègue Alexey Lesovsky a fait des tests avec un simple pgbench, où il a augmenté le coût de migration d'un ordre de grandeur et a désactivé l'autogroupe. La différence sur un mauvais matériel était de près de 10 %. Il y a une discussion sur la liste de diffusion postgres où les gens donnent des résultats de changements similaires dans la vitesse des requêtes. influencé 50%. Il existe de nombreuses histoires de ce type.

Et enfin, sur la politique d'économie d'énergie. La bonne nouvelle est que Linux peut désormais être utilisé sur un ordinateur portable. Et cela épuisera soi-disant bien la batterie. Mais soudain, il s’avère que cela peut aussi se produire sur le serveur.

De plus, si vous louez des serveurs auprès d'un hébergeur, les « bons » hébergeurs ne se soucient pas de vos meilleures performances. Leur tâche est de veiller à ce que leur fer soit utilisé le plus efficacement possible. Par conséquent, par défaut, ils peuvent activer le mode d’économie d’énergie de l’ordinateur portable sur le système d’exploitation.

Si vous utilisez ce matériel sur un serveur avec une base de données sous forte charge, alors votre choix est acpi_cpufreq + permormance. Même avec la demande, il y aura des problèmes.

Intel_pstate est un pilote légèrement différent. Et maintenant, la préférence est donnée à celui-ci, car il est plus tardif et fonctionne mieux.

Et par conséquent, le gouverneur n’est qu’une performance. Ondemand, Power Save et tout le reste ne vous concernent pas.

Les résultats de l'analyse d'explication de PostgreSQL peuvent différer de plusieurs ordres de grandeur si vous activez la sauvegarde d'énergie, car pratiquement le processeur de votre base de données fonctionnera de manière complètement imprévisible.

Ces éléments peuvent être inclus par défaut. Regardez attentivement pour voir s'ils l'ont activé par défaut. Cela peut être un très gros problème.

Et à la fin, je voulais remercier les gars de notre équipe PosgreSQL-Consulting DBA, à savoir Max Boguk et Alexey Lesovsky, qui progressent chaque jour dans ce domaine. Et nous essayons de faire de notre mieux pour nos clients afin que tout fonctionne pour eux. C’est comme avec les consignes de sécurité aérienne. Ici, tout est écrit avec du sang. Chacune de ces noix se retrouve en train de résoudre une sorte de problème. Je suis heureux de les partager avec vous.

Questions:

Merci! Si, par exemple, une entreprise souhaite économiser de l'argent et placer la base de données et la logique d'application sur un seul serveur, ou si l'entreprise suit la tendance à la mode des architectures de microservices, dans lesquelles PostgreSQL s'exécute dans un conteneur. C'est quoi le truc? Sysctl affectera l'ensemble du noyau globalement. Je n'ai pas entendu parler de sysctls virtualisés d'une manière ou d'une autre afin qu'ils fonctionnent séparément sur un conteneur. Il n'y a qu'un groupe de contrôle et il n'y a qu'une partie du contrôle. Comment peux-tu vivre avec ça ? Ou si vous voulez des performances, exécutez PostgreSQL sur un serveur matériel distinct et réglez-le ?

Nous avons répondu à votre question de trois manières environ. Si nous ne parlons pas d'un serveur matériel pouvant être réglé, etc., alors détendez-vous, tout fonctionnera bien sans ces paramètres. Si vous avez une telle charge que vous devez effectuer ces paramètres, vous arriverez alors sur le serveur Iron plus tôt que ces paramètres.

Quel est le problème? S'il s'agit d'une machine virtuelle, vous rencontrerez probablement de nombreux problèmes, par exemple du fait que sur la plupart des machines virtuelles, la latence du disque est assez incohérente. Même si le débit du disque est bon, et qu'une transaction d'E/S ayant échoué n'affecte pas grandement le débit moyen survenu au moment du point de contrôle ou au moment de l'écriture dans WAL, la base de données en souffrira grandement. Et vous le remarquerez avant de rencontrer ces problèmes.

Si vous avez NGINX sur le même serveur, vous rencontrerez également le même problème. Il se battra pour la mémoire partagée. Et vous n’arriverez pas aux problèmes décrits ici.

Mais d’un autre côté, certains de ces paramètres resteront pertinents pour vous. Par exemple, définissez dirty_ratio avec sysctl pour que ce ne soit pas si fou - dans tous les cas, cela aidera. D'une manière ou d'une autre, vous aurez une interaction avec le disque. Et ce sera selon un mauvais modèle. Il s'agit généralement d'une valeur par défaut pour les paramètres que j'ai montrés. Et de toute façon il vaut mieux les changer.

Mais il peut y avoir des problèmes avec NUMA. VmWare, par exemple, fonctionne bien avec NUMA avec exactement les paramètres opposés. Et ici, vous devez choisir : un serveur en fer ou un serveur sans fer.

J'ai une question concernant Amazon AWS. Ils ont des images préconfigurées. L'un d'eux s'appelle Amazon RDS. Existe-t-il des paramètres personnalisés pour leur système d'exploitation ?

Il y a des paramètres là-bas, mais ce sont des paramètres différents. Ici, nous configurons le système d'exploitation en fonction de la manière dont la base de données utilisera cette chose. Et il y a des paramètres qui déterminent où nous devons aller maintenant, comme le façonnage. Autrement dit, nous avons besoin de tellement de ressources que nous allons maintenant les consommer. Après cela, Amazon RDS réduit ces ressources et les performances y chutent. Il existe des histoires individuelles sur la façon dont les gens commencent à se mêler de cette affaire. Parfois même avec beaucoup de succès. Mais cela n'a rien à voir avec les paramètres du système d'exploitation. C'est comme pirater le cloud. C'est une autre histoire.

Pourquoi les pages énormes transparentes n'ont-elles aucun effet par rapport à Huge TLB ?

Ne donnent pas. Cela peut s’expliquer de plusieurs manières. Mais en réalité, ils ne le donnent tout simplement pas. Quelle est l’histoire de PostgreSQL ? Au démarrage, il alloue une grande partie de la mémoire partagée. Qu’ils soient transparents ou non n’a aucune importance. Le fait qu’ils se démarquent au départ explique tout. Et s'il y a beaucoup de mémoire et que vous devez reconstruire le segment shared_memory, alors les énormes pages transparentes seront pertinentes. Dans PostgreSQL, il est simplement alloué en gros morceau au début et c'est tout, et ensuite rien de spécial ne se passe là-bas. Vous pouvez, bien sûr, l'utiliser, mais il existe un risque de corruption de shared_memory lors de la réallocation de quelque chose. PostgreSQL n'est pas au courant.

Source: habr.com