Server<\/a> und das alles am Ende auf eine SATA-Festplatte ohne Cache ankommt, verwandelt sich der gesamte Datenbankserver nicht nur in einen K\u00fcrbis, sondern in einen K\u00fcrbis mit SATA-Schnittstelle. Sie werden direkt darauf sto\u00dfen. Nichts wird Sie retten.<\/p>\n<\/p>\n
<\/p>\n
Was den ersten Punkt \u00fcber den Arbeitsspeicher betrifft, so gibt es drei Dinge, die das Leben erheblich erschweren k\u00f6nnen. <\/p>\n
<\/p>\n
Das erste ist NUMA. NUMA ist ein Konzept, das entwickelt wurde, um die Leistung zu verbessern. Je nach Arbeitslast k\u00f6nnen verschiedene Dinge optimiert werden. In ihrer aktuellen Form ist sie f\u00fcr Anwendungen wie Datenbanken, die intensiv gemeinsam genutzte Seiten Caches verwenden, nicht sehr gut. <\/p>\n
<\/p>\n
<\/p>\n
Kurz gesagt. Wie erkennt man, dass mit NUMA etwas nicht stimmt? Sie haben ein unangenehmes Ger\u00e4usch, pl\u00f6tzlich ist eine CPU \u00fcberlastet. Gleichzeitig analysieren Sie die Anfragen in PostgreSQL und sehen, dass dort nichts \u00c4hnliches ist. Diese Anfragen sollten die CPU nicht so intensiv beanspruchen. Es kann lange dauern, dies zu erkennen. Am besten verwenden Sie von Anfang an die richtige Empfehlung zur Einrichtung von NUMA f\u00fcr PostgreSQL.<\/p>\n
<\/p>\n
<\/p>\n
Was passiert wirklich? NUMA steht f\u00fcr Non-Uniform Memory Access. Worauf basiert das? Sie haben eine CPU, daneben ist deren lokaler Speicher. Und dieser Interconnects-Speicher kann Speicher von anderen CPUs abrufen.<\/p>\n
<\/p>\n
Wenn Sie ausf\u00fchren numactl --hardware<\/code>, erhalten Sie eine gro\u00dfe Ausgabe. Unter anderem wird es ein Feld mit Distanzen geben. Dort finden Sie Zahlen \u2013 10-20, etwas in dieser Art. Diese Zahlen sind nichts anderes als die Anzahl der Hops, um diesen entfernten Speicher anzuschlie\u00dfen und lokal zu nutzen. Im Prinzip ist das eine gute Idee. Es beschleunigt die Leistung bei bestimmten Lasten erheblich.<\/p>\n<\/p>\n
Stellen Sie sich jetzt vor, Sie haben eine CPU, die zun\u00e4chst versucht, ihren lokalen Speicher zu nutzen, um dann \u00fcber das Interconnect einen anderen Speicher f\u00fcr etwas zu abrufen. Und auf diese CPU gelangt der gesamte Page Cache von PostgreSQL \u2013 alles, was da sind k\u00f6nnte, einige Gigabyte. Sie erhalten immer den schlechtesten Fall, weil in diesem Modul der Arbeitsspeicher normalerweise wenig Platz hat. Und der gesamte Speicher, der verwaltet wird, l\u00e4uft \u00fcber diese Interconnects. Das wird langsam und frustrierend. Und Sie haben einen Prozessor, der diesen Knoten versorgt, der st\u00e4ndig \u00fcberlastet ist. Und die Zugriffszeit auf diesen Speicher ist schlecht, langsam. Das ist die Situation, die Sie vermeiden m\u00f6chten, wenn Sie dies f\u00fcr eine Datenbank verwenden. <\/p>\n
<\/p>\n
Daher ist die sinnvollere L\u00f6sung f\u00fcr die Datenbank, dass das Betriebssystem Linux \u00fcberhaupt nicht wei\u00df, was dort passiert. Damit es auf den Speicher zugreift, wie es zugreift. <\/p>\n
<\/p>\n
Warum ist das so? Es scheint, dass es umgekehrt sein sollte. Das passiert aus einem einfachen Grund, dass wir viel Speicher f\u00fcr den Page Cache ben\u00f6tigen \u2013 Dutzende, Hunderte von Gigabyte. <\/p>\n
<\/p>\n
Und wenn wir das alles zugewiesen und unsere Daten dort zwischengespeichert haben, dann wird der Vorteil durch die Verwendung des Caches deutlich gr\u00f6\u00dfer sein als der Vorteil durch so eine raffinierte Speicheransprache. Dadurch gewinnen wir in einem Vergleich dazu, dass wir effizienter auf den Speicher mit NUMA\u2010Technik zugreifen.<\/p>\n
<\/p>\n
Aus diesem Grund gibt es derzeit zwei Ans\u00e4tze, solange die strahlende Zukunft noch nicht eingetreten ist und die Datenbank nicht selbst herausfindet, auf welchen CPUs sie arbeitet und woher sie etwas abrufen muss. <\/p>\n
<\/p>\n
<\/p>\n
Daher ist der richtige Ansatz, NUMA generell abzuschalten<\/strong>, zum Beispiel beim Neustart. In den meisten F\u00e4llen sind die Gewinne so erheblich, dass die Frage, was besser ist, gar nicht aufkommt. <\/p>\n<\/p>\n
Es gibt eine andere M\u00f6glichkeit. Wir verwenden sie \u00f6fter als die erste, weil es f\u00fcr einen Kunden, der zu uns kommt, ein gro\u00dfes Anliegen ist, den Server neugestartet zu bekommen. Sein Gesch\u00e4ft l\u00e4uft dort. Und sie haben Probleme mit NUMA. Daher versuchen wir, es auf weniger invasive Weise abzustellen als durch einen Neustart, aber achten Sie darauf, dass es auch tats\u00e4chlich abgeschaltet ist. Denn wie die Erfahrung zeigt, dass wir NUMA f\u00fcr den \u00fcbergeordneten PostgreSQL-Prozess deaktivieren, ist das gut, aber es ist nicht unbedingt sicher, dass das funktioniert. Man muss \u00fcberpr\u00fcfen und sicherstellen, dass es wirklich abgeschaltet ist. <\/p>\n
<\/p>\n
Es gibt einen guten Beitrag von Robert Haas. Er ist einer der Committer von PostgreSQL und z\u00e4hlt zu den Hauptentwicklern aller Low-Level-Details. Wenn man den Links in diesem Beitrag folgt, findet man mehrere farbenfrohe Geschichten dar\u00fcber, wie NUMA den Menschen das Leben erschwert hat. Schaut euch die Checkliste f\u00fcr Systemadministratoren an, um zu sehen, was auf dem Server eingestellt werden muss, damit unsere Datenbank gut funktioniert. Diese Einstellungen sollten notiert und \u00fcberpr\u00fcft werden, denn sonst kann es problematisch werden. <\/p>\n
<\/p>\n
Ich weise darauf hin, dass dies alle Einstellungen betrifft, \u00fcber die ich sprechen werde. Normalerweise werden Datenbanken im Master-Slave-Modus f\u00fcr Ausfallsicherheit konfiguriert. Vergessen Sie nicht, diese Einstellungen auch im Slave vorzunehmen, denn eines sch\u00f6nen Tages wird ein Notfall eintreten, und Sie m\u00fcssen auf den Slave umschalten, der dann 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 hereingest\u00fcrzt. Dann bleibt keine Zeit, um zu pr\u00fcfen. Die Ergebnisse k\u00f6nnen ziemlich katastrophal sein.<\/p>\n
<\/p>\n
<\/p>\n
Der n\u00e4chste Punkt sind Huge Pages. Huge Pages sind schwierig separat zu testen, und es macht auch keinen Sinn, obwohl es Benchmarks gibt, die das k\u00f6nnen. Diese finden Sie leicht \u00fcber eine Google-Suche. <\/p>\n
<\/p>\n
Worum geht es? Sie haben einen nicht besonders teuren Server mit viel RAM, zum Beispiel mehr als 30 GB. Huge Pages werden nicht verwendet. Das bedeutet, dass es eindeutig einen Overhead bei der Speichernutzung gibt. Und dieser Overhead ist alles andere als angenehm. <\/p>\n
<\/p>\n
<\/p>\n
Warum ist das so? Was passiert dabei? Das Betriebssystem weist den Speicher in kleinen St\u00fccken zu. So ist es bequem, das hat sich historisch so entwickelt. Wenn man ins Detail geht, muss das OS virtuelle Adressen in physische \u00fcbersetzen. Und dieser Prozess ist nicht der einfachste, weshalb das OS das Ergebnis dieses Vorgangs im Translation Lookaside Buffer (TLB) cacht.<\/p>\n
<\/p>\n
Da der TLB ein Cache ist, treten in dieser Situation alle typischen Cache-Probleme auf. Erstens, wenn Sie sehr viel RAM haben und dieser in kleinen Chunks zugewiesen ist, wird der Buffer sehr gro\u00df. Und wenn der Cache gro\u00df ist, dauert die Suche darin l\u00e4nger. Der Overhead ist erheblich, und er selbst ben\u00f6tigt Platz, d.h. irgendetwas Unangemessenes verbraucht RAM. <\/p>\n
<\/p>\n
Zwei \u2013 je mehr der Cache in einer solchen Situation anw\u00e4chst, desto h\u00f6her ist die Wahrscheinlichkeit, dass Sie Cache Misses haben. Die Effizienz dieses Caches sinkt schnell mit seiner Gr\u00f6\u00dfe. Deshalb wurde in Betriebssystemen ein einfacher Ansatz entwickelt. In Linux wird dies schon lange verwendet. In FreeBSD ist es nicht so lange her, dass es eingef\u00fchrt wurde. Aber wir sprechen von Linux. Es sind huge pages.<\/p>\n
<\/p>\n
Hier ist zu erw\u00e4hnen, dass huge pages als Idee urspr\u00fcnglich von Gemeinschaften, zu denen Oracle und IBM geh\u00f6rten, durchgesetzt wurden, d. h. die Hersteller von Datenbanken haben intensiv dar\u00fcber nachgedacht, dass dies n\u00fctzlich sein k\u00f6nnte, unter anderem f\u00fcr Datenbanken. <\/p>\n
<\/p>\n
<\/p>\n
Wie l\u00e4sst sich das mit PostgreSQL kombinieren? Erstens m\u00fcssen huge pages im Linux-Kernel aktiviert sein.<\/p>\n
<\/p>\n
Zweitens m\u00fcssen sie explizit durch den sysctl-Parameter angegeben werden \u2013 wie viele es sind. Die Zahlen stammen von einem \u00e4lteren Server. Sie k\u00f6nnen ungef\u00e4hr berechnen, wie viele Shared Buffers Sie haben, damit die huge pages dort Platz finden. <\/p>\n
<\/p>\n
Wenn Ihr gesamte Server PostgreSQL gewidmet ist, dann ist ein guter Ausgangspunkt, entweder 25 % des Arbeitsspeichers f\u00fcr Shared Buffers zu verwenden oder 75 %, wenn Sie sicher sind, dass Ihre Datenbank in diese 75 % passt. Das ist der erste Ausgangspunkt. Und rechnen Sie, wenn Sie 256 GB RAM haben, dann haben Sie entsprechend 64 GB Shared Buffers. Sch\u00e4tzen Sie ungef\u00e4hr mit etwas Puffer \u2013 in welcher H\u00f6he diese Zahl eingestellt werden sollte.<\/p>\n
<\/p>\n
Bis zur Version 9.2 (wenn ich mich nicht irre, ab Version 8.2) konnte man PostgreSQL mithilfe einer Drittanbieterbibliothek mit huge pages verbinden. Und das muss immer gemacht werden. Erstens muss das Kernel in der Lage sein, huge pages richtig zuzuweisen. Und zweitens, damit die Anwendung, die damit arbeitet, sie nutzen kann. Einfach so wird sie das nicht tun. Da PostgreSQL den Speicher im Style von System 5 zugewiesen hat, konnte dies mit libhugetlbfs geschehen \u2013 das ist der vollst\u00e4ndige Name der Bibliothek.<\/p>\n
<\/p>\n
In Version 9.3 wurde die Leistung von PostgreSQL im Umgang mit Speicher verbessert, und die Methode 5 zur Speicherzuweisung wurde aufgegeben. Alle waren sehr erfreut, denn ansonsten versucht man, zwei Instanzen von PostgreSQL auf einer Maschine zu starten, und er sagt, dass der Shared-Speicher nicht ausreicht. Und er sagt, man muss den sysctl anpassen. Dabei ist der sysctl so beschaffen, dass man sich auch neu starten muss usw. Insgesamt waren alle erfreut. Aber die mmap-Speicherzuweisung hat die Verwendung von Huge Pages beeintr\u00e4chtigt. Die meisten unserer Kunden verwenden gro\u00dfe Shared Buffers. Und wir haben dringend empfohlen, nicht auf 9.3 umzusteigen, da dort der Overhead in guten Prozents\u00e4tzen beginnt zu berechnen.<\/p>\n
<\/p>\n
Aber die Community hat auf dieses Problem hingewiesen und in 9.4 wurde dieses Thema sehr gut \u00fcberarbeitet. In 9.4 gibt es nun einen Parameter in postgresql.conf, mit dem man try, on oder off aktivieren kann.<\/p>\n
<\/p>\n
Try ist der sicherste Parameter. Beim Start von PostgreSQL, wenn er den Shared-Speicher zuweist, versucht er, sich diesen Speicher aus den Huge Pages zu holen. Und wenn das nicht klappt, f\u00e4llt er auf die normale Zuweisung zur\u00fcck. Wenn Sie FreeBSD oder Solaris haben, k\u00f6nnen Sie try verwenden, das ist immer sicher. <\/p>\n
<\/p>\n
Wenn on, dann startet er einfach nicht, wenn er den Speicher nicht aus den Huge Pages zuweisen konnte. Das h\u00e4ngt dann von den individuellen Vorlieben ab. Aber wenn Sie try eingestellt haben, stellen Sie sicher, dass wirklich das zugewiesen wurde, was ben\u00f6tigt wird, denn es gibt viel Raum f\u00fcr Fehler. Momentan funktioniert diese Funktionalit\u00e4t nur unter Linux.<\/p>\n
<\/p>\n
Noch eine kleine Anmerkung, bevor wir fortfahren. Transparent Huge Pages sind bisher nicht f\u00fcr PostgreSQL relevant. Er kann sie nicht richtig nutzen. Und bei Transparent Huge Pages gibt es f\u00fcr solche Workloads, bei denen ein gro\u00dfer St\u00fcck Shared-Speicher ben\u00f6tigt wird, nur bei sehr gro\u00dfen Volumina Vorteile. Wenn Sie Terabytes an Speicher haben, kann das eine Rolle spielen. Wenn wir von allt\u00e4glichen Anwendungen sprechen, bei denen Sie 32, 64, 128 oder 256 GB Speicher auf der Maschine haben, dann ist die normale Huge Page-Implementierung in Ordnung, w\u00e4hrend Transparent einfach deaktiviert bleibt. <\/p>\n
<\/p>\n
<\/p>\n
Und das letzte Thema, das den Speicher betrifft, ist nicht direkt mit dem Durchsatz verbunden, kann aber das Leben erheblich erschweren. Die gesamte Bandbreite leidet erheblich, da der Server st\u00e4ndig swappt. <\/p>\n
<\/p>\n
Und das wird in einer Reihe von Momenten sehr unangenehm sein. Das Hauptproblem besteht darin, dass sich das Verhalten der modernen Kerne etwas von den \u00e4lteren Linux-Kernen unterscheidet. Und das ist etwas, auf was man ziemlich unangenehm tritt, denn wenn wir \u00fcber die Arbeit mit Swap sprechen, endet das nicht mit dem rechtzeitigen Erscheinen des OOM-Killers. Und der OOM-Killer, der nicht rechtzeitig kam und PostgreSQL heruntergefahren hat, ist unangenehm. Das erfahren alle, d. h. bis zum letzten Benutzer. <\/p>\n
<\/p>\n
<\/p>\n
Was passiert? Ihr habt viel Arbeitsspeicher, alles funktioniert gut. Aber aus irgendeinem Grund h\u00e4ngt der Server im Swap und verlangsamt sich dadurch. Es scheint, dass viel Speicher vorhanden ist, aber trotzdem passiert es. <\/p>\n
<\/p>\n
<\/p>\n
Fr\u00fcher haben wir empfohlen, vm.swappiness auf null zu setzen, d. h. Swap zu deaktivieren. Fr\u00fcher schien es, dass 32 GB Arbeitsspeicher und entsprechende Shared Buffers eine riesige Menge sind. Die Hauptaufgabe von Swap besteht darin, einen Platz zu haben, wohin man einen Prozess ablegen kann, wenn wir ausfallen. Und das hat nicht mehr wirklich funktioniert. Und was macht man dann mit diesem Prozess? Das ist dann so eine Aufgabe, bei der nicht ganz klar ist, wozu Swap \u00fcberhaupt ben\u00f6tigt wird, erst recht nicht in solcher Gr\u00f6\u00dfe. <\/p>\n
<\/p>\n
Aber in den moderneren, d. h. in den dritten Versionen des Kerns hat sich das Verhalten ge\u00e4ndert. Wenn man Swap auf null setzt, also deaktiviert, wird irgendwann, auch bei noch vorhandenem Arbeitsspeicher, der OOM-Killer kommen, um die intensivsten Verbraucher zu killen. Denn er wird annehmen, dass bei dieser Arbeitslast noch ein wenig Speicher \u00fcbrig ist und wir ausfallen, d. h. nicht den Systemprozess abschalten, sondern etwas weniger Wichtiges. Dieses weniger Wichtige wird dann ein intensiver Verbraucher des Shared Memory sein, n\u00e4mlich postmaster. Und danach wird es gut sein, wenn die Datenbank nicht wiederhergestellt werden muss. <\/p>\n
<\/p>\n
Deshalb ist standardm\u00e4\u00dfig, soweit ich mich erinnere, bei den meisten Distributionen ein Wert von etwa 6 eingestellt, d. h. ab wann mit Swap begonnen wird, je nachdem, wie viel Speicher noch \u00fcbrig ist. Wir empfehlen jetzt, vm.swappiness auf 1 zu setzen, weil das es praktisch ausschaltet, aber nicht die negativen Effekte hat, die mit einem unerwartet kommenden OOM-Killer verbunden sind, der alles kaputt macht.<\/strong> <\/p>\n<\/p>\n
<\/p>\n
Was kommt als N\u00e4chstes? Wenn wir \u00fcber die Leistung von Datenbanken sprechen und allm\u00e4hlich zu den Festplatten \u00fcbergehen, geraten alle in Aufruhr. Denn die Wahrheit, dass die Festplatte langsam und der Speicher schnell ist, ist jedem seit seiner Kindheit bekannt. Und alle wissen, dass es in einer Datenbank Probleme mit der Festplattenleistung geben wird.<\/p>\n
<\/p>\n
Das Hauptproblem mit der Leistung von PostgreSQL, das mit den Spitzenbelastungen bei Checkpoints verbunden ist, entsteht nicht, weil die Festplatte langsam ist. Es liegt eher daran, dass die Bandbreite von Speicher und Festplatte nicht ausgeglichen ist. Dabei k\u00f6nnen sie an verschiedenen Punkten unausgeglichen sein. PostgreSQL ist nicht konfiguriert, das Betriebssystem ist nicht konfiguriert, die Hardware ist nicht konfiguriert und die Hardware ist falsch. Und dieses Problem tritt nur dann nicht auf, wenn alles nach Plan l\u00e4uft, d. h. entweder gibt es keine Last oder die Einstellungen und die Hardware sind gut ausgew\u00e4hlt. <\/p>\n
<\/p>\n
<\/p>\n
Was ist das und wie sieht es aus? Normalerweise arbeiten Menschen, die mit PostgreSQL umgehen, mehrmals an diesem Thema. Ich werde es erkl\u00e4ren. Wie ich bereits sagte, f\u00fchrt PostgreSQL regelm\u00e4\u00dfig Checkpoints durch, um die schmutzigen Seiten im gemeinsamen Speicher auf die Festplatte zu dumpen. Wenn wir ein gro\u00dfes Volumen an gemeinsamem Speicher haben, beginnt der Checkpoint intensiv auf die Festplatte einzuwirken, weil er diese Seiten mit fsync dumpet. Er gelangt in den Kernel-Puffer und wird mithilfe von fsync auf die Festplatten geschrieben. Und wenn dieses Volumen gro\u00df ist, k\u00f6nnen wir einen unangenehmen 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. Das sind zwei zeitlich korrelierte Grafiken. Die erste Grafik zeigt die Festplattenauslastung. Hier erreicht sie in diesem Moment fast 90 %. Wenn Ihre Datenbank mit physischen Festplatten und einem RAID-Controller eine Auslastung von fast 90 % aufweist, sind das schlechte Nachrichten. Das bedeutet, dass es nur noch ein kleines St\u00fcckchen bis zu 100 % sind und die Ein- und Ausgabe stoppen werden. <\/p>\n
<\/p>\n
Wenn Sie ein RAID-System haben, sieht die Geschichte ein wenig anders aus. Es h\u00e4ngt davon ab, wie es konfiguriert ist, um was f\u00fcr ein Array es sich handelt usw. <\/p>\n
<\/p>\n
Gleichzeitig ist hier ein Diagramm aus der internen PostgreSQL-Ansicht konfiguriert, das zeigt, wie der Checkpoint abl\u00e4uft. In Gr\u00fcn wird angezeigt, wie viele Buffer, also diese schmutzigen Seiten, in diesem Moment f\u00fcr die Synchronisierung bei diesem Checkpoint angekommen sind. Und das ist das Wichtigste, was man hier wissen muss. Wir sehen, dass viele Seiten angekommen sind und irgendwann sto\u00dfen wir auf die Grenze, d.h. wir haben viel geschrieben, hier ist eindeutig das Speichersystem stark besch\u00e4ftigt. Und unser Checkpoint hat einen gro\u00dfen Einfluss auf die Festplatte. Idealerweise sollte die Situation eher so aussehen, dass wir hier weniger Schreibvorg\u00e4nge hatten. Und mit den Einstellungen k\u00f6nnen wir das beheben, damit es so bleibt. Das hei\u00dft, die Auslastung ist gering, aber irgendwo machen wir hier Schreibvorg\u00e4nge. <\/p>\n
<\/p>\n
Was muss man tun, um dieses Problem zu \u00fcberwinden? Wenn das IO unter der Datenbank stoppt, bedeutet das, dass alle Benutzer, die ihre Anfragen ausf\u00fchren wollen, warten m\u00fcssen. <\/p>\n
<\/p>\n
<\/p>\n
Wenn man das aus der Sicht von Linux betrachtet, wenn man gute Hardware hat, sie richtig konfiguriert hat und PostgreSQL so eingestellt hat, dass es diese Checkpoints seltener durchf\u00fchrt und sie zeitlich voneinander verteilt, dann landet man bei den Standardparametern von Debian. F\u00fcr die meisten Linux-Distributionen sieht die Situation so aus: vm.dirty_ratio=20, vm.dirty_background_ratio=10.<\/p>\n
<\/p>\n
Was bedeutet das? Mit dem Kernel 2.6 erschien ein Daemon f\u00fcr das Flushing. Pdglush, je nachdem, wer welchen nutzt, befasst sich mit dem Hintergrund-Entfernen von schmutzigen Seiten aus dem Kernel-Buffer und damit, das Entfernen durchzuf\u00fchren, wenn es unbedingt n\u00f6tig ist, wenn das Hintergrund-Entfernen nicht mehr hilft. <\/p>\n
<\/p>\n
Wann tritt das Hintergrund-Entfernen ein? Wenn 10 % des gesamten Arbeitsspeichers, der auf dem Server vorhanden ist, mit schmutzigen Seiten im Kernel-Buffer belegt sind, wird eine spezielle Funktion f\u00fcr das Entfernen im Hintergrund aufgerufen. Warum ist sie im Hintergrund? Sie nimmt als Parameter auf, wie viele Seiten entfernt werden sollen. Und, sagen wir, entfernt N Seiten. Und f\u00fcr eine gewisse Zeit schl\u00e4ft dieses Ding dann. Danach kommt es wieder und entfernt eine weitere Anzahl von Seiten. <\/p>\n
<\/p>\n
Das ist eine ganz einfache Geschichte. Hier ist die Aufgabe wie bei einem Pool, wo in ein Rohr rein und aus einem anderen rausl\u00e4uft. Unser Checkpoint ist angekommen und wenn er nur wenige schmutzige Seiten zum Entfernen geschickt hat, wird sich das allm\u00e4hlich aus dem Kernel-Buffer durch pgflush zusammensetzen. <\/p>\n
<\/p>\n
Wenn diese schmutzigen Seiten weiter ansammeln, summieren sie sich bis zu 20 %, danach hat das Betriebssystem Priorit\u00e4t, all dies auf die Festplatte zu schreiben, weil die Stromversorgung ausf\u00e4llt, und es wird schlecht f\u00fcr uns sein. Wir verlieren diese Daten, zum Beispiel. <\/p>\n
<\/p>\n
Was ist der Trick? Der Trick besteht darin, dass diese Parameter in der modernen Welt 20 und 10 % des gesamten Arbeitsspeichers, der im Computer vorhanden ist, ausmachen, was aus Sicht der Bandbreite jeder Festplattensysteme, die Sie haben, v\u00f6llig t\u00f6dlich ist.<\/strong> <\/p>\n<\/p>\n
Stellen Sie sich vor, Sie haben 128 GB RAM. 12,8 GB kommen in Ihr Speichersystem. Und egal, welcher Cache vorhanden ist, egal welches Array Sie haben, sie werden das nicht verkraften. <\/p>\n
<\/p>\n
<\/p>\n
Deshalb empfehlen wir, diese Zahlen sofort an die M\u00f6glichkeiten Ihres RAID-Controllers anzupassen.<\/strong> Hier ist sofort eine Empfehlung f\u00fcr einen Controller angegeben, der 512 MB Cache hat. <\/p>\n<\/p>\n
Es ist alles sehr einfach. Man kann vm.dirty_background in Bytes setzen. Und diese Einstellungen heben die vorherigen beiden auf. Entweder das Verh\u00e4ltnis standardm\u00e4\u00dfig oder die aktiviert, die in Bytes sind, werden die arbeiten, die in Bytes sind. Aber da ich als DBA-Berater arbeite und mit verschiedenen Kunden zu tun habe, versuche ich, auf Nummer sicher zu gehen, und daher, wenn in Bytes, dann in Bytes. Niemand hat eine Garantie gegeben, dass ein freundlicher Administrator dem Server nicht mehr Speicher zuschiebt oder ihn nicht neu startet, w\u00e4hrend die Zahl die gleiche bleibt. Berechnen Sie einfach diese Zahlen, damit garantiert alles hineinpasst. <\/p>\n
<\/p>\n
Was passiert, wenn Sie nicht hineinpassen? Es steht geschrieben, dass jeder Flushing effektiv gestoppt wird, aber in Wirklichkeit ist das eine Floskel. Das Betriebssystem hat ein gro\u00dfes Problem \u2013 es hat viele schmutzige Seiten, deshalb wird der IO, der von Ihren Clients erzeugt wird, effektiv gestoppt, d. h. eine SQL-Anwendung ist dabei, eine Anfrage an die Datenbank zu senden, sie wartet. Jeder Input-Output in sie hat die niedrigste Priorit\u00e4t, weil die Datenbank mit dem Checkpoint besch\u00e4ftigt ist. Und wann sie damit fertig ist, ist v\u00f6llig unklar. Und wenn Sie nicht am hintergr\u00fcndigen, nicht am Hintergrund-Flushing angekommen sind, bedeutet das, dass alle IO damit besch\u00e4ftigt sind. Und solange es nicht abgeschlossen ist, k\u00f6nnen Sie nichts tun. <\/p>\n
<\/p>\n
Es gibt noch zwei wichtige Punkte, die den Rahmen dieses Berichts sprengen. Diese Einstellungen sollten mit den Einstellungen in postgresql.conf \u00fcbereinstimmen, d. h. den Einstellungen f\u00fcr Checkpoints. Und Ihr Speichersystem sollte angemessen konfiguriert sein. Wenn Sie einen Cache auf RAID haben, sollte sich darauf eine Batterie befinden.<\/strong> Menschen kaufen RAID mit gutem Cache ohne Batterie. Wenn Sie SSDs im RAID haben, sollten sie Server-SSDs sein, sie sollten Kondensatoren haben.<\/strong> Hier ist eine ausf\u00fchrliche Checkliste. \u00dcber diesen Link finden Sie meinen Bericht dar\u00fcber, wie man die Disk-Performance in PostgreSQL einstellt. Dort sind all diese Checklisten enthalten. <\/p>\n<\/p>\n
<\/p>\n
Was kann das Leben noch erheblich erschweren? Das sind zwei Parameter. Sie sind relativ neu. Sie k\u00f6nnen standardm\u00e4\u00dfig in verschiedenen Anwendungen aktiviert sein. Und sie k\u00f6nnen das Leben nicht minder komplizieren, wenn sie falsch aktiviert sind. <\/p>\n
<\/p>\n
<\/p>\n
Es gibt zwei relativ neue Merkmale. Sie sind bereits in den dritten Kernversionen aufgetaucht. Das sind sched_migration_cost in Nanosekunden und sched_autogroup_enabled, das standardm\u00e4\u00dfig auf eins gesetzt ist. <\/p>\n
<\/p>\n
Und wie beeintr\u00e4chtigen sie das Leben? 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 die Migration auf einen anderen CPU v\u00f6llig unverst\u00e4ndlich. F\u00fcr die Datenbank ist das sehr schlecht.<\/strong> Daher ist eine sinnvolle Politik, den migration_cost auf einen hohen Wert zu setzen, zumindest mehrere tausend Nanosekunden.<\/strong> <\/p>\n<\/p>\n
Was wird das f\u00fcr den Scheduler bedeuten? Er wird annehmen, dass dieser Prozess in diesem Zeitraum weiterhin aktiv ist. Das bedeutet, wenn Sie eine lange Transaktion haben, die sich mit etwas Zeitaufwendigem besch\u00e4ftigt, wird der Scheduler das verstehen. Er wird annehmen, dass dieser Prozess nicht migriert werden muss, solange dieser Timeout nicht \u00fcberschritten ist. Wenn der Prozess gleichzeitig etwas tut, wird er nicht migriert, sondern l\u00e4uft weiterhin auf dem CPU, der ihm zugewiesen wurde. Das Ergebnis ist ausgezeichnet. <\/p>\n
<\/p>\n
Der zweite Punkt ist autogroup. Es gibt eine gute Idee f\u00fcr spezifische Workloads, die nichts mit modernen Datenbanken zu tun haben \u2013 Prozesse nach dem virtuellen Terminal, von dem aus sie gestartet wurden, zu gruppieren. Das ist praktisch f\u00fcr bestimmte Aufgaben. In der Praxis ist PostgreSQL ein Multiprozesssystem mit Prefork, das von einem Terminal aus gestartet wird. Sie haben Writer-Locks, Checkpoints, und alle Ihre Client-Anfragen werden auf einen Scheduler, auf eine CPU, gruppiert. Dort werden sie gemeinsam warten, bis sie frei werden, um sich gegenseitig zu behindern und sie l\u00e4nger zu besetzen. Diese Situation ist bei solch einer Belastung v\u00f6llig unn\u00f6tig, und daher sollte sie abgeschaltet werden.<\/strong><\/p>\n<\/p>\n
<\/p>\n
Mein Kollege Alexey Lesovskiy hat Tests mit einfachem pgbench durchgef\u00fchrt, bei denen er die Migrationskosten um den Faktor 10 erh\u00f6ht und die Autogruppe deaktiviert hat. Der Unterschied bei schlechter Hardware betrug fast 10 %.<\/strong>. Es gibt eine Diskussion in der Postgres-Mail-Liste, in der Leute Ergebnisse erw\u00e4hnen, wie solche \u00c4nderungen die Abfragegeschwindigkeit beeinflussten um 50 %.<\/strong>. Es gibt viele solcher Geschichten.<\/p>\n<\/p>\n
<\/p>\n
Und abschlie\u00dfend zur Stromsparpolitik. Es ist gut, dass man Linux jetzt auf einem Laptop verwenden kann. Und es wird angeblich den Akku gut schonen. Aber pl\u00f6tzlich stellt sich heraus, dass das auch auf Servern so sein kann. <\/p>\n
<\/p>\n
Dar\u00fcber hinaus, wenn Sie Server von einem Hosting-Anbieter mieten, k\u00fcmmern sich die \"freundlichen\" Hoster<\/a> nicht darum, Ihnen eine bessere Leistung zu bieten. Ihre Aufgabe ist es, daf\u00fcr zu sorgen, dass ihre Hardware m\u00f6glichst effizient genutzt wird. Daher k\u00f6nnen sie standardm\u00e4\u00dfig den Energiesparmodus des Laptops im Betriebssystem aktivieren.<\/p>\n<\/p>\n
Wenn Sie auf einem Server mit einer stark belasteten Datenbank den Energiesparmodus verwenden, dann ist Ihre Wahl acpi_cpufreq + performance. Selbst mit ondemand werden bereits Probleme auftreten.<\/strong> <\/p>\n<\/p>\n
Intel_pstate ist bereits ein etwas anderer Treiber. Und aktuell wird dieser bevorzugt, da er sp\u00e4ter entwickelt wurde und besser funktioniert.<\/p>\n
<\/p>\n
Entsprechend ist der Governor ausschlie\u00dflich performance. Ondemand, powersave und alles andere \u2013 das ist nicht f\u00fcr Sie. <\/p>\n
<\/p>\n
Die Ergebnisse von explain analyze in PostgreSQL k\u00f6nnen um mehrere Gr\u00f6\u00dfenordnungen abweichen, wenn Sie powersave aktivieren, da der CPU unter Ihrer Datenbank auf vollkommen unvorhersehbare Weise geplant wird.<\/p>\n
<\/p>\n
Diese Dinge k\u00f6nnen standardm\u00e4\u00dfig aktiviert sein. Schauen Sie genau hin \u2013 haben sie m\u00f6glicherweise standardm\u00e4\u00dfig aktiviert. Das k\u00f6nnte wirklich ein gro\u00dfes Problem sein. <\/p>\n
<\/p>\n
<\/p>\n
Und zum Schluss m\u00f6chte ich den Jungs aus unserem DBA-Team PosgreSQL-Consulting danken, insbesondere Max Boguk und Alexey Lesovsky, die sich jeden Tag mit diesem Thema auseinandersetzen. F\u00fcr unsere Kunden versuchen wir, es so gut wie m\u00f6glich zu machen, damit alles funktioniert. Das ist wie mit den Anleitungen zur Flugsicherheit. Hier steht alles in Blut geschrieben. Jede dieser Schrauben wurde im Zuge eines Problems entdeckt. Ich teile sie gerne mit Ihnen.<\/p>\n
<\/p>\n
Fragen:<\/p>\n
<\/p>\n
Danke! Wenn zum Beispiel ein Unternehmen Kosten sparen m\u00f6chte und die Datenbank und die Anwendungslogik auf einem Server unterbringen m\u00f6chte, oder wenn das Unternehmen dem Trend zu mikroservicebasierten Architekturen folgt, bei denen PostgreSQL in einem Container l\u00e4uft. Was ist der Trick dabei? Sysctl beeinflusst global den gesamten Kernel. Ich habe noch nie geh\u00f6rt, dass sysctl irgendwie virtualisiert wird, damit sie in einem Container separat arbeiten. Es gibt nur cgroups und dort gibt es nur eine eingeschr\u00e4nkte Kontrolle. Wie kann man damit leben? Oder wenn Sie Leistung m\u00f6chten, sollten Sie PostgreSQL auf einem eigenen physischen Server betreiben und diesen optimieren?<\/em><\/p>\n<\/p>\n
Wir haben Ihre Frage auf etwa drei Arten beantwortet. Wenn es sich nicht um einen physischen Server handelt, den man optimieren kann usw., dann entspannen Sie sich, alles wird auch ohne diese Einstellungen gut funktionieren. Wenn Sie eine Last haben, die diese Einstellungen erforderlich macht, werden Sie schneller zu einem physischen 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 viele Probleme haben, zum Beispiel mit der insgesamt inkonsistenten Latenz der Festplatte auf den meisten virtuellen Maschinen. Selbst wenn die Festplattendurchsatz gut ist, kann eine fehlgeschlagene Transaktion bei einer Ein- und Ausgabeoperation, die sich zur Zeit eines Checkpoints oder beim Schreiben in WAL ereignet, die mittlere Durchsatzrate kaum beeinflussen, aber die Datenbank wird darunter leiden. Und Sie werden das fr\u00fcher bemerken, als Sie denken. <\/p>\n
<\/p>\n
Wenn Sie NGINX auf demselben Server haben, wird es ebenfalls das gleiche Problem geben. Er wird um den gemeinsamen Speicher k\u00e4mpfen. Und zu den Problemen, die hier beschrieben sind, werden Sie nicht gelangen.<\/p>\n
<\/p>\n
Aber auf der anderen Seite werden einige dieser Parameter f\u00fcr Sie dennoch relevant sein. Zum Beispiel, mit sysctl den dirty_ratio einstellen, damit es nicht so verr\u00fcckt ist \u2013 das hilft in jedem Fall. So oder so werden Sie mit der Festplatte interagieren. Und das wird nach einem falschen Schema geschehen. Das sind im Grunde die Standardparameter, die ich gezeigt habe. Und in jedem Fall ist es besser, sie zu \u00e4ndern. <\/p>\n
<\/p>\n
Mit NUMA kann es Probleme geben. VmWare funktioniert zum Beispiel gut mit NUMA mit genau gegenteiligen Einstellungen. Und hier muss man w\u00e4hlen \u2013 ein physischer Server oder kein physischer. <\/p>\n
<\/p>\n
Ich habe eine Frage zu Amazon AWS. Sie haben vorgefertigte Images. Eines davon nennt sich Amazon RDS. Gibt es dort irgendwelche benutzerdefinierten Einstellungen f\u00fcr ihr Betriebssystem?<\/em><\/p>\n<\/p>\n
Es gibt Einstellungen, aber das sind andere Einstellungen. Hier konfigurieren wir das Betriebssystem aus der Perspektive, wie die Datenbank dies nutzen wird. Und dort gibt es Parameter, die festlegen, wohin wir jetzt gehen, so eine Art Shaping. D.h. wir brauchen so viele Ressourcen, die werden wir jetzt verbrauchen. Danach f\u00fcgt Amazon RDS diese Ressourcen hinzu, und die Leistung sinkt. Es gibt verschiedene Geschichten, wie Leute anfangen, in dieser Angelegenheit zu experimentieren. Manchmal sogar sehr erfolgreich. Aber das hat nichts mit den Einstellungen des OS zu tun. Das ist gewisserma\u00dfen Cloud-Hacking. Das ist eine andere Geschichte.<\/p>\n
<\/p>\n
Warum haben transparente gro\u00dfe Seiten keinen Effekt im Vergleich zu gro\u00dfen TLB?<\/em><\/p>\n<\/p>\n
Haben sie nicht. Man kann das auf viele Arten erkl\u00e4ren. Aber faktisch bringen sie einfach nichts. Wie steht es um PostgreSQL? Zu Beginn reserviert es ein gro\u00dfes St\u00fcck Shared Memory. Ob transparent oder nicht transparent \u2013 das ist v\u00f6llig unwichtig. Die Tatsache, dass sie zu Beginn reserviert wird, erkl\u00e4rt alles. Und wenn der Speicher sehr gro\u00df ist und der shared_memory-Segment umstrukturiert werden muss, dann wird Transparent Huge Pages relevant. Bei PostgreSQL ist es einfach zu Beginn als gro\u00dfes St\u00fcck reserviert, und das war's, und danach passiert nichts Besonderes. Nat\u00fcrlich kann man es verwenden, aber es besteht die Gefahr, dass der shared_memory besch\u00e4digt wird, wenn er etwas neu zuweist. PostgreSQL wei\u00df jedoch nichts davon.<\/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-Tuning](\"\/wp-content\/uploads\/2020\/06\/8292f74a7d004a9c13ff5f1393816340.jpg\")
<\/p>\n