Moin,
am Wochenende habe ich log_checkpoints aktiviert.
Eigentlich wollte ich gestern Abend noch die Logs auswerten und mich hier melden, aber es kommt ja immer etwas dazwischen.
Darum habe ich mir jetzt die Logs angesehen aber das wirft bei mir nur noch mehr Fragen auf.
1. Bekommen wir da die Meldung: Consider increasing the configuration parameter "checkpoint_segments".
Dieser steht auf Default. Und wenn ich in Abschnitt zu den checkpoint_segments aus dem Buch richtig verstanden habe,
dürften in dem Unterverzeichnis pg_xlog 3 Dateien mit einer Größe von 16MB sein...
Bei uns sind da 12 Dateien drin, keine älter als 30 Minuten.
Wie kommt das?
Ist es wirklich Notwendig checkpoint_segments zu erhöhen, wenn er eh schon mehr als drei hat?
2. Hier mal ein Auszug aus den Logs, bezüglich checkpoint:
2010-03-15 11:25:36.161 CETLOG: checkpoint starting: time
.
---
2010-03-15 11:25:51.922 CETLOG: duration: 0.029 ms
2010-03-15 11:25:51.923 CETLOG: duration: 1.087 ms
2010-03-15 11:25:51.924 CETLOG: duration: 0.277 ms
.
---
2010-03-15 11:25:52.078 CETLOG: duration: 9.546 ms
2010-03-15 11:25:52.080 CETLOG: duration: 0.372 ms
2010-03-15 11:25:52.080 CETLOG: duration: 0.051 ms
.
2010-03-15 11:25:54.456 CETLOG: checkpoint complete: wrote 90 buffers (0.1%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=18.141 s, sync=0.069 s, total=18.295 s
.
---
2010-03-15 11:25:57.564 CETLOG: duration: 0.040 ms
2010-03-15 11:25:57.594 CETLOG: duration: 24.535 ms
2010-03-15 11:25:57.596 CETLOG: duration: 1.996 ms
Sowohl zwischen den checkpoints also auch währenddessen, gönnt sich der Server mal eine langsame Query.
Was mich auch irritiert: Wenn jetzt für eine Query ein mal duration da stehen würde, könnte ich das nachvollziehen.
Aber da steht das duration nun drei mal. (Anstellt von --- stehen beliebige Querys. )
3. Ich habe noch mal mit hdparm die Platten-Geschwindigkeit getestet. Nicht ein mal gab's weniger als 100 MB/sec.
Damit kann ich doch die Platten als Defekt endgültig ausschließen und ich muss mir noch mal die Systemlogs zu gemüte führen.
Vielleicht habe ich da ja doch etwas übersehen.
Jedenfalls hatten wir jetzt über eine Woche kein Segfault mehr. Ohne Hardwarewechsel und trotz großer Last.
Allein das Logfile von Gestern waren 1,03 GB Text...
4. Während ich den Text hier verfasste und zwischendurch noch ein wenig Helpdesk machte, hat sich was in pg_xlog getan:
Nur noch acht Dateien, sechs davon sind ca. eine Stunde alt und zwei nur ein paar Minuten.
5. Ist der Punkt in den Millisekunden nun Tausenderzeichen oder Komma?
Beim checkpoint siehts mir nach einem Komma aus...
Trifft das dann auch auf die ms bei duration zu?
Wenn ja, wäre das alles ja nicht soooo schlimm. Dann hätte der letzte Block ja nur 0+25+2 ms gearbeitet.
Gruß
Björn
Lass es mich so beschreiben:
Ein CHECKPOINT ist ein Punkt, an dem alle geänderten Daten auf die Platte geschrieben wurden. Das ist also ein Punkt, an dem der Stand auf der Festplatte konsistent war.
Stürzt die Datenbank ab (weil z. B. der Strom ausfällt), sucht die Datenbank den letzten CHECKPOINT und spielt von dort aus alle Änderungen aus den Transaktionslogs noch mal ein.
Änderungen werden von der Datenbank zwei Mal geschrieben:
1) In das Transaktionslog. Kontinuierlich. Beim COMMIT stellt die Datenbank sicher, dass diese Informationen wirklich auf der Festplatte sind.
2) In die geänderten Speicherseiten. Diese werden nur ab und zu mal auf die Festplatte geschrieben, da a) weitere Änderungen in der gleichen Speicherseite vorkommen können und b) die Änderungen über das Transaktionslog nachvollziehbar sind.
Das bedeutet nun: bei einem CHECKPOINT müssen alle geänderten Speicherseiten auf die Festplatte geschrieben werden. Bei 16 GB RAM und 1/4 RAM für PostgreSQL sind das theoretisch 4 GB Änderungen. Einen Teil der Arbeit übernimmt der Background-Writer, aber nicht alles. Alles in allem ist ein CHECKPOINT immer sehr I/O-lastig, zumindest bei einer Datenbank, in der sich viel ändert.
So, jetzt spiele mal gedanklich folgendes Szenario durch: du hast 3 Transaktionslogs. Wenn das 3. voll ist, schreibt PostgreSQL einen CHECKPOINT, alle geänderten Daten wandern auf die Platte und dann können die alten Logfiles weggeworden/wiederverwendet/überschrieben werden - der letzte gültige Stand ist dieser CHECKPOINT. Hast du jetzt 16 oder 32 Transaktionslogs, wird die Zeit zwischen zwei CHECKPOINT größer - und geänderte Speicherseiten müssen weniger häufig auf die Platte geschrieben werden. Das macht alles in allem weniger I/O-Last.
Aber: nichts gibt es umsonst: die größere Anzahl Transaktionslogs kostet natürlich Speicherplatz. Außerdem dauert ein Recovery beim Neustart länger, da zuerst der letzte CHECKPOINT gesucht wird und dann von dort aus alle Änderungen noch mal eingespielt werden.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Gut, was kannst du machen:
- dein Debugging etwas hochdrehen
- log_min_duration_statement passend setzen
- Overcommitment im Betriebssystem ausschalten
- dirty_background_ratio im Betriebssystem auf 0 stellen (wichtig)
- den Background Writer anpassen
Das hört sich aber so an, als sollte man mal einen genauen Blick auf dieses System werfen und das passend für den Anwendungszweck konfigurieren.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Okay,
jetzt habe ich dafür eine erfreuliche Nachricht:
Ich darf bei Null anfangen!
Habe soeben vier neue Platte, 3ware-RAID - Controller und auch den Rest der notwendigen Hardware auf den Tisch bekommen und darf nun einen komplett neuen DB-Server aufbauen.
Quad Core, 4GB RAM...
Die Anforderungen: Reiner DB-Server für Postgres.
OS: Debian Lenny
Die Lenny-Installation läuft bereits.
Aber die Postgres-Konfig ist jetzt ja quasi bei Null...
Bin also für jeden Vorschlag offen.
Meine Ideen:
shared_buffers = 1024MB
work_mem = 8MB
temp_buffers = 8MB
Debugging hochschrauben.
log_checkpoints aktivieren
ads' vorschläge werde ich mir auch noch genauer ansehen.
Ja, als Start ist das schon mal nicht schlecht. Dann mal schauen, wie das im laufenden Betrieb aussieht.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen