Re: Hardware-Frage

From: Susanne Ebrecht <miracee(at)web(dot)de>
To: pgsql-de-allgemein(at)postgresql(dot)org
Subject: Re: Hardware-Frage
Date: 2012-03-25 10:27:37
Message-ID: 4F6EF319.1030807@web.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-de-allgemein

Am 24.03.2012 19:11, schrieb Thomas Markus:
> - bei viel ram kann es zu hängern kommen wenn die platten nicht
> hinterherkommen. Da soll kernel3.3 abhilfe schaffen. hab ich aber noch
> nicht probiert.
>

Das möchte ich kurz erläutern:

PostgreSQL lagert bei jedem Checkpoint auf die Platte aus.
Wenn jetzt soviel Shared Buffer eingestellt wurde, dass das Schreiben
auf Platte längert dauert,
als der Zeitraum zwischen zwei Checkpoints, dann suckt es.

Default passiert ein Checkpoint alle 5 Minuten oder aber nachdem die
Anzahl Checkpoint-Segments
erreicht wurde.

Es wird hier immer wieder von 8 GB als Grenze gesprochen. Aber, wo die
Grenze wirklich liegt,
hängt von der Plattengeschwindigkeit ab.

Wenn die Platte 7 Minuten braucht, um 8 GB wegzuschreiben und alle 5
Minuten passiert ein
Checkpoint, dann ist es sinnvoller nur 4 GB als Shared Buffer zu
konfigurieren, damit das
Wegschreiben nicht so ewig dauert.

RAM, der nicht in Shared Buffers festgelegt wird, steht dem
Betriebssystem zur Verfügung.
Auf einem reinen DB-Server cached hier natürlich das Betriebssystem
automatisch und
ausschließlich für PostgreSQL. Wieviel RAM zu erwarten ist, dass das
Betriebssystem für
PostgreSQL cached sollte in effective-cache-size eingetragen werden. Der
Planer weiss dann,
mit wieviel gecachten Daten er rechnen kann und ermittelt korrekt, wann
er auf die Platte
greifen muss. Bei einem reinen DB-Server ist in effective-cache-size
alles an RAM
minus das, was in Shared Buffers eingetragen wurde.

Das Betriebssystem schreibt natürlich auch irgendwann auf die Platte.
Hier sind in /proc/sys/vm/
dirty_ratio und dirty_background_ratio zu finden. Die geben an, nach
wieviel Prozent RAM an
Wegschreiben gedacht wird. Früher hatte man noch nicht soviel RAM,
deshalb können
die Werte zu hoch sein. Empfohlen wird hier als ein guter Start, 10% RAM
für dirty_ratio
und 5% für dirty_background_ratio. Das kann natürlich bei sehr viel RAM
noch immer zuviel
sein.
Wird es zu klein gesetzt, kann es aber den Server auch wieder langsam
machen.
Daneben bietet Linux mit dirty_bytes und dirty_background_bytes an, das
ganze in Bytes statt in
Prozent festzulegen. Es geht entweder oder nicht beides.eingetragen.

Viel RAM hilft nicht immer viel. Wenn die Datenbank komplett in den RAM
passt, hilft mehr RAM
gar nichts. Da sollte über schnellere Prozessoren nachgedacht werden.

Susanne

--
Susanne Ebrecht,
Bielefeld

In response to

Browse pgsql-de-allgemein by date

  From Date Subject
Next Message Andreas Tille 2012-05-04 20:09:48 Wie kann man newlines in die Ausgabe einfügen
Previous Message Andreas Kretschmer 2012-03-24 19:48:59 Re: Hardware-Frage