Server<\/a> und alles am Ende auf eine SATA-Festplatte ohne jeglichen Cache ankommt, dann verwandelt sich der gesamte Datenbankserver nicht nur in eine K\u00fcrbis, sondern in einen K\u00fcrbis mit SATA-Schnittstelle. Sie werden direkt an Ihre Grenzen sto\u00dfen. Und nichts wird Sie retten.<\/p>\n<\/p>\n
<\/p>\n
Was den ersten Punkt zum Thema Speicher betrifft, so gibt es drei Dinge, die das Leben erheblich erschweren k\u00f6nnen. <\/p>\n
<\/p>\n
Das erste ist NUMA. NUMA ist eine Technologie, die entwickelt wurde, um die Leistung zu verbessern. Je nach Arbeitslast k\u00f6nnen verschiedene Dinge optimiert werden. In seiner aktuellen Form ist es jedoch nicht besonders gut f\u00fcr Anwendungen wie Datenbanken geeignet, die intensiv den Page Cache und Shared Buffers nutzen. <\/p>\n
<\/p>\n
<\/p>\n
In kurzen Worten. Wie erkennt man, dass mit NUMA etwas nicht stimmt? Es gibt ein unangenehmes Ger\u00e4usch, pl\u00f6tzlich wird ein CPU \u00fcberlastet. Dabei analysieren Sie die Anfragen in PostgreSQL und sehen, dass dort nichts dergleichen zu finden ist. Diese Abfragen sollten den CPU nicht so intensiv beanspruchen. Es kann lange dauern, dies zu bemerken. Es ist einfacher, von Anfang an den richtigen Ratschlag zu nutzen, wie man NUMA f\u00fcr PostgreSQL konfiguriert.<\/p>\n
<\/p>\n
<\/p>\n
Was passiert tats\u00e4chlich? NUMA bedeutet Non-Uniform Memory Access. Worauf kommt es an? Sie haben einen CPU, neben dem befindet sich sein lokaler Speicher. Und dieser Speicher kann \u00fcber Interconnects auf den Speicher anderer CPUs zugreifen.<\/p>\n
<\/p>\n
Wenn Sie numactl --hardware<\/code>, ausf\u00fchren, erhalten Sie eine gro\u00dfe \u00dcbersicht. Unter anderem gibt es ein Feld f\u00fcr Distanzen. Dort werden Zahlen stehen \u2013 10-20, etwas in dieser Art. Diese Zahlen sind nichts anderes als die Anzahl der Hops, um diesen entfernten Speicher anzubinden und lokal zu nutzen. Im Grunde ist das eine gute Idee. Es verbessert die Leistung bei einer Reihe von Lasten erheblich.<\/p>\n<\/p>\n
Stellen Sie sich vor, ein CPU versucht zun\u00e4chst, seinen lokalen Speicher zu nutzen, und greift dann \u00fcber das Interconnect auf einen anderen Speicher zu. Und auf diesen CPU gelangt der gesamte Page-Cache von PostgreSQL \u2013 mehrere Gigabyte. In der Regel haben Sie immer den schlechtesten Fall, denn der CPU hat normalerweise wenig direkten Zugriff auf diesen Speichermodul. Der gesamte Speicher, der verwaltet wird, l\u00e4uft \u00fcber diese Interconnects. Das f\u00fchrt zu langsamen und unbefriedigenden Ergebnissen. Ihr Prozessor, der diesen Knoten betreut, ist st\u00e4ndig \u00fcberlastet. Die Zugriffszeit auf diesen Speicher ist schlecht und langsam. Das ist die Situation, die Sie vermeiden m\u00f6chten, wenn Sie dies f\u00fcr Datenbanken verwenden. <\/p>\n
<\/p>\n
Daher ist es besser, wenn das Betriebssystem Linux gar nicht wei\u00df, was dort vor sich geht. Es sollte den Speicher so ansprechen, wie es \u00fcblich ist. <\/p>\n
<\/p>\n
Warum ist das so? Es scheint, als sollte es anders sein. Der Grund ist einfach: Wir ben\u00f6tigen viel Speicher f\u00fcr den Page-Cache \u2013 Dutzende, Hundert Gigabyte. <\/p>\n
<\/p>\n
Wenn wir also all dies \u0432\u044b\u0434\u0435\u043b\u0438\u043b\u0438 und unsere Daten dort zwischengespeichert haben, wird der Nutzen der Nutzung des Caches deutlich gr\u00f6\u00dfer sein als der Vorteil einer so cleveren Speicheranprache. Dadurch werden wir im Vergleich dazu erheblich profitieren, dass wir den Speicher mit NUMA effektiver ansprechen.<\/p>\n
<\/p>\n
Deshalb gibt es im Moment zwei Ans\u00e4tze, w\u00e4hrend wir auf eine bessere Zukunft warten, in der die Datenbank selbst erkennen kann, auf welchen CPUs sie l\u00e4uft und woher sie etwas abrufen muss. <\/p>\n
<\/p>\n
<\/p>\n
Der korrekte Ansatz besteht also darin, NUMA insgesamt zu deaktivieren.<\/strong>, beispielsweise beim Neustart. In den meisten F\u00e4llen sind die Vorteile so erheblich, dass die Frage, wie es am besten gemacht wird, gar nicht aufkommt. <\/p>\n<\/p>\n
Es gibt eine andere Option. Wir nutzen sie h\u00e4ufiger als die erste, weil es f\u00fcr unsere Kunden, die Unterst\u00fctzung ben\u00f6tigen, ein gro\u00dfes Problem darstellt, den Server neu zu starten. Ihr Gesch\u00e4ft h\u00e4ngt davon ab. Sie haben da Schwierigkeiten mit NUMA. Daher versuchen wir, weniger invasive Methoden zu verwenden, um den Dienst zu beenden, als einen Reboot durchzuf\u00fchren, aber dabei muss man vorsichtig \u00fcberpr\u00fcfen, ob er tats\u00e4chlich beendet wurde. Denn wie die Erfahrung zeigt, es ist zwar gut, den \u00fcbergeordneten Prozess PostgreSQL NUMA zu stoppen, jedoch ist es keineswegs garantiert, dass dies funktioniert. Man muss \u00fcberpr\u00fcfen und sicherstellen, dass es tats\u00e4chlich gestoppt wurde. <\/p>\n
<\/p>\n
Es gibt einen informativen Beitrag von Robert Haas. Er ist einer der Committer von PostgreSQL und ein Schl\u00fcsselentwickler f\u00fcr alle grundlegenden Aspekte. Wenn man den Links in diesem Beitrag folgt, findet man einige interessante Geschichten dar\u00fcber, wie NUMA den Menschen das Leben erschwert hat. Schauen Sie sich die Checkliste f\u00fcr Systemadministratoren an, um die notwendigen Einstellungen auf dem Server vorzunehmen, damit unsere Datenbank gut funktioniert. Diese Einstellungen sollten dokumentiert und \u00fcberpr\u00fcft werden, denn andernfalls k\u00f6nnte es problematisch werden. <\/p>\n
<\/p>\n
Ich m\u00f6chte darauf hinweisen, dass dies alle Einstellungen betrifft, \u00fcber die ich sprechen werde. In der Regel werden Datenbanken im Master-Slave-Modus zur Ausfallsicherheit konfiguriert. Vergessen Sie nicht, diese Einstellungen auch auf dem Slave vorzunehmen, denn irgendwann werden Sie mit einem Ausfall konfrontiert werden, und dann wechseln Sie zum Slave, der zum Master wird. <\/p>\n
<\/p>\n
In einer Notfallsituation, in der alles schiefgeht, klingelt st\u00e4ndig das Telefon, und der Chef kommt mit einem gro\u00dfen Stock, bleibt Ihnen keine Zeit, um die Situation zu \u00fcberpr\u00fcfen. Die Ergebnisse k\u00f6nnen dann \u00e4u\u00dferst bedauerlich sein.<\/p>\n
<\/p>\n
<\/p>\n
Der n\u00e4chste Punkt sind die Huge Pages. Huge Pages sind schwer isoliert zu testen, und wirklich sinnvoll ist es auch nicht, obwohl es Benchmarks gibt, die das k\u00f6nnen. Diese lassen sich leicht googeln. <\/p>\n
<\/p>\n
Worin besteht der Sinn? Sie haben einen nicht besonders teuren Server mit viel RAM, zum Beispiel mehr als 30 GB. Sie verwenden keine Huge Pages. Das bedeutet, dass Sie unweigerlich einen Overhead bei der Nutzung des Speichers haben, und dieser Overhead ist alles andere als angenehm. <\/p>\n
<\/p>\n
<\/p>\n
Warum ist das so? Was passiert hier? Das Betriebssystem weist den Speicher in kleinen Bl\u00f6cken zu. So praktisch, so hat sich das historisch entwickelt. Und wenn man ins Detail geht, muss das OS virtuelle Adressen in physische umwandeln. Dieser Prozess ist nicht ganz einfach, weshalb das OS das Ergebnis dieser Operation im Translation Lookaside Buffer (TLB) zwischenspeichert.<\/p>\n
<\/p>\n
Da der TLB ein Cache ist, treten dabei die typischen Cache-Probleme auf. Erstens: Wenn Sie sehr viel Arbeitsspeicher haben und dieser in kleinen Bl\u00f6cken zugewiesen wird, wird dieser Buffer sehr gro\u00df. Und je gr\u00f6\u00dfer der Cache ist, desto langsamer wird die Suche darin. Der Overhead ist erheblich, und er verbraucht Speicherplatz, was bedeutet, dass der Arbeitsspeicher f\u00fcr etwas Unn\u00f6tiges verwendet wird. Das ist Punkt eins. <\/p>\n
<\/p>\n
Zweitens: Je gr\u00f6\u00dfer der Cache in dieser Situation wird, desto h\u00f6her ist die Wahrscheinlichkeit f\u00fcr Cache-Misses. Die Effizienz dieses Caches sinkt rapide mit zunehmender Gr\u00f6\u00dfe. Daher haben die Betriebssysteme einen einfachen Ansatz entwickelt. In Linux wird dieser bereits seit langem verwendet. In FreeBSD ist er erst k\u00fcrzlich eingef\u00fchrt worden. Aber wir sprechen hier \u00fcber Linux. Dies sind die Huge Pages.<\/p>\n
<\/p>\n
Es ist wichtig zu betonen, dass die Idee der Huge Pages urspr\u00fcnglich von Gemeinschaften wie Oracle und IBM vorangetrieben wurde, das hei\u00dft, dass Datenbankhersteller fest davon \u00fcberzeugt waren, dass dies auch f\u00fcr Datenbanken n\u00fctzlich ist. <\/p>\n
<\/p>\n
<\/p>\n
Und wie bringt man das mit PostgreSQL zusammen? Zun\u00e4chst m\u00fcssen Huge Pages im Linux-Kernel aktiviert sein.<\/p>\n
<\/p>\n
Zweitens m\u00fcssen sie explizit mit dem sysctl-Parameter angegeben werden \u2013 wie viele es sind. Die Zahlen stammen von einem \u00e4lteren Server. Sie k\u00f6nnen berechnen, wie viele Shared Buffers Sie ungef\u00e4hr haben, damit die Huge Pages dort hinein passen. <\/p>\n
<\/p>\n
Wenn der gesamte Server PostgreSQL zugewiesen ist, ist ein guter Ausgangspunkt, entweder 25 % des Arbeitsspeichers f\u00fcr die Shared Buffers zu reservieren oder 75 %, wenn Sie sicher sind, dass Ihre Datenbank problemlos in diese 75 % passt. Dies ist der erste Ausgangspunkt. Berechnen Sie, wenn Sie 256 GB RAM haben, dass Sie entsprechend 64 GB f\u00fcr die Shared Buffers verwenden sollten. Sch\u00e4tzen Sie etwas gro\u00dfz\u00fcgig \u2013 was diese Zahl sein sollte.<\/p>\n
<\/p>\n
Bis zur Version 9.2 (wenn ich mich nicht irre, ab Version 8.2) konnte man PostgreSQL mit Huge Pages \u00fcber eine Drittanbieter-Bibliothek integrieren. Das sollte immer gemacht werden. Erstens muss der Kernel in der Lage sein, Huge Pages korrekt zuzuweisen. Und zweitens muss die Anwendung, die damit arbeitet, sie auch nutzen k\u00f6nnen. Einfach so kann sie das nicht. Da PostgreSQL Speicher im System 5-Stil zugewiesen hat, konnte dies mit libhugetlbfs - das ist der vollst\u00e4ndige Name der Bibliothek - realisiert werden.<\/p>\n
<\/p>\n
In Version 9.3 wurde die Leistung von PostgreSQL bei der Speicherverwaltung verbessert und die System 5-Methode zur Speichereinteilung wurde verworfen. Alle waren sehr erfreut, denn sonst versucht man, zwei PostgreSQL-Instanzen auf einem Rechner zu starten, und es sagt, dass nicht genug Shared Memory vorhanden ist. Und es verlangt, dass man sysctl anpassen muss. Und der sysctl ist so beschaffen, dass man sich auch neu starten muss, usw. Insgesamt waren alle erleichtert. Aber die Speicherzuweisung \u00fcber mmap hat die Verwendung von Huge Pages gest\u00f6rt. Die meisten unserer Kunden nutzen gro\u00dfe Shared Buffers. Daher haben wir dringend empfohlen, nicht auf 9.3 umzusteigen, da der Overhead dort in ansehnlichen Prozentwerten zu zunehmen begann.<\/p>\n
<\/p>\n
Die Community hat jedoch auf dieses Problem reagiert und in Version 9.4 wurde diese Funktionalit\u00e4t erheblich \u00fcberarbeitet. In der Version 9.4 gibt es nun einen Parameter in postgresql.conf, mit dem Sie den try-Status auf on oder off setzen k\u00f6nnen.<\/p>\n
<\/p>\n
Try ist der sicherste Parameter. Beim Start von PostgreSQL, wenn der Shared Memory zugewiesen wird, versucht das System, den Speicher aus den Huge Pages zu verwenden. Wenn dies nicht gelingt, f\u00e4llt es auf die normale Zuweisung zur\u00fcck. Wenn Sie FreeBSD oder Solaris verwenden, k\u00f6nnen Sie try einstellen; das ist immer sicher. <\/p>\n
<\/p>\n
Wenn der Parameter auf on gesetzt ist, startet das System einfach nicht, wenn es nicht in der Lage ist, Speicher aus den Huge Pages zuzuweisen. Hier ist es eine Frage der individuellen Pr\u00e4ferenz. Wenn Sie jedoch try benutzen, \u00fcberpr\u00fcfen Sie, ob tats\u00e4chlich der ben\u00f6tigte Speicher zugewiesen wurde, da es viele M\u00f6glichkeiten f\u00fcr Fehler gibt. Momentan funktioniert diese Funktionalit\u00e4t nur auf Linux.<\/p>\n
<\/p>\n
Eine kleine Anmerkung, bevor wir weitermachen: Transparent Huge Pages sind f\u00fcr PostgreSQL bisher nicht geeignet. Er kann sie nicht richtig nutzen. Bei Transparent Huge Pages profitieren Sie nur bei extrem gro\u00dfen Arbeitsspeichern, wenn ein gro\u00dfer Teil des gemeinsamen Speichers ben\u00f6tigt wird. Wenn Sie Terabytes an RAM haben, k\u00f6nnte das eine Rolle spielen. Bei allt\u00e4glichen Anwendungen mit 32, 64, 128 oder 256 GB RAM auf der Maschine ist es besser, die normalen Huge Pages zu verwenden und die Transparenten einfach auszuschalten. <\/p>\n
<\/p>\n
<\/p>\n
Der letzte Punkt zur Speicherverwaltung ist nicht direkt mit dem Durchsatz verbunden, kann aber das Leben stark erschweren. Die gesamte Bandbreite leidet erheblich darunter, dass der Server st\u00e4ndig swappt. <\/p>\n
<\/p>\n
Und das wird in mehreren Momenten sehr unangenehm sein. Das Hauptproblem besteht darin, dass sich das Verhalten der modernen Kernel geringf\u00fcgig von \u00e4lteren Linux-Kernel unterscheidet. Das ist etwas, worauf man nicht gerne tritt, denn wenn wir \u00fcber die Arbeit mit Swap sprechen, endet das nicht mit einem rechtzeitigen Eingreifen des OOM-Killers. Und ein OOM-Killer, der nicht rechtzeitig kommt und PostgreSQL abschaltet, ist unangenehm. Das erfahren alle, das hei\u00dft, bis zum letzten Benutzer. <\/p>\n
<\/p>\n
<\/p>\n
Was passiert? Sie haben eine gro\u00dfe Menge RAM, alles funktioniert gut. Aber aus irgendeinem Grund h\u00e4ngt der Server im Swap und verz\u00f6gert sich dadurch. Es scheint viel Speicher vorhanden zu sein, aber so ist es eben. <\/p>\n
<\/p>\n
<\/p>\n
Fr\u00fcher haben wir empfohlen, vm.swappiness auf null zu setzen, das hei\u00dft, Swap zu deaktivieren. Fr\u00fcher schien es, dass 32 GB RAM und die entsprechenden Shared Buffers eine enorme Menge sind. Der Hauptzweck von Swap besteht darin, einen Platz zu haben, um Inhalte auszuschalten, wenn wir ausfallen. Und das wurde nicht mehr wirklich erf\u00fcllt. Und was macht man dann mit diesen Inhalten? Das ist eine Aufgabe, bei der es nicht wirklich klar ist, warum Swap ben\u00f6tigt wird, insbesondere in dieser Gr\u00f6\u00dfe. <\/p>\n
<\/p>\n
In den neueren, also den dritten Kernel-Versionen, hat sich das Verhalten ge\u00e4ndert. Wenn Sie den Swap auf null setzen, also deaktivieren, wird der OOM-Killer fr\u00fcher oder sp\u00e4ter selbst bei noch vorhandenem Arbeitsspeicher aktiviert, um die Prozesse mit dem h\u00f6chsten Ressourcenverbrauch zu beenden. Er geht davon aus, dass bei dieser Arbeitslast nur noch wenig verf\u00fcgbar ist und dass wir ausfallen k\u00f6nnten, d.h. er wird nicht systemwichtige Prozesse beenden, sondern etwas weniger Wichtiges. Dabei handelt es sich h\u00e4ufig um einen intensiven Verbraucher des Shared Memory, konkret um den Postmaster. Nach diesem Eingriff kann man froh sein, wenn die Datenbank nicht wiederhergestellt werden muss. <\/p>\n
<\/p>\n
Deshalb ist es meines Wissens nach momentan standardm\u00e4\u00dfig so, dass die meisten Distributionen bei etwa 6 liegen, also, ab wann man beginnen sollte, Swap zu verwenden, je nachdem, wie viel Arbeitsspeicher noch verf\u00fcgbar ist. Wir empfehlen jetzt, vm.swappiness = 1 einzustellen, da dies quasi die Nutzung von Swap deaktiviert, jedoch nicht die unangenehmen Effekte mit einem unerwartet auftretenden OOM-Killer bringt, die dann alles mit sich rei\u00dfen.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Was kommt als N\u00e4chstes? Wenn wir \u00fcber die Leistung von Datenbanken sprechen und uns allm\u00e4hlich den Datentr\u00e4gern n\u00e4hern, greifen alle sich an den Kopf. Denn die Wahrheit, dass Festplatten langsam und der Arbeitsspeicher schnell ist, ist jedem seit der Kindheit bekannt. Und jeder wei\u00df, dass es in Datenbanken Probleme mit der Festplattengeschwindigkeit geben wird.<\/p>\n
<\/p>\n
Das Hauptproblem mit der PostgreSQL-Leistung, das mit Checkpoint-Spitzen zusammenh\u00e4ngt, resultiert nicht daraus, dass die Festplatte langsam ist. Es liegt vielmehr daran, dass die Bandbreite von Arbeitsspeicher und Festplatte nicht ausgewogen ist. Diese Unausgewogenheit kann an verschiedenen Stellen auftreten. PostgreSQL ist nicht richtig konfiguriert, das Betriebssystem ist nicht optimiert, die Hardware ist ungeeignet oder nicht richtig eingestellt. Dieses Problem tritt nur dann nicht auf, wenn alles richtig l\u00e4uft, d.h. entweder keinerlei Last vorhanden ist oder die Konfiguration und Hardware gut ausgew\u00e4hlt sind. <\/p>\n
<\/p>\n
<\/p>\n
Was ist das und wie sieht es aus? Normalerweise sind es Menschen, die mit PostgreSQL arbeiten und \u00f6fter mit diesem Thema in Ber\u00fchrung kommen. Ich werde das erkl\u00e4ren. Wie bereits erw\u00e4hnt, f\u00fchrt PostgreSQL regelm\u00e4\u00dfig Checkpoints durch, um die schmutzigen Seiten im Shared Memory auf die Festplatte zu sichern. Wenn wir einen gro\u00dfen Umfang an Shared Memory haben, wirkt sich der Checkpoint intensiv auf die Festplatte aus, da er diese Seiten mit fsync sichert. Diese gelangen in den Kernel-Puffer und werden \u00fcber fsync auf die Festplatten geschrieben. Und wenn der Umfang gro\u00df ist, k\u00f6nnen wir einen unerfreulichen Effekt beobachten, n\u00e4mlich eine sehr hohe Auslastung der Festplatten.<\/p>\n
<\/p>\n
Hier habe ich zwei Bilder. Ich werde jetzt erkl\u00e4ren, was das ist. Es handelt sich um zwei zeitlich korrelierte Grafiken. Die erste Grafik zeigt die Festplattenschutz. Hier erreicht sie in diesem Moment fast 90 %. Wenn Ihre Datenbank mit physischen Festplatten und einem RAID-Controller eine Auslastung von fast 90 % hat, dann sind das schlechte Nachrichten. Das bedeutet, dass es nicht mehr lange dauern wird, bis es 100 % erreicht und der Ein- und Ausgabeprozess stoppt. <\/p>\n
<\/p>\n
Wenn Sie ein Festplattenspeichersystem haben, ist die Geschichte ein wenig anders. Es h\u00e4ngt davon ab, wie es konfiguriert ist, um welchen Typ von Array es sich handelt, usw. <\/p>\n
<\/p>\n
Parallel dazu wurde hier ein Zeitplan aus einer internen Postgres-Ansicht konfiguriert, die beschreibt, wie der Checkpoint erfolgt. In Gr\u00fcn wird angezeigt, wie viele Buffer, also diese \"schmutzigen\" Seiten, zu diesem Zeitpunkt in diesem Checkpoint zur Synchronisierung angekommen sind. Das ist das Wichtigste, was Sie hier wissen m\u00fcssen. Wir sehen, dass hier viele Seiten angekommen sind und irgendwann gesto\u00dfen sind, d.h. wir haben ununterbrochen geschrieben, und es ist offensichtlich, dass das Festplattensystem hier stark ausgelastet ist. Der Checkpoint hat erheblichen Einfluss auf die Disk-Performance. Ideal sollte die Situation eher so aussehen, dass wir weniger Schreibvorg\u00e4nge hatten. Mit den richtigen Einstellungen k\u00f6nnen wir dies beheben, um sicherzustellen, dass es zuk\u00fcnftig so bleibt. Das hei\u00dft, die Auslastung ist gering, aber irgendwo schreiben wir dennoch etwas. <\/p>\n
<\/p>\n
Was k\u00f6nnen Sie tun, um dieses Problem zu l\u00f6sen? Wenn Ihr IO unter der Datenbank steht, bedeutet das, dass alle Benutzer, die ihre Anfragen ausf\u00fchren m\u00f6chten, warten m\u00fcssen. <\/p>\n
<\/p>\n
<\/p>\n
Betrachtet man es aus der Perspektive von Linux, wenn Sie gute Hardware verwenden, sie richtig konfigurieren und PostgreSQL so einstellen, dass es die Checkpoints seltener erstellt, diese \u00fcber die Zeit verteilt, dann landen Sie bei den Standardparametern von Debian. F\u00fcr die meisten Linux-Distributionen sieht das folgenderma\u00dfen aus: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Was bedeutet das? Mit dem Kernel 2.6 wurde ein Daemon f\u00fcr das Flushing eingef\u00fchrt. Pdglush, abh\u00e4ngig davon, wer es nutzt, der sich um das Hintergrund-Entleeren von schmutzigen Seiten aus dem Kernel-Puffer k\u00fcmmert und das Entleeren erzwingt, wenn es unbedingt notwendig ist, um schmutzige Seiten zu entleeren, wenn das Hintergrund-Entleeren nicht mehr hilft. <\/p>\n
<\/p>\n
Wann tritt der Hintergrund ein? Wenn 10 % des gesamten Arbeitsspeichers, der auf dem Server vorhanden ist, mit schmutzigen Seiten im Kernel-Puffer belegt sind, wird eine spezielle Funktion zum Hintergrundschreiben aufgerufen. Warum ist sie im Hintergrund? Sie nimmt als Parameter an, wie viele Seiten geschrieben werden sollen. Und nehmen wir an, es werden N Seiten geschrieben. F\u00fcr eine gewisse Zeit schl\u00e4ft dieser Prozess dann und kommt sp\u00e4ter zur\u00fcck, um eine weitere Anzahl von Seiten zu schreiben. <\/p>\n
<\/p>\n
Es ist eine ganz einfache Geschichte. Man kann es mit einem Schwimmbecken vergleichen: Wenn in ein Rohr Wasser hineinflie\u00dft, flie\u00dft es in ein anderes wieder heraus. Wir haben einen Checkpoint erhalten und wenn nur wenige schmutzige Seiten zur Entsorgung gesendet wurden, wird sich dies nach und nach aus dem Kernel-Puffer pgflush elegant l\u00f6sen. <\/p>\n
<\/p>\n
Wenn diese schmutzigen Seiten weiter angesammelt werden, erreichen sie 20 %. Danach hat das Betriebssystem Priorit\u00e4t, diese auf die Festplatte zu schreiben, weil ein Stromausfall zu schlimmen Problemen f\u00fchren kann. Wir w\u00fcrden beispielsweise diese Daten verlieren. <\/p>\n
<\/p>\n
Was ist der Trick? Der Trick besteht darin, dass diese Werte in der modernen Welt, 20 % und 10 % des gesamten Arbeitsspeichers, der auf dem Rechner vorhanden ist, aus Sicht der Durchsatzkapazit\u00e4t jedes Disk-Systems, das Sie haben, v\u00f6llig absurd sind.<\/strong> <\/p>\n<\/p>\n
Stellen Sie sich vor, Sie haben 128 GB Arbeitsspeicher. 12,8 GB landen in Ihrem Speichersystem. Egal, welcher Cache oder welches Array Sie dort haben, sie k\u00f6nnen so viel nicht verarbeiten. <\/p>\n
<\/p>\n
<\/p>\n
Deshalb empfehlen wir, diese Werte gleich an die M\u00f6glichkeiten Ihres RAID-Controllers anzupassen.<\/strong> Hier gibt es sofort eine Empfehlung f\u00fcr einen Controller mit 512 MB Cache. <\/p>\n<\/p>\n
Es ist alles recht einfach. Man kann vm.dirty_background in Bytes festlegen. Diese Einstellungen heben die vorherigen beiden auf. Entweder wird das Verh\u00e4ltnis standardm\u00e4\u00dfig verwendet oder, wenn die in Bytes aktiv sind, dann gelten die in Bytes. Da ich jedoch DBA-Berater bin und mit verschiedenen Kunden arbeite, versuche ich, auf alles vorbereitet zu sein. Wenn es also in Bytes ist, dann in Bytes. Niemand hat eine Garantie gegeben, dass ein wohlwollender Administrator dem Server nicht etwas mehr RAM hinzuf\u00fcgt oder ihn neu startet, w\u00e4hrend die Zahlen gleich bleiben. Berechnen Sie einfach diese Zahlen, um sicherzustellen, dass alles problemlos passt. <\/p>\n
<\/p>\n
Was passiert, wenn Sie nicht eingreifen? Mir wurde gesagt, dass jegliches Flushing effektiv gestoppt wird, aber das ist eigentlich nur eine Redewendung. Das Betriebssystem hat ein gro\u00dfes Problem \u2013 es gibt viele schmutzige Seiten, weshalb letztendlich der IO effektiv gestoppt wird, den Ihre Kunden generieren. Das hei\u00dft, wenn eine App versucht, eine SQL-Anfrage an die Datenbank zu senden, wartet sie. Jeder IO-Vorgang hat die niedrigste Priorit\u00e4t, weil die Datenbank mit dem Checkpoint besch\u00e4ftigt ist. Und wann dieser abgeschlossen wird, ist v\u00f6llig unklar. Wenn Sie den nicht-background Flushing erreicht haben, bedeutet das, dass alle IO-Vorg\u00e4nge damit besch\u00e4ftigt sind. Und solange dies nicht abgeschlossen ist, k\u00f6nnen Sie nichts weiter machen. <\/p>\n
<\/p>\n
Es gibt hier noch zwei wichtige Punkte, die \u00fcber diesen Bericht hinausgehen. Diese Einstellungen sollten mit den Einstellungen in postgresql.conf \u00fcbereinstimmen, also mit den Einstellungen f\u00fcr Checkpoints. Und Ihr Speichersystem sollte entsprechend konfiguriert sein. Wenn Sie Cache auf RAID haben, sollte darauf eine Batterie vorhanden sein.<\/strong> Menschen kaufen RAID mit gutem Cache, aber ohne Batterie. Wenn Sie SSDs in RAID haben, sollten diese serverseitig sein und \u00fcber Kondensatoren verf\u00fcgen.<\/strong> Hier ist eine ausf\u00fchrliche Checkliste. \u00dcber diesen Link finden Sie meinen Bericht zur Konfiguration der Festplattenleistung in PostgreSQL. Alle diese Checklisten sind dort enthalten. <\/p>\n<\/p>\n
<\/p>\n
Was das Leben zus\u00e4tzlich erheblich komplizieren kann, sind zwei Parameter. Sie sind relativ neu. Standardm\u00e4\u00dfig k\u00f6nnen sie in verschiedenen Anwendungen aktiviert sein. Wenn sie jedoch falsch eingestellt sind, k\u00f6nnen sie das Leben nicht weniger erschweren. <\/p>\n
<\/p>\n
<\/p>\n
Es gibt zwei relativ neue Funktionen. Sie sind bereits in den dritten Versionen der Kerne vorhanden. Das sind sched_migration_cost in Nanosekunden und sched_autogroup_enabled, das standardm\u00e4\u00dfig auf 1 gesetzt ist. <\/p>\n
<\/p>\n
Und wie beeinflussen sie das Leben negativ? Was ist sched_migration_cost? Der Linux-Scheduler kann einen Prozess von einem CPU auf einen anderen migrieren. Und f\u00fcr PostgreSQL, das Abfragen ausf\u00fchrt, ist es v\u00f6llig unverst\u00e4ndlich, warum eine Migration auf einen anderen CPU stattfinden sollte. Aus Sicht des Betriebssystems ist es vielleicht sinnvoll, wenn Sie Fenster zwischen OpenOffice und dem Terminal wechseln, aber f\u00fcr eine Datenbank ist das \u00e4u\u00dferst nachteilig.<\/strong> Deshalb ist eine vern\u00fcnftige Richtlinie, den migration_cost auf einen hohen Wert zu setzen, mindestens mehrere Tausend Nanosekunden.<\/strong> <\/p>\n<\/p>\n
Was bedeutet das f\u00fcr den Scheduler? Er wird annehmen, dass dieser Prozess w\u00e4hrend dieser Zeit weiterhin aktiv ist. Das hei\u00dft, wenn Sie mit einer langwierigen Transaktion besch\u00e4ftigt sind, wird der Scheduler dies erkennen. Er wird also annehmen, dass dieser Prozess nicht migriert werden muss, solange der Timeout nicht abgelaufen ist. Wenn der Prozess etwas tut, wird er nicht migriert, sondern weiterhin auf der ihm zugewiesenen CPU arbeiten. Das Ergebnis ist ausgezeichnet. <\/p>\n
<\/p>\n
Ein zweiter Punkt ist das Autogrouping. Es gibt eine gute Idee f\u00fcr spezifische Workloads, die nichts mit modernen Datenbanken zu tun haben: Prozesse nach dem virtuellen Terminal zu gruppieren, von dem aus sie gestartet wurden. Das ist praktisch f\u00fcr bestimmte Aufgaben. In der Praxis ist PostgreSQL ein multiprozessuales System mit Prefork, das von einem einzigen Terminal aus gestartet wird. Sie haben einen Lock-Writer, Checkpoint und alle Ihre Client-Anfragen werden einem Scheduler und einer CPU zugeordnet. Sie werden dort gemeinsam darauf warten, dass der Scheduler frei wird, um sich gegenseitig nicht zu st\u00f6ren und ihn l\u00e4nger zu beanspruchen. Diese Vorgehensweise ist unter solch einer Last v\u00f6llig unn\u00f6tig und sollte daher deaktiviert werden.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Mein Kollege Alexey Lesovski hat Tests mit einem einfachen pgbench durchgef\u00fchrt, bei denen er den migration_cost um einen Faktor erh\u00f6ht und die Autogroup deaktiviert hat. Der Unterschied bei schlechter Hardware betrug fast 10 %.<\/strong>Es gibt eine Diskussion im Postgres-Forum, in der die Leute Ergebnisse pr\u00e4sentieren, wie solche \u00c4nderungen die Abfragegeschwindigkeit beeinflusst haben. Das hatte einen Einfluss von 50 %.<\/strong>Es gibt viele solche Geschichten.<\/p>\n<\/p>\n
<\/p>\n
Und zum Schluss noch etwas zur Energiesparpolitik. Es ist gut, dass man Linux jetzt auf Laptops verwenden kann, und es soll angeblich den Akku gut schonen. Aber \u00fcberraschenderweise kann das auch auf Servern der Fall sein. <\/p>\n
<\/p>\n
Dar\u00fcber hinaus, wenn Sie Server bei einem Hosting-Anbieter mieten, k\u00fcmmern sich die 'freundlichen' Hosting-Dienstleister<\/a> nicht darum, dass Sie eine bessere Leistung erhalten. Ihre Aufgabe ist es, die Hardware so effizient wie m\u00f6glich zu nutzen. Daher k\u00f6nnen sie standardm\u00e4\u00dfig im Betriebssystem den Laptop-Energiesparmodus aktivieren.<\/p>\n<\/p>\n
Wenn Sie auf einem Server mit einer stark belasteten Datenbank dieses System verwenden, sollten Sie acpi_cpufreq + performance w\u00e4hlen. Selbst mit ondemand werden bereits Probleme auftreten.<\/strong> <\/p>\n<\/p>\n
Intel_pstate \u2013 ist ein etwas anderer Treiber. Aktuell wird dieser bevorzugt, da er neuer und stabiler ist.<\/p>\n
<\/p>\n
Dementsprechend ist der Governor nur auf Performance eingestellt. Ondemand, powersave und \u00e4hnliche Optionen sind hier nicht relevant. <\/p>\n
<\/p>\n
Die Ergebnisse von explain analyze in PostgreSQL k\u00f6nnen sich um mehrere Gr\u00f6\u00dfenordnungen \u00e4ndern, wenn powersave aktiviert ist, da der CPU unter diesen Bedingungen auf unvorhersehbare Weise geplant wird.<\/p>\n
<\/p>\n
Diese Einstellungen k\u00f6nnen standardm\u00e4\u00dfig aktiviert sein. \u00dcberpr\u00fcfen Sie sorgf\u00e4ltig, ob sie nicht bereits standardm\u00e4\u00dfig eingeschaltet sind. Das k\u00f6nnte ein gro\u00dfes Problem darstellen. <\/p>\n
<\/p>\n
<\/p>\n
Zum Schluss m\u00f6chte ich mich bei unserem DBA-Team von PostgreSQL-Consulting bedanken, insbesondere bei Max Boguk und Alexey Lesovski, die t\u00e4glich Erfahrungen sammeln. Wir streben danach, unseren Kunden die bestm\u00f6gliche Performance zu bieten. Es ist wie bei den Sicherheitsanweisungen im Flugwesen \u2013 alles ist aus bitteren Erfahrungen heraus geschrieben. Jede dieser Schrauben wurde durch ein Problem erkannt. Ich teile diese Erkenntnisse gern mit Ihnen.<\/p>\n
<\/p>\n
Fragen:<\/p>\n
<\/p>\n
Danke! Wenn ein Unternehmen beispielsweise Kosten sparen m\u00f6chte und sowohl eine Datenbank als auch die Anwendungslogik auf einem Server betreiben will, oder wenn es dem modernen Trend zu Microservice-Architekturen folgt, in denen PostgreSQL in einem Container l\u00e4uft, was ist dann der Trick? Sysctl wirkt sich global auf den gesamten Kernel aus. Ich habe noch nie geh\u00f6rt, dass sysctl irgendwie virtualisiert wurden, sodass sie im Container getrennt funktionieren. Es gibt nur cgroups und dort gibt es nur eine teilweise Kontrolle. Wie kann man damit leben? Oder wenn Sie Leistung wollen, sollten Sie PostgreSQL auf einem dedizierten Server betreiben und es optimieren?<\/em><\/p>\n<\/p>\n
Wir haben Ihre Frage auf etwa drei Arten beantwortet. Wenn es sich nicht um einen dedizierten Server handelt, den man optimieren kann usw., dann entspannen Sie sich, es wird auch ohne diese Einstellungen gut laufen. Wenn die Last so hoch wird, dass diese Einstellungen n\u00f6tig sind, werden Sie fr\u00fcher zu einem dedizierten Server kommen, als zu diesen Einstellungen.<\/p>\n
<\/p>\n
Was ist das Problem? Wenn es sich um eine virtuelle Maschine handelt, werden Sie wahrscheinlich auf zahlreiche Probleme sto\u00dfen, wie beispielsweise inkonsistente Disklatenzen bei den meisten virtuellen Maschinen. Selbst wenn die Datentransfergeschwindigkeit gut ist, kann eine fehlerhafte Eingabe-\/Ausgabe-Transaktion, die die durchschnittliche Bandbreite nicht merklich beeinflusst, w\u00e4hrend eines Checkpoints oder beim Schreiben in das WAL erfolgen, was die Datenbank erheblich belasten wird. Und Sie werden dies fr\u00fcher bemerken, als Sie denken. <\/p>\n
<\/p>\n
Wenn Sie NGINX auf demselben Server betreiben, wird das gleiche Problem auftreten. Es wird um den gemeinsam genutzten Speicher konkurrieren. Und Sie werden nicht vor den beschriebenen Problemen sicher sein.<\/p>\n
<\/p>\n
Auf der anderen Seite werden einige dieser Parameter weiterhin f\u00fcr Sie relevant sein. Zum Beispiel sollten Sie mit sysctl den dirty_ratio einstellen, um extreme Werte zu vermeiden \u2013 das wird auf jeden Fall helfen. So oder so wird Ihre Interaktion mit der Disk stattfinden. Und das wird auf eine falsche Weise geschehen. Die Parameter, die ich gezeigt habe, sind Standardwerte. In jedem Fall ist es besser, diese zu \u00e4ndern. <\/p>\n
<\/p>\n
Mit NUMA k\u00f6nnen Probleme auftreten. VmWare funktioniert beispielsweise gut mit NUMA bei genau entgegengesetzten Einstellungen. Hier muss man zwischen einem physischen Server und einem virtuellen Server w\u00e4hlen. <\/p>\n
<\/p>\n
Ich habe eine Frage zu Amazon AWS. Sie haben vorinstallierte Images. Eines davon hei\u00dft Amazon RDS. Gibt es dort irgendwelche benutzerdefinierten Einstellungen f\u00fcr deren Betriebssystem?<\/em><\/p>\n<\/p>\n
Es gibt Einstellungen, aber es sind andere Einstellungen. Hier konfigurieren wir das Betriebssystem in Bezug darauf, wie die Datenbank es nutzen wird. Dort gibt es Parameter, die bestimmen, in welche Richtung wir jetzt gehen, diese Art von Shaping. Das hei\u00dft, wir ben\u00f6tigen so viele Ressourcen, die werden wir jetzt aussch\u00f6pfen. Danach passt Amazon RDS diese Ressourcen an, und die Leistung sinkt. Es gibt verschiedene Geschichten dar\u00fcber, wie Leute mit diesem Thema experimentieren. Manchmal sogar recht erfolgreich. Aber das hat nichts mit den Betriebssystemeinstellungen zu tun. Es ist eher wie Cloud-Hacking. Das ist eine andere Geschichte.<\/p>\n
<\/p>\n
Warum bringen transparente gro\u00dfe Seiten keinen Effekt im Vergleich zu gro\u00dfen TLB?<\/em><\/p>\n<\/p>\n
Sie geben es nicht. Das kann man auf viele Arten erkl\u00e4ren, aber letztendlich geben sie es einfach nicht. Was ist die Geschichte von PostgreSQL? Beim Start weist es ein gro\u00dfes St\u00fcck Shared Memory zu. Ob dies transparent ist oder nicht, spielt keine Rolle. Die Tatsache, dass Speicher zu Beginn zugewiesen wird, erkl\u00e4rt alles. Wenn viel Speicher vorhanden ist und der Shared Memory-Segment neu aufgebaut werden muss, sind transparente gro\u00dfe Seiten relevant. In PostgreSQL ist es einfach beim Start in einem gro\u00dfen St\u00fcck zugewiesen, und dann passiert nichts Besonderes mehr. Nat\u00fcrlich k\u00f6nnte man es verwenden, aber es besteht die Gefahr, dass der Shared Memory besch\u00e4digt wird, wenn es wieder zugewiesen wird. PostgreSQL wei\u00df dar\u00fcber jedoch nichts.<\/p>\n
Quelle: 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
![\"Linux-Optimierung](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n