Speicherverbrauch "beschränken"

Hallo zusammen,

ich bin was das Thema PostgreSQL angeht noch am Anfang, da ich bis dato nur MySQL verwendet habe. Soweit habe ich mir 3 Bücher und ein paar Online-Dokus zu dem Thema zu Gemüte geführt, tappe aber bei einer Sache noch etwas im Dunklen. Ich habe PostgreSQL momentan auf einem kleinen Testsystem am laufen um Erfahrungen damit zu sammeln.

Schlussendlich soll PostgreSQL für eine Webapplikation, die ich entwickle, verwendet werden. Das ganz soll dann auf einem Server mit insgesamt 8 GB RAM laufen, wovon ich 3GB für PostgreSQL, 2GB für den Webserver, 2GB für Python-Prozesse und 1 GB für das System vorgesehen habe.

Wie sind die Einstellungen für sagen wir einfach mal max. 100 Client-Connections zu berechnen, bzw. welche Einstellungen sind für shared_buffers zu wählen? Es ist bei shared_buffers so ca. von 1/4 des RAMs die Rede, das wären hier dann 768 MB. Ich habe die Datenbank bis jetzt immer mit pg_bench getestet, das 100 Connections simuliert, aber dabei würde pro Connection ein Prozess mit 768 MB gestartet (lt. top), was ja den RAM-Verbrauch extrem hochtreiben würde (100 Connections x 768MB = 75GB). Oder lügt mich top hier an?

Muss ich hier anders rechnen, also anstatt der 25% des RAM?
Kann man hier einfach [shared_buffers = (3072 MB / 100 Connections) - work_mem] verwenden?

Hat vielleicht jemand ein paar Dokumente/Links zur Hand, damit ich mich hier weiter einlesen kann? Einem direkten Tipp wäre ich natürlich auch nicht abgeneigt :wink:

Vielen Dank schon mal im Vorraus.

Freundliche Grüße

ich vermute, dass du da was falsch interpretiert hast - meiner Erfahrung nach sind die 786 MB für alle 100 Connections wohl realistisch - bei mir braucht jeder PG prozess 5-8 MB (mehr oder weniger idle) unter windows - ich kann mir vorstellen, dass unter linux oder was auch immer aehnliche größenordnungen zu erwarten sind. das ist aber auch nich so maßgeblich.

wenn du wirklich wissen willst, womit du zu rechnen hast wird wohl das beste sein, wenn du dir ein paar kleine anwendungsfaelle programmierst und mal schaust was ein prozess (connection) an resourcen beansprucht (bei offenen datenmengen). dann kannst du auch abschaetzen was im mehrbenutzerbetrieb passiert.

100 gleichzeitig offene connections sind nicht unbedingt viel

Stimmt, ich habe da etwas falsch verstanden, ich dachte shared_buffers wäre der Wert pro Verbindung. Zudem hab ich mich noch verguckt, was Top anging. Ich dachte der “VIRT” Wert wäre der real verbrauchte Speicher, aber der real verbrauchte Speicher liegt wie du schon gesagt hast, bei ca. 4 - 6 MB. Wenn ein größerer Query ausgeführt wird, steigt dieser natürlich an, aber auch nicht ins unendliche.

Aber von dem was ich bis jetzt von PostgreSQL gesehen habe, frage ich mich gerade, warum ich meine Zeit bisher mit MySQL “vergeudet” habe :smiley:

Vielen Dank für die Hilfe. :slight_smile:

You are welcome.

Andreas

Abwarten … MySQL verfolgt(e) einfach eine andere Philosophie.

Und sach das nich so laut, sonst suchen dich die PostgreSQL-Evangelisten heim :slight_smile:

Du sprichst von “Shared Memory”. Das ist Speicher, der bei allen Prozessen gleichzeitig verwendet wird und daher auch bei allen Prozessen in der Speicherübersicht auftaucht.

Ansonsten: das Tuning einer Datenbank kann man nicht mittels einer Faustformel berechnen - leider. Dazu sind zu viele Faktoren im Spiel.

Ok, bin schon ruhig :slight_smile:

Klar verfolgt(e) MySQL andere Ziele, aber wenn man auf Referenzielle Integrität angewiesen ist und dafür InnoDB nutzen muss, sieht die Sache schon ganz anders aus. Hier denke ich hat PostgreSQL einfach die Nase vorn. Zudem, wenn selbst der “Erfinder” von MySQL sagt, dass man es nicht in großen, produktiven Systemen verwenden sollte… Naaaja :p

Zudem muss man erst einmal abwarten, was der Kauf von Sun durch Oracle aus MySQL macht.

MySQL ist für viele die Einstiegsdroge - wenn du merkst, dass du DB-affin bist, dann stößt du sehr bald an Grenzen - dann legst Du Wert auf ausgefeilte Modelle mit ein wenig Schnickschnack. etc. etc. … Referenzielle Integrität ist keine Erfindung von PostgreSQL :slight_smile: pssst

Auch mit MySQL muß man umgehen können - da kannst du schön rumsauen - Dinge machen die in PG absolutes Nogo sind - da wirst du von ADS hoechst persönlich abgewatscht g wenn du nachts heimlich drann denkst.

Nur möchte die Realität solche “tools” eben auch (nicht nur manchmal) - und da wirft dir das gut durchdachte PostgreSQL ein paar Knueppel zwischen die Beine und erweist sich für “nur bedingt geeignet”. Ok - auch kein Beinbruch.

Es kommt halt 1. darauf an, was du machen willst, und nochmal 2. was du kannst/beherrschst. MySQL ist ein dirty little helper. PostgreSQL ist kein Grund diesen zu ächten.