PostgreSQL-Skalierung auf bis zu 64 Kerne?


10

In diesem Computer World-Artikel wird angegeben, dass PostgreSQL bis zu einem Kernlimit von 64 skaliert werden kann. Bedeutet dies für einen Multi-Core-Prozessor mit 64 Kernen? Oder mehrere Prozessoren mit weniger Kernen?

Der Grund, warum ich frage, ist, dass ich versuche herauszufinden, auf wie viele Prozessoren PostgreSQL skaliert werden kann, aber das kann natürlich auf den Prozessortyp beschränkt sein. Ich habe jedoch andere Statistiken in anderen Datenbanken gefunden (dh Microsoft SQL Server hier gibt an, dass es bis zu 320 logische Prozessoren skalieren kann) und sie geben nicht die Anzahl der Kerne an. Ist das eine sehr vage Statistik?

Irgendwelche Gedanken wären sehr dankbar. Vielen Dank!


1
PostgreSQL ist es egal, ob es sich um 8 8-Kern-CPUs, 32 2-Kern-CPUs oder was auch immer handelt. Es geht nur um logische Prozessoren. Außerdem sind 64 Kerne ungefähr und hängen vom Rest Ihrer Hardware ab. 64 Kerne nützen nichts, wenn Sie nur 4 GB RAM für eine 1-TB-Datenbank auf einer SATA-Festplatte mit 7200 U / min haben. Es gibt keine feste technische Grenze für die Kernzahlen, es ist nur so, dass es kürzlich getestet wurde und nachweislich bis zu 64 skaliert.
Craig Ringer

Antworten:


7

Nein, es ist eine sehr genaue Statistik. Ein "logischer Prozessor" ist ein Kern. Und ein Kern ist genau das, es spielt keine Rolle, wie sie auf physischen Prozessoren verteilt sind.

Und wenn Sie mit einem Computer arbeiten, der mehr Kerne als die unterstützte Anzahl hat, sollte dies bei PostgreSQL kein Problem sein. Jede Verbindung ist von Natur aus Single-Threaded *. Unabhängig von der Anzahl der Kerne wird die Effizienz und Effizienz gleichzeitiger Verbindungen eingeschränkt.

Natürlich bedeutet dies auch, dass Sie Ihr Geld in schnellere Kerne als in die Anzahl der Kerne stecken sollten, es sei denn, Sie möchten die Dinge auf eine kompliziertere Methode gruppieren.

* 2017 Update: Einige Abfragen (oder Unterabfragen) können parallel ausgeführt werden .


1
Needless to say this also means you should put your money in faster cores than quantity of cores unless you want to cluster things in a more complicated method.<- Ich stimme dieser Aussage nur zu, wenn die Anzahl der Kerne größer ist als die Anzahl der gleichzeitigen Clients und die Anzahl der gleichzeitigen Clients wahrscheinlich nicht zunimmt. Für die Leistung ist es ziemlich wichtig, dass für jedes Postgres-Backend ein Kern verfügbar ist ...
voretaq7

@ voretaq7 Ich stimme größtenteils zu, aber eine CPU mit einem höheren TPS kann (offensichtlich) mehr Transaktionen in einer bestimmten Zeit verarbeiten, daher mehr Clients. Es wird einen Sweet Spot geben, der von Ihrer Ladungsart und Ihrem Budget abhängt.
Oli

1
Ein logischer Prozess ist die kleinste logische Ausführungseinheit. Mit den aktuellen Technologien ist er kein Kern, sondern ein Thread.
Dyasny

2
@ voretaq7: Es ist nicht ungewöhnlich, über einen Verbindungspooling-Mechanismus eine Verbindung zu postgresql herzustellen. Dies geschieht unter anderem, weil die Verbindung zu postgresql relativ teuer ist. Durch das Pooling kann die Anzahl der gleichzeitigen Verbindungen zur Datenbank erheblich reduziert werden. Daher bevorzuge ich schnelle CPUs gegenüber der Anzahl der Kerne. Aber wie immer: es hängt von vielen Faktoren ab ...
m.sr

2
@ m.sr Einverstanden - Verbindungspooling-Mechanismen sind sehr verbreitet. Die "intelligentesten" von diesen werden mehrere Verbindungen zu Postgres herstellen und zwischen ihnen ausgleichen (eine unserer internen Apps gibt jedem Apache-Prozess eine eigene Verbindung zu Postgres - eine recht praktische Zuordnung für unseren Anwendungsfall mit einem angemessenen Backend -zu-Benutzer-Verhältnis). IMHO, wenn Ihr Verbindungspooling Abfragen in die Warteschlange stellt, anstatt Backends zu erzeugen, tut es Ihnen keinen Gefallen, aber die Vor- und Nachteile davon wären interessanter, wenn Sie sich mit Datenbankadministratoren befassen . Also habe ich gefragt!
voretaq7

12

Postgres kann auf so viele Prozessoren skaliert werden, wie Sie installieren möchten, und Ihr Betriebssystem kann diese effektiv verwalten. Sie können Postgres auf einem 128-Core-Computer (oder sogar einem Computer mit 128 physischen Prozessoren) installieren, und es funktioniert einwandfrei. Es funktioniert möglicherweise sogar besser als auf einem 64-Core-Computer, wenn der OS-Scheduler so viele Kerne verarbeiten kann.

Es wurde gezeigt, dass Postgres linear auf 64 Kerne skaliert (mit Einschränkungen: Wir sprechen über die Leseleistung in einer bestimmten Konfiguration (Festplatte, RAM, Betriebssystem usw.) - Robert Haas hat einen Blog-Artikel mit einem schönen Diagramm, das Ich habe unten reproduziert:

Geben Sie hier die Bildbeschreibung ein

Was ist an diesem Diagramm wichtig?

Die Beziehung ist linear (oder so fast), solange die Anzahl der Clients ist kleiner als oder gleich der Anzahl der Kerne , und beginnt dann , was in etwa eine log-linear sein sieht Rückgang der Leistung , wie Sie mehr Client - Verbindungen haben , als Sie Führen Sie Kerne aus, um Postgres-Backends auszuführen, da die Backends um die CPU kämpfen (der durchschnittliche Auslastungsgrad liegt über 1,0 usw.).

Obwohl dies nur für bis zu 64 Kerne demonstriert wurde , können Sie verallgemeinern, dass Sie weiterhin Kerne (und Clients) hinzufügen und die Leistung verbessern können, bis zu einem anderen Subsystem (Festplatte, Speicher, Netzwerk), in dem keine Prozesse mehr ausgeführt werden Probleme mit CPU-Konflikten haben, aber stattdessen auf etwas anderes warten.

( Haas hat auch einen anderen Artikel veröffentlicht, in dem die lineare Skalierbarkeit auf 32 Kerne nachgewiesen wurde, der ein großartiges Referenzmaterial zur Skalierbarkeit im Allgemeinen enthält - sehr empfehlenswertes Lesen im Hintergrund!)


2
Der Grund für diese lineare Skalierbarkeit wurde übrigens in Olis Antwort erwähnt : Postgres verwendet für jede Clientverbindung einen separaten Backend-Prozess. Wenn Sie nur eine Verbindung verwenden, sehen Sie daher keinen großen (wenn überhaupt) Vorteil für mehrere Kerne. Sie benötigen parallele Anforderungen, um mehrere Kerne auszunutzen.
voretaq7

2

Andere haben klargestellt, dass sich ein logischer Prozessor im Allgemeinen auf einen CPU-Kern bezieht, aber ich möchte die Aussage kommentieren, dass es keine Rolle spielt, wie Kerne über CPUs verteilt sind.

Auf dem CPU-Chip können Caches vorhanden sein, die von mehreren Kernen gemeinsam genutzt werden oder für einzelne oder Untergruppen von Kernen reserviert sind. Eine häufig verwendete Konfiguration ist beispielsweise der dedizierte L1-Cache und der gemeinsam genutzte L2-Cache. In diesem Fall kann sich die Skalierbarkeit einer einzelnen Dual-Core-CPU von zwei Single-Core-CPUs unterscheiden.

Diese Skalierbarkeitseffekte setzen sich im Hauptspeicher fort, wobei NUMA-Maschinen ein anderes Verhalten aufweisen als Nicht-NUMA.

Ich weise nur darauf hin, weil das OP Fragen der Skalierbarkeit diskutiert, deren Antworten im Allgemeinen nuancierter sind als "Programm X kann Y CPU-Kerne verwenden".


1

In diesem Fall handelt es sich um mehrere Prozessoren mit weniger Kernen ... Ein Teil der Diskussion ist zukunftssicher. Einige sprechen Marketing.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.