Re: Hardware-Frage
Susanne Ebrecht <[email protected]>
| Newsgroups | gmane.comp.db.postgresql.german |
|---|---|
| Message-ID | <[email protected]> |
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 -- Sent via pgsql-de-allgemein mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-de-allgemein