PostgreSQL - Wenn ich mehrere Abfragen gleichzeitig ausführen würde, unter welchen Umständen würde ich eine Beschleunigung sehen? Unter welchen Umständen würde ich eine Verlangsamung sehen?

Ich gehe Sie alle demütig als jemanden an, der KEIN DBA ist, und ich bin sicher, dass meine Frage mit konzeptionellen Mängeln behaftet ist und "es hängt von" Landminen ab. Ich bin mir auch ziemlich sicher, dass alle von Ihnen, die sich für eine Antwort entscheiden, viel mehr Einzelheiten wünschen werden, als ich derzeit liefern kann.

Trotzdem bin ich neugierig auf das folgende Szenario im Allgemeinen:

• Angenommen, ich habe zwei nicht triviale Fragen.
• Abfrage 1 dauert durchschnittlich 2 Minuten.
• Abfrage 2 dauert durchschnittlich 5 Minuten.

Wenn ich sie direkt nacheinander seriell ausführe, wird es voraussichtlich 7 Minuten dauern, bis sie abgeschlossen sind. Ist das vernünftig?

Mehr als das, was ist, wenn ich die beiden Abfragen gleichzeitig ausführe? Zwei getrennte Verbindungen gleichzeitig.

• Unter welchen Bedingungen würde ich eine Beschleunigung erwarten? (Gesamtzeit <7 Minuten)
• Unter welchen Bedingungen würde ich eine Verlangsamung erwarten? (Gesamtzeit> 7 Minuten)

Wenn nun 1.000 nicht triviale Abfragen gleichzeitig ausgeführt würden, hätte ich die Vermutung, dass dies zu einer allgemeinen Verlangsamung führen würde. Wo wäre in diesem Fall der Engpass wahrscheinlich? Prozessor? RAM? Fährt?

Auch hier weiß ich, dass es wahrscheinlich unmöglich ist, die Frage genau zu beantworten, ohne Einzelheiten zu kennen (die ich nicht habe). Ich suche nach allgemeinen Richtlinien, über die ich nachdenken muss, wenn ich die folgenden Fragen stelle:

• Unter welchen Umständen führen gleichzeitige Abfragen zu einer allgemeinen Beschleunigung?
• Unter welchen Umständen führen gleichzeitige Abfragen zu einer allgemeinen Verlangsamung?

Wenn ich sie direkt nacheinander seriell ausführe, wird es voraussichtlich 7 Minuten dauern, bis sie abgeschlossen sind. Ist das vernünftig?

Wenn sie nicht verwandte Datensätze verwenden, dann ja.

Wenn sie einen Datensatz gemeinsam nutzen und der Cache für die erste Abfrage kalt ist und die Abfrage größtenteils an E / A gebunden ist, wird die zweite möglicherweise in wenigen Augenblicken abgeschlossen. Sie müssen Caching-Effekte berücksichtigen, wenn Sie sich mit Leistungsanalyse und Abfrage-Timing befassen.

Mehr als das, was ist, wenn ich die beiden Abfragen gleichzeitig ausführe? Zwei getrennte Verbindungen gleichzeitig.

"Es hängt davon ab, ob".

Wenn beide sequentielle Scans derselben Tabelle verwenden würden, wäre dies in PostgreSQL aufgrund der Unterstützung für synchronisierte sequentielle Scans ein enormer Leistungsgewinn.

Wenn sie dieselben Indizes gemeinsam nutzen würden, würden sie wahrscheinlich von den gegenseitigen Lesevorgängen im Cache profitieren.

Wenn sie unabhängig sind und unterschiedliche Daten berühren, konkurrieren sie möglicherweise um die E / A-Bandbreite. In diesem Fall benötigen sie möglicherweise dieselbe Zeit wie die sequentielle Ausführung. Wenn das E / A-Subsystem von Parallelität profitiert (höherer Nettodurchsatz mit mehr Clients), ist die Gesamtzeit möglicherweise kürzer. Wenn das E / A-Subsystem die Parallelität schlecht verarbeitet, dauert es möglicherweise länger, als sie nacheinander auszuführen. Oder sie sind möglicherweise überhaupt nicht an E / A gebunden. In diesem Fall könnten sie, wenn für jede eine freie CPU vorhanden ist, gut ausgeführt werden, als ob die andere überhaupt nicht ausgeführt würde.

Dies hängt stark von der Hardware- und Systemkonfiguration, dem Datensatz und den Abfragen selbst ab.

Wenn nun 1.000 nicht triviale Abfragen gleichzeitig ausgeführt würden, hätte ich die Vermutung, dass dies zu einer allgemeinen Verlangsamung führen würde. Wo wäre in diesem Fall der Engpass wahrscheinlich? Prozessor? RAM? Fährt?

Ja, das würde die Dinge aus mehreren Gründen sehr wahrscheinlich verlangsamen.

• PostgreSQLs eigene Gemeinkosten für die Koordination zwischen Prozessen, das Transaktions- und Sperrenmanagement, das Puffermanagement usw. Dies kann sehr hohe Kosten verursachen, und PostgreSQL ist nicht wirklich für hohe Clientzahlen ausgelegt - es funktioniert besser, wenn Sie in der Warteschlange arbeiten .

• Wettbewerb um Arbeitsspeicher, Cache usw.

• Overhead bei der Planung des Betriebssystems, da 1000 konkurrierende Prozesse alle Zeitscheiben benötigen. Heutzutage sind moderne Betriebssysteme ziemlich klein und haben schnelle Planer.

• I / O verprügeln. Die meisten E / A-Systeme weisen eine Clientanzahl mit Spitzenleistung auf. Manchmal ist es 1, dh es ist am besten mit nur einem Client, aber es ist oft höher. Manchmal sinkt die Leistung wieder über den Schwellenwert. Manchmal erreicht es nur ein Plateau.