maintenance_work_mem? shared_buffers? Wieviel Speicher?

Okay, nachmals vielen Dank :slight_smile: Bei maintenance_work_mem wurde in vielen Foren vorgeschlagen das so einzustellen: “Gesamter RAM des Systems/8” Das erscheint mir etwas viel^^. Aber auf dem Server läuft ja nur Postgre. Von daher geht das denk ich mal. Was meinst du? Passt die Formel so?

Um mit David Fetter zu sprechen: TIAS.
( Try It And See )


Andreas

Okay, :smiley: Genauso mit work_mem: Gesamter RAM/max_connections. Da es bei mir nicht viele sind, ist das alles ziemlich hoch. Aber naja, ich werds prüfen, wenn er richtig produktiv geht. Hier ist der Link mit den Formeln:

HOWTO : Performance tuning for PostgreSQL on Ubuntu/Debian « Samiux’s Blog

das ist quatsch.

Andreas

fsync recommended “off”

Das Blogposting ist nicht wert überhaupt weiter zu lesen.

Hab ich auch nicht gemacht^^

Jetzt hab ich ein weiteres Problem:

Die Anwendung “Teamcity” loggt wirklich alles. Also wirklich ALLES. Jedes einzelne Select, INSERT Befehl wird unter pg_log geloggt. Innerhalb von nichtmal 5min. wächst das Log auf eine Größe von ~300MB. log_truncate_on_rotation ist auf “on” gestellt und log_rotation_size wurde eigentlich auf 5MB gesetzt. Kann man das so konfigurieren, dass NUR Errors geloggt werden? Ich war heute nachmittag richtig erschrocken, als das Log eine Größe von 2,5GB hat. Und das nur in ~4h^^
weitere Einstellungen, die ich gesetzt habe:

log_destination = ‘stderr’

logging_collector = on

client_min_messages = error

log_min_messages = error

log_min_error_statement = error

log_min_duration_statement = -1

log_connections = on

log_disconnections = on

Könnt ihr mir bitte helfen :frowning:

Auf den ersten Blick scheint das okay zu sein - aber eine Anwendung kann per Verbindung/Session auch die Werte überschreiben.

Also, mach mal psql auf, mache ein select version(), und gugge, ob das auch im Log landed.



Andreas

Also das hier muss im Log stehen?:

version

PostgreSQL 9.1.3 on x86_64-suse-linux-gnu, compiled by gcc (SUSE Linux) 4.6.2, 64-bit
(1 row)

EDIT: ACHSO. Ja, es taucht im Log auf

Es sollte halt NICHT im Log stehen. Wenn es nicht drin ist, ist PG passend konfiguriert und nur die Applikation überscheibt die Einstellungen.
Dann mußt dort suchen, ansonsten in der PG-Config.



Du kannst auch mit “show all” in psql schauen, wie die Werte gesetzt sind, die mit dem Logging zusammenhängen

Achte auch auf log_statement …

Andreas

log_autovacuum_min_duration | -1
log_checkpoints | off
log_connections | on
log_destination | stderr
log_directory | pg_log
log_disconnections | on
log_duration | off
log_error_verbosity | default
log_executor_stats | off
log_file_mode | 0600
log_filename | postgresql-%Y-%m-%d.log
log_hostname | on
log_line_prefix | %t %d %u
log_lock_waits | off
log_min_duration_statement | 0
log_min_error_statement | error
log_min_messages | warning
log_parser_stats | off
log_planner_stats | off
log_rotation_age | 1d
log_rotation_size | 5MB
log_statement | none
log_statement_stats | off
log_temp_files | -1
log_timezone | posixrules
log_truncate_on_rotation | off
logging_collector | on

Vielen Dank für den Tipp. Ich verstehe das nicht. Eingentlich loggt der doch keine Statements oder? Da steht doch none.

Da ist dein Problem.

Ja danke… Das hatte ich schon auf -1 gesetzt, aber ich habe nicht gewusst, dass man den PostgreSQL Server dienst reloaden muss^^ Normalerweise steht das doch immer daneben^^ Aber jetzt ist wieder alles gut :slight_smile:

Fein.

akretschmer: schreibst bitte eine Rechnung?

Wie Rechnung? :smiley:

Na Rechnung halt. Sag mir doch mal Deine Kundennummer bei uns :wink:

Andreas

Hallo liebes PG-Forum

passender Thread für mein Problem. Ich bin in den letzten Monaten häufiger hier gelandet und war immer kurz davor viele Fragen loszulassen, nur haben sie sich meist von selbst geklärt. Aber gerade bin ich das erste Mal vollkommen ratlos. Bin Student der Geoinformatik und mitten in der Masterarbeit. Das Thema ist die Portierung einer Datenbank für 3D-Stadtmodelle im CityGML-Format von Oracle nach PostgreSQL/PostGIS. Dazu musste auch eine Importer/Exporter-Software in Java umprogrammiert werden. Hat alles soweit geklappt.

Nun teste ich meine Version gegen die Oracle-Version, d.h. ich im- und exportiere Datensätze mit dem Java-Tool und notiere die benötigte Zeit. Das Tool macht folgendes. Es parst zunächst die xml-artigen Datensätze, wandelt sie in Java-Objekte um, die dann in PreparedStatements an die Datenbank geschickt werden. Es sind nur Inserts. Die Datenbank ist schon vorhanden, aber leer. Den Export könnt ihr euch ja denken.

Die Tests verliefen ganz gut bisher. PostgreSQL war selbst mit Default-Einstellungen oft schneller als Oracle. Ich verwende ne 32-Bit-Installation auf einem Win7 64-Bit OS, 6 Kerne, 24 GB RAM. Auf dem selben Server läuft auch die Oracle-Installation (64-Bit). Das Tests steuere ich über einen anderen Rechner des Netzwerkes.

Nun zum Problem: Ich war schon ganz gespannt, wie die Ergebnisse ausfallen würden, wenn ich conf-Datei etwas tune. Ich habe in vielen Quellen recherchiert und anhand der Empfehlungen an etlichen Schrauben gedreht (s_buf wahlweise auf 512MB oder 1024MB – mehr geht nicht, temp_buf und wal_buf auf 16MB, w_mem auf 24MB, m_w_mem auf 512MB, e_c_size auf 4GB, checkpoint_segments auf 32 … um mal die wichtigsten zu nennen). Das Ergebnis: Im- und Exporte sind langsamer geworden. Wenn ich alles wieder zurücksetze, hab ich die alten Bestzeiten wieder. Habe ich irgendwo übertrieben? Außer mir arbeitet sonst niemand im Netzwerk (weil Wochenende). Irgendeine Veränderung scheint eher suboptimal zu sein. Ich habe allerdings keine Zeit dies Stück für Stück zu prüfen.

Es ist nicht mehr sehr entscheidend für den Ausgang der Arbeit. Ich würde den ausgebliebenen Erfolg beim Konfigurieren nur irgendwie begründen wollen. Hab nur wirklich keinen Schimmer, woran es liegen könnte. Stecke in der Thematik auch erst seit einem halben Jahr drin.

Ich hoffe, ihr könnt meinen Fall in etwa nachvollziehen. Vermutungen reichen mir völlig. Danke schon mal.

Gruß, Felix

Aus der Ferne schwer einzuschätzen. Ressourcen, die Du dem PG gibts, fehlen vielleicht dem ORA. Du mußt versuchen zu ermitteln, was der Flaschenhals ist. Windows als Server-OS ist vielleicht auch nicht die beste Wahl …

Du könntest/solltest versuchen, aus Insert’s eher ein COPY zu machen, ist flotter.

Andreas

Hey, danke für die schnelle Antwort. Ja, irgendwas füllt den Arbeitsspeicher bis zum Anschlag, nur bin ich mir seit heute morgen nicht mehr sicher, ob es Postgres ist, denn mit einmal sind wieder 6GB als free ausgezeichnet, die Einstellungen aber diesselben. Tja, wenn ich doch mehr Ahnung von sowas hätte :-/. Das Tunen zeigt jetzt seine Wirkung, wenn auch nur geringfügig. Copy ist mir auch schon oft begegnet. Werde ich mal testen.

Eine spezielle Frage habe ich noch bzgl. Rechnerprozesse. Ich überwache meine Tests mit dem Process Monitor von Win7. Mir ist aufgefallen, dass Oracle nur einen Prozess hat, indem alles abläuft, die Thread-Anzahl varriert etc… PostgreSQL bildet viele Prozesse aus. Der Hauptprozess hat 4 Threads … alle weiteren Prozesse laufen mit max. 3 Threads. Sollten mehr benötigt werden, entstehen neue Prozesse. Mein Tool arbeitet übrigens mit Multithreading. Wurde PostgreSQL absichtlich so programmiert, weil es irgendwie flexibler und schonender für den Rechner ist? Könnte ich mir gut vorstellen. Kann man dazu irgendwo etwas nachlesen? Werde mal die Mailing Listen durchstöbern bzw. dort nachfragen…

Bitte.

Eine spezielle Frage habe ich noch bzgl. Rechnerprozesse. Ich überwache meine Tests mit dem Process Monitor von Win7. Mir ist aufgefallen, dass Oracle nur einen Prozess hat, indem alles abläuft, die Thread-Anzahl varriert etc… PostgreSQL bildet viele Prozesse aus. Der Hauptprozess hat 4 Threads … alle weiteren Prozesse laufen mit max. 3 Threads. Sollten mehr benötigt werden, entstehen neue Prozesse. Mein Tool arbeitet übrigens mit Multithreading. Wurde PostgreSQL absichtlich so programmiert, weil es irgendwie flexibler und schonender für den Rechner ist? Könnte ich mir gut vorstellen. Kann man dazu irgendwo etwas nachlesen? Werde mal die Mailing Listen durchstöbern bzw. dort nachfragen…

Ja, nachzulesen im guten alten Quelltext :wink:

Aber stimmt: ORA und MySQL machen Threads, PG neue Prozesse. Diskussionen dazu gab es wie Sand am Meer. Scheint aber besser zu sein, auf großen Trümmern skaliert PG besser als z.B. MySQL. PG 9.2 skaliert gerade hoch - auch bis zu 64 Cores.

Andreas