Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-de-allgemein by date

Next:From: Andreas TilleDate: 2012-05-04 20:09:48
Subject: Wie kann man newlines in di?==?iso-8859-1?Q?e Ausgabe einfügen
Previous:From: Andreas KretschmerDate: 2012-03-24 19:48:59
Subject: Re: Hardware-Frage

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group