Hatte hier schonmal ein ähnliches Problem: http://www.pg-forum.de/allgemeines/2...ry-tables.html
Hallo,
ich habe heute mal wiederdurchgelesen. Dabei fand ich folgenden Stichpunkt:PostgreSQL optimieren
CLT 2010 – 13.-14.03.2010
Andreas ’ads’ Scherbaum
Web: http://andreas.scherbaum.la/
E-Mail: andreas[at]scherbaum.biz
PGP: 9F67 73D3 43AA B30E CA8F 56E5 3002 8D24 4813 B5FE
13.-14.03.2010
genug RAM haben wir schonmal (4GB) - nur leider weiß ich nicht wie ich die Tabellen da rein bekomme. Habe hier schonmal im Forum gesucht aber leider kann ich nicht nach dem Wort "RAM" suchen (es ist scheinbar zu kurz).Soviel RAM wie notwendig: die wichtigen Tabellen/Daten
sollen komplett im RAM liegen
Ich nutze PostgreSQL Version 8.2 unter windows xp.
MfG T
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Danke für das Zitieren meines Vortrags ;-)
Also, gemeint ist damit: optimal ist es, wenn du soviel Hauptspeicher hast, dass deine Datenbank da hinein passt.
Das skaliert allerdings auch nur begrenzt, für kleine Datenbanken (sagen wir unter ungefähr 1 GB Größe) ist das jedoch in Ordnung.
Der wichtige Parameter dafür ist "shared_buffers".
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
Ich danke auch für die Antworten
Das hatte ich auch bei meiner Suche gefunden, nur war ich damit nicht so recht zufrieden, weil 'ads' in seiner altuellen Doku geschrieben hatte:
...und wenn das 'ads' schon sagt, dann MUSS es ja wohl gehen!Soviel RAM wie notwendig: die wichtigen Tabellen/Daten sollen komplett im RAM liegen
... weiter im Text:
Könntet ihr vorschlagen, welche Konfiguration für 4GB (relativ) optimal ist?
Sollte man lieber ein RAM-Disk (mit wieviel MB/GB?) anlegen und Tablespaces nutzen,
oder shared_buffers so hoch schrauben wie es geht?
Heißt das soviel wie
"Solange deine DBs nicht größer als 1GB werden, erhöhe den Wert für 'shared_buffers'.
Wenn sie jedoch größer werden, solltest du eine RAM-Disk anlegen und Tablespaces nutzen." ?
Dann würde ich mich noch für Beziehungen von 'shared_buffers' interessieren.
Gibts es die?
Ich denke da Beispielsweise an soetwas:
Gibt es noch weitere Einstellungen, die Standartmäßig Deaktiviert sind bzw. einen (viel) zu kleinen Standartwert haben, um mehr performace zu bekommen?'temp_buffers' = 'shared_buffers' / 32
'work_mem' = 'shared_buffers' /30
Ich denke da zum Beispiel an die ganzen
'cpu_tuple_cost', 'cpu_...', 'effective_cache_size', 'geqo'
-Werte?
MfG
Habe ich irgendwo etwas von Ramdisk geschrieben?
Um dieses Problem gleich mal zu erschlagen: was passiert, wenn dein Rechner abstürzt? Was ist dann mit den Daten in der Ramdisk?
Genau, die sind weg! Zusätzlich hat PostgreSQL danach sinnlose Pointer in seinen Systemtabellen, die in eine Ramdisk zeigen, die es nicht mehr gibt.
Also vergiss das Thema "Ramdisk" bitte wieder.
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
So, und jetzt mal zur spannenden Frage: wie groß ist deine Datenbank?
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
20100111.backup 6.587 KB
20100310.backup 26.382 KB
20100415.backup 80.516 KB
Das soll zeigen wie sie dieses Jahr bis jetzt gewachsen ist.
Im Moment ist sie noch klein, aber sie wächst eben ständig...
Nebenbemerkung: Du solltest dir in deiner Datenbank Gedanken über Partitionierung machen.
Gut, nun zum Problem: deine Datenbank ist größer als dein verfügbarer Hauptspeicher. Demzufolge wird dir auch eine Ramdisk nichts bringen, um alle Daten im Speicher vorzuhalten. Das nur mal als Anmerkung.
Wenn du 4 GB Speicher hast, starte mal mit 1 GB Shared Memory und beobachte die Auslastung der Datenbank. Außerdem soltest du die Free Space Map anpassen (oder gleich mal auf 8.4 wechseln). Ein VACUUM VERBOSE Aufruf ohne weitere Parameter sagt dir am Ende, ob deine FSM-Einstellungen passen.
effective_cache_size kannst du auf ungefähr 2 GB setzen, das dürfte hinkommen, wenn auf der Maschine nichts weiter läuft.
maintenance_work_mem kannst du hochsetzen. Denke mal so 128 MB dürften ein guter Wert sein.
work_mem und temp_buffers hängen nicht von deinem Hauptspeicher sondern vom Workload ab. Dazu kann man also keine pauschalen Aussagen treffen.
Die *cost* fässt du bitte nicht an, bevor du nicht weisst, was du da tust ;-)
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
temp_buffers ist der Speicher, der nur für temporäre Tabellen genutzt wird? wenn ich keine habe, kann ich es deaktiviert lassen, ja?
work_mem .... hm keine ahnung so richtig... vielleicht der Speicher für die Erstellungen von Abfragen-Ausgaben (also Datenanzeige und so?) ??? kann ich den gleich setzen mit maintenance_work_mem, also 128MB?
und was ist nun mit den 'geqo's ? "genetec query optimization" hört sich doch nicht schlecht an, oder?? sollte ich das aktivieren und auf 'on' setzen? der nachteil wäre dann wieder dass ich dann wieder 6 geqo_Einstellungen habe, bei denen ich nicht weiß, was ich einstellen soll oder was die direkt bewirken ...
MfG!
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen