Es handelt sich um einen Terminalserver. in der DB gibt es 2 Datenbanken:
mo_koenig und test
Wegen des Vergleichs:
wir haben einen XEON Server mit 4 GB Ram
Beim Kunden steht ein Dual Xenon mit etwa 36 GB RAM
Raid yx (5?) Verbund für Die Daten und Raid xy (1?) fürs BS.
Es geht um eine Abfrage aller offenen Kaufverträge.
Diese Abfrage dauert mit unserem Programm bei uns ca. 2 sekunden
Beim Kunden über 3 minuten...
Amilandverbindungen???
Wo???
Zum thema testen:
Leider wird bei uns erst gemacht und dann später gefragt ob das sinnvoll ist
Wird gleich gemacht.log_min_duration_statement hochsetzen! Auf irgendwas um die 500 (Millisekunden). Dann das Logfile beobachten.
Was für ein OS? Config dafür angepaßt?
RAID5 ist eher nicht performant...Raid yx (5?) Verbund für Die Daten und Raid xy (1?) fürs BS.
Kommt mir doch irgendwie bekannt wor ...Es geht um eine Abfrage aller offenen Kaufverträge.
Diese Abfrage dauert mit unserem Programm bei uns ca. 2 sekunden
140.100.100.252Amilandverbindungen???
Wo???
Code:kretschmer@tux:~$ whois 140.100.100.252 OrgName: Navy Network Information Center (NNIC) OrgID: NNICN-1 Address: 130 West Ave Address: Suite D City: Pensacola StateProv: FL PostalCode: 32508 Country: US
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Wegen der IP:
unser internes netz ist 192.168.44.xxx beim Kunden hingegen ist das interne Netz 140.100.100.xxx
Ich bin über VPN beim Kunden angebunden.
OS ist OpenSuse 11.2;
PG 8.4.1
config wie folgt:
Code:listen_addresses = '*' # what IP address(es) to listen on; port = 5432 # (change requires restart) max_connections = 100 # (change requires restart) superuser_reserved_connections = 3 # (change requires restart) shared_buffers = 8000MB # min 128kB # (change requires restart) temp_buffers = 16MB # min 800kB work_mem = 2MB # min 64kB maintenance_work_mem = 2000MB # min 1MB fsync = on # turns forced synchronization on or off synchronous_commit = on # immediate fsync at commit full_page_writes = on # recover from partial page writes wal_buffers = 64kB # min 32kB # (change requires restart) wal_writer_delay = 200ms # 1-10000 milliseconds checkpoint_segments = 16 # in logfile segments, min 1, 16MB each checkpoint_timeout = 5min # range 30s-1h checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0 checkpoint_warning = 30s # 0 disables effective_cache_size = 3000MB log_destination = 'stderr' # Valid values are combinations of logging_collector = on # Enable capturing of stderr and csvlog log_directory = 'pg_log' # directory where log files are written, # can be absolute or relative to PGDATA log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern, log_truncate_on_rotation = on # If on, an existing log file of the log_rotation_age = 3d # Automatic rotation of logfiles will log_rotation_size = 0 # Automatic rotation of logfiles will client_min_messages = notice # values in order of decreasing detail: log_min_messages = notice # values in order of decreasing detail: log_min_error_statement = error # values in order of decreasing detail: log_min_duration_statement = 2500 # -1 is disabled, 0 logs all statements log_checkpoints = on log_connections = on log_disconnections = on log_line_prefix = '%t %h ' # special values: log_temp_files = 0 # log temporary files equal or larger update_process_title = on log_statement_stats = off autovacuum = on # Enable autovacuum subprocess? 'on' # requires track_counts to also be on. log_autovacuum_min_duration = 0 # -1 disables, 0 logs all actions and autovacuum_max_workers = 3 # max number of autovacuum subprocesses autovacuum_naptime = 1min # time between autovacuum runs autovacuum_vacuum_threshold = 50 # min number of row updates before # vacuum autovacuum_analyze_threshold = 50 # min number of row updates before # analyze autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum # (change requires restart) autovacuum_vacuum_cost_delay = 20ms # default vacuum cost delay for # autovacuum, in milliseconds; # -1 means use vacuum_cost_delay autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for # autovacuum, -1 means use # vacuum_cost_limit datestyle = 'GERMAN, dmy' client_encoding = UTF8 # actually, defaults to database lc_messages = 'de_DE.UTF-8' # locale for system error message # strings lc_monetary = 'de_DE.UTF-8' # locale for monetary formatting lc_numeric = 'de_DE.UTF-8' # locale for number formatting lc_time = 'de_DE.UTF-8' # locale for time formatting default_text_search_config = 'pg_catalog.german'
Richte Ihnen aus, daß es Idioten sind. Sie verwenden ein nicht Ihnen gehörendes Netz. Irgendwann verwendet ein Dumpfbatz mal 74.125.0.0/24 und wundert sich, daß google.de nicht funzt.
Aktuell ist 8.4.2.OS ist OpenSuse 11.2;
PG 8.4.1
Sind das 64 Bit Versionen? Für z.B.
brauchst Du ein 64 Bit-System, mit 32 Bit ist das nicht adressierbar.
config wie folgt:
Code:listen_addresses = '*' # what IP address(es) to listen on; shared_buffers = 8000MB # min 128kB # (change requires restart)
effective_cache_size = 3000MB
Dieser Wert ist für den Planner bestimmt, damit er weiß, wie groß shared_buffers + Cache des OS ist. Wenn Du shared_buffers 8 GByte hast und effective_cache_size ist 3 GByte, dann hat das OS rechnerisch - 5 GByte Cache. Du erkennst den Bullshit?
Man könnte noch einige andere Werte anpassen, work_mem erscheint mir als zu geizig z.B., und man könnte manche Dinge loggen (temp_files).
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Darf ich eine Schulung beim Kunden einwerfen? ;-)
akretschmer hat Recht, da ist einiges im Argen. Nicht nur bei der Datenbank.
So, ich mache mich mal los, CeBIT Stand aufbauen ...
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
Ok...
Ich glaube wir kommen bal mal auf die Schulungsgeschichte zu sprechen...
Vielen Dank aber schon mal bis hierhin...
Das BS ist 64 Bit.
Schande über mich. Leider nicht.Du erkennst den Bullshit?
Die Administration der DB ist nicht mein Hauptgebiet. Ich soll da eher "unterstützend" eingreifen...
Wie wäre denn ein vernünftiges Verhältnis:
RAM = 32 GB
CPU = Intel(R) Xeon(R) CPU E5530 @ 2.40GHz
cat /proc/cpuinfo
gibt 16 mal den Eintrag meiner CPU???
Du definierst 8 GByte shared_mem und verkündest dem Planner, es gäbe 3 GByte insgesamt an Cache. Effektive_cache ist aber shared_mem PLUS dem Cache des OS. Die Umstellung einer Gleichnung nach einer Unbekannten, hier den Cache des OS, schaffst Du?Code:Dieser Wert ist für den Planner bestimmt, damit er weiß, wie groß shared_buffers + Cache des OS ist. Wenn Du shared_buffers 8 GByte hast und effective_cache_size ist 3 GByte, dann hat das OS rechnerisch - 5 GByte Cache.
Wenn Du bei 32 GByte 8 Gyte shared_mem definierst, dann braucht OS und PG noch a bissl was, so daß vielleicht 20 GByte an Cache für das OS bleiben. Ads kann das sicher besser als ich kalkulieren, aber Deine 8 GByte shared_mem PLUS die geschätzten 20 GByte Cache vom OS sind dann 28 GByte effective_cache_size.
Andererseits hast Du nur 2 MByte work_mem definiert. Dieser ist aber sehr wichtig für z.B. Sortieroperationen, JOINS etc. Aber Vorsicht: work_mem gilt bei Abfragen pro Operation. Wenn Du also komplexe Abfragen hast, kann das pro Abfrage mehrfach allokiert werden. Und das je User. Also, work_men erhöhen, aber vorsichtig. Vielleicht auf 8 MByte. Und dann schauen, was in den Plänen steht (EXPLAIN ANALYSE) und auf Ausgaben wie "Sort Method: quicksort Memory: 17kB" achten. Wenn dort FILE oder sowas steht, dann wird extern sortiert, in temp. Dateien. Wenn Du das Anlegen von temp. Dateien loggst, dann sieht man das auch. Es gibt auch noch auto_explain (CONTRIB), was für Performance-Analyse recht nützlich ist.
PostgreSQL: Documentation: Manuals: PostgreSQL 8.4: auto_explain
Generell kann man sagen, daß man nicht generall sagen kann, wie eine optimale Konfiguration ausschaut. Das muß man probieren und beobachten.
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Fogende Einträge gilt es also vernünftig zu definiern:
shared_buffers bzw. effective_cache_size Richtig? (Bei uns zur Zeit shared_buffers=8000MB und effective_cache_size=3000MB)
Da ich 32 GB RAM habe und der DB-Server zu 90 als DB-Server läuft:
Effectivecache = sharedmem + OScache
3000 = 8000 + (-x)
Ahhh!!! Jetzt erkenne ich den Bullshit...
Also:
Ich habe in der ini jetzt den effective_cache_size von 3000MB auf 28000MB vergrößert
und den work_mem von 2MB auf 8MB erhöht.
Heute abend wird dann der Server neu gestartet mal sehen was passiert...
Vielen Dank!
Auszug aus der Log im pg_log Verzeichnis:
Ich darf davon ausgehen, dass die Eintzräge: "LOG: temporäre Datei:xxx" nix gutes bedeuten?Code:2010-03-01 12:00:53 CET 140.100.100.252 LOG: temporäre Datei: Pfad »base/pgsql_tmp/pgsql_tmp811.46«, Größe 19280 2010-03-01 12:00:53 CET 140.100.100.252 ANWEISUNG: declare "SQL_CUR05CF3188" cursor with hold for SELECT a.LSARTIKELTEXT,a.LSARTIKELTEXTKURZ,a.NARTIKELARTKZ,a.NARTIKELGRUPPEKZ,a.NARTIKELKEY,a.NKOMMUNIKARTKZ,a.NLIEFEKEY,a.NLIEFEPROGRAMMKEY,a.NMANDANTKEY,a.NMWSTKZ,a.NREKLAAGENTURKEY,a.NSORTIMENTKZ,a.NSTATISTIKKZ,a.NWARENGRUPPEKZ,a.SARTIKBEZEICHNUNG,a.SARTIKELARTKZ,a.SARTIKELGESPERRT,a.SARTIKELGRUPPEKZ,a.SARTIKELIDENT,a.SBESTELLSPERRE,a.SKATALOG,a.SLIEFERANTGESPERRT,a.SLIEFERANTIDENT,a.SMODELLHERSTELLER,a.SMODELLINTERN,a.SMWSTKZ,a.SNAME1,a.SOHNEBESTAND,a.SPFAD,a.SPROGBEZEICHNUNG,a.SPROGRAMMIDENT,a.SSORTIMENTKZ,a.SSTATISTIKKZ,a.SSTUECKARTIKEL,a.SVERBANDNR,a.SWARENGRUPPEKZ FROM V_ARTIKLIEFEADRESS a WHERE (Upper(SARTIKELIDENT) like '116848100%' or Upper(SLIEFERANTIDENT) like '116848100%' or Upper(SNAME1) like '116848100%' or Upper(SARTIKBEZEICHNUNG) like '116848100%' or Upper(SMODELLHERSTELLER) like '116848100%' or Upper(SMODELLINTERN) like '116848100%' or Upper(SPROGBEZEICHNUNG) like '116848100%' or Upper(LSARTIKELTEXTKURZ) like '%116848100%' or Upper(SVERBANDNR) like '116848100%' ) AND ( ( sartikelgesperrt = '0' ) OR ( sartikelgesperrt IS NULL ) ) and NMANDANTKEY = 1 ;fetch 20000 in "SQL_CUR05CF3188" 2010-03-01 12:00:53 CET 140.100.100.252 LOG: temporäre Datei: Pfad »base/pgsql_tmp/pgsql_tmp811.44«, Größe 1188788 2010-03-01 12:00:53 CET 140.100.100.252 ANWEISUNG: declare "SQL_CUR05CF3188" cursor with hold for SELECT a.LSARTIKELTEXT,a.LSARTIKELTEXTKURZ,a.NARTIKELARTKZ,a.NARTIKELGRUPPEKZ,a.NARTIKELKEY,a.NKOMMUNIKARTKZ,a.NLIEFEKEY,a.NLIEFEPROGRAMMKEY,a.NMANDANTKEY,a.NMWSTKZ,a.NREKLAAGENTURKEY,a.NSORTIMENTKZ,a.NSTATISTIKKZ,a.NWARENGRUPPEKZ,a.SARTIKBEZEICHNUNG,a.SARTIKELARTKZ,a.SARTIKELGESPERRT,a.SARTIKELGRUPPEKZ,a.SARTIKELIDENT,a.SBESTELLSPERRE,a.SKATALOG,a.SLIEFERANTGESPERRT,a.SLIEFERANTIDENT,a.SMODELLHERSTELLER,a.SMODELLINTERN,a.SMWSTKZ,a.SNAME1,a.SOHNEBESTAND,a.SPFAD,a.SPROGBEZEICHNUNG,a.SPROGRAMMIDENT,a.SSORTIMENTKZ,a.SSTATISTIKKZ,a.SSTUECKARTIKEL,a.SVERBANDNR,a.SWARENGRUPPEKZ FROM V_ARTIKLIEFEADRESS a WHERE (Upper(SARTIKELIDENT) like '116848100%' or Upper(SLIEFERANTIDENT) like '116848100%' or Upper(SNAME1) like '116848100%' or Upper(SARTIKBEZEICHNUNG) like '116848100%' or Upper(SMODELLHERSTELLER) like '116848100%' or Upper(SMODELLINTERN) like '116848100%' or Upper(SPROGBEZEICHNUNG) like '116848100%' or Upper(LSARTIKELTEXTKURZ) like '%116848100%' or Upper(SVERBANDNR) like '116848100%' ) AND ( ( sartikelgesperrt = '0' ) OR ( sartikelgesperrt IS NULL ) ) and NMANDANTKEY = 1 ;fetch 20000 in "SQL_CUR05CF3188" 2010-03-01 12:00:53 CET 140.100.100.252 LOG: temporäre Datei: Pfad »base/pgsql_tmp/pgsql_tmp811.45«, Größe 19200 2010-03-01 12:00:53 CET 140.100.100.252 ANWEISUNG: declare "SQL_CUR05CF3188" cursor with hold for SELECT a.LSARTIKELTEXT,a.LSARTIKELTEXTKURZ,a.NARTIKELARTKZ,a.NARTIKELGRUPPEKZ,a.NARTIKELKEY,a.NKOMMUNIKARTKZ,a.NLIEFEKEY,a.NLIEFEPROGRAMMKEY,a.NMANDANTKEY,a.NMWSTKZ,a.NREKLAAGENTURKEY,a.NSORTIMENTKZ,a.NSTATISTIKKZ,a.NWARENGRUPPEKZ,a.SARTIKBEZEICHNUNG,a.SARTIKELARTKZ,a.SARTIKELGESPERRT,a.SARTIKELGRUPPEKZ,a.SARTIKELIDENT,a.SBESTELLSPERRE,a.SKATALOG,a.SLIEFERANTGESPERRT,a.SLIEFERANTIDENT,a.SMODELLHERSTELLER,a.SMODELLINTERN,a.SMWSTKZ,a.SNAME1,a.SOHNEBESTAND,a.SPFAD,a.SPROGBEZEICHNUNG,a.SPROGRAMMIDENT,a.SSORTIMENTKZ,a.SSTATISTIKKZ,a.SSTUECKARTIKEL,a.SVERBANDNR,a.SWARENGRUPPEKZ FROM V_ARTIKLIEFEADRESS a WHERE (Upper(SARTIKELIDENT) like '116848100%' or Upper(SLIEFERANTIDENT) like '116848100%' or Upper(SNAME1) like '116848100%' or Upper(SARTIKBEZEICHNUNG) like '116848100%' or Upper(SMODELLHERSTELLER) like '116848100%' or Upper(SMODELLINTERN) like '116848100%' or Upper(SPROGBEZEICHNUNG) like '116848100%' or Upper(LSARTIKELTEXTKURZ) like '%116848100%' or Upper(SVERBANDNR) like '116848100%' ) AND ( ( sartikelgesperrt = '0' ) OR ( sartikelgesperrt IS NULL ) ) and NMANDANTKEY = 1 ;fetch 20000 in "SQL_CUR05CF3188" 2010-03-01 12:00:53 CET 140.100.100.252 LOG: temporäre Datei: Pfad »base/pgsql_tmp/pgsql_tmp811.42«, Größe 1185512 2010-03-01 12:00:53 CET 140.100.100.252 ANWEISUNG: declare "SQL_CUR05CF3188" cursor with hold for SELECT a.LSARTIKELTEXT,a.LSARTIKELTEXTKURZ,a.NARTIKELARTKZ,a.NARTIKELGRUPPEKZ,a.NARTIKELKEY,a.NKOMMUNIKARTKZ,a.NLIEFEKEY,a.NLIEFEPROGRAMMKEY,a.NMANDANTKEY,a.NMWSTKZ,a.NREKLAAGENTURKEY,a.NSORTIMENTKZ,a.NSTATISTIKKZ,a.NWARENGRUPPEKZ,a.SARTIKBEZEICHNUNG,a.SARTIKELARTKZ,a.SARTIKELGESPERRT,a.SARTIKELGRUPPEKZ,a.SARTIKELIDENT,a.SBESTELLSPERRE,a.SKATALOG,a.SLIEFERANTGESPERRT,a.SLIEFERANTIDENT,a.SMODELLHERSTELLER,a.SMODELLINTERN,a.SMWSTKZ,a.SNAME1,a.SOHNEBESTAND,a.SPFAD,a.SPROGBEZEICHNUNG,a.SPROGRAMMIDENT,a.SSORTIMENTKZ,a.SSTATISTIKKZ,a.SSTUECKARTIKEL,a.SVERBANDNR,a.SWARENGRUPPEKZ FROM V_ARTIKLIEFEADRESS a WHERE (Upper(SARTIKELIDENT) like '116848100%' or Upper(SLIEFERANTIDENT) like '116848100%' or Upper(SNAME1) like '116848100%' or Upper(SARTIKBEZEICHNUNG) like '116848100%' or Upper(SMODELLHERSTELLER) like '116848100%' or Upper(SMODELLINTERN) like '116848100%' or Upper(SPROGBEZEICHNUNG) like '116848100%' or Upper(LSARTIKELTEXTKURZ) like '%116848100%' or Upper(SVERBANDNR) like '116848100%' ) AND ( ( sartikelgesperrt = '0' ) OR ( sartikelgesperrt IS NULL ) ) and NMANDANTKEY = 1 ;fetch 20000 in "SQL_CUR05CF3188" 2010-03-01 12:00:53 CET 140.100.100.252 LOG: temporäre Datei: Pfad »base/pgsql_tmp/pgsql_tmp811.47«, Größe 19280 2010-03-01 12:00:53 CET 140.100.100.252 ANWEISUNG: declare "SQL_CUR05CF3188" cursor with hold
Es sortiert also auf der Paltte in Verzeichnissen, anstatt im Arbeitsspeicher?
Geändert von ipConfig (01.03.2010 um 14:58 Uhr)
Nun ja, logge lahme Abfragen und schaue Dir diese mit explain analyse an. Dann kannst Du auch in der aktuellen Session work_mem höher setzen und erneut probieren. Das geht mit set work_mem = '8mB'; ganz easy.
Die Temp-files hier sind IMHO durch den CURSOR bedingt, nicht durch das sortieren.
Auszug aus der Log im pg_log Verzeichnis:
Ich darf davon ausgehen, dass die Eintzräge: "LOG: temporäre Datei:xxx" nix gutes bedeuten?Code:2010-03-01 12:00:53 CET 140.100.100.252 LOG: temporäre Datei: Pfad »base/pgsql_tmp/pgsql_tmp811.46«, Größe 19280 2010-03-01 12:00:53 CET 140.100.100.252 ANWEISUNG: declare "SQL_CUR05CF3188" cursor with hold for SELECT a.LSARTIKELTEXT,a.LSARTIKELTEXTKURZ,a.NARTIKELARTKZ,a.NARTIKELGRUPPEKZ,a.NARTIKELKEY,a.NKOMMUNIKARTKZ,a.NLIEFEKEY,a.NLIEFEPROGRAMMKEY,a.NMANDANTKEY,a.NMWSTKZ,a.NREKLAAGENTURKEY,a.NSORTIMENTKZ,a.NSTATISTIKKZ,a.NWARENGRUPPEKZ,a.SARTIKBEZEICHNUNG,a.SARTIKELARTKZ,a.SARTIKELGESPERRT,a.SARTIKELGRUPPEKZ,a.SARTIKELIDENT,a.SBESTELLSPERRE,a.SKATALOG,a.SLIEFERANTGESPERRT,a.SLIEFERANTIDENT,a.SMODELLHERSTELLER,a.SMODELLINTERN,a.SMWSTKZ,a.SNAME1,a.SOHNEBESTAND,a.SPFAD,a.SPROGBEZEICHNUNG,a.SPROGRAMMIDENT,a.SSORTIMENTKZ,a.SSTATISTIKKZ,a.SSTUECKARTIKEL,a.SVERBANDNR,a.SWARENGRUPPEKZ FROM V_ARTIKLIEFEADRESS a WHERE (Upper(SARTIKELIDENT) like '116848100%' or Upper(SLIEFERANTIDENT) like '116848100%' or Upper(SNAME1) like '116848100%' or Upper(SARTIKBEZEICHNUNG) like '116848100%' or Upper(SMODELLHERSTELLER) like '116848100%' or Upper(SMODELLINTERN) like '116848100%' or Upper(SPROGBEZEICHNUNG) like '116848100%' or Upper(LSARTIKELTEXTKURZ) like '%116848100%' or Upper(SVERBANDNR) like '116848100%' ) AND ( ( sartikelgesperrt = '0' ) OR ( sartikelgesperrt IS NULL ) ) and NMANDANTKEY = 1 ;fetch 20000 in "SQL_CUR05CF3188" 2010-03-01 12:00:53 CET 140.100.100.252 LOG: temporäre Datei: Pfad »base/pgsql_tmp/pgsql_tmp811.44«, Größe 1188788 2010-03-01 12:00:53 CET 140.100.100.252 ANWEISUNG: declare "SQL_CUR05CF3188" cursor with hold for SELECT a.LSARTIKELTEXT,a.LSARTIKELTEXTKURZ,a.NARTIKELARTKZ,a.NARTIKELGRUPPEKZ,a.NARTIKELKEY,a.NKOMMUNIKARTKZ,a.NLIEFEKEY,a.NLIEFEPROGRAMMKEY,a.NMANDANTKEY,a.NMWSTKZ,a.NREKLAAGENTURKEY,a.NSORTIMENTKZ,a.NSTATISTIKKZ,a.NWARENGRUPPEKZ,a.SARTIKBEZEICHNUNG,a.SARTIKELARTKZ,a.SARTIKELGESPERRT,a.SARTIKELGRUPPEKZ,a.SARTIKELIDENT,a.SBESTELLSPERRE,a.SKATALOG,a.SLIEFERANTGESPERRT,a.SLIEFERANTIDENT,a.SMODELLHERSTELLER,a.SMODELLINTERN,a.SMWSTKZ,a.SNAME1,a.SOHNEBESTAND,a.SPFAD,a.SPROGBEZEICHNUNG,a.SPROGRAMMIDENT,a.SSORTIMENTKZ,a.SSTATISTIKKZ,a.SSTUECKARTIKEL,a.SVERBANDNR,a.SWARENGRUPPEKZ FROM V_ARTIKLIEFEADRESS a WHERE (Upper(SARTIKELIDENT) like '116848100%' or Upper(SLIEFERANTIDENT) like '116848100%' or Upper(SNAME1) like '116848100%' or Upper(SARTIKBEZEICHNUNG) like '116848100%' or Upper(SMODELLHERSTELLER) like '116848100%' or Upper(SMODELLINTERN) like '116848100%' or Upper(SPROGBEZEICHNUNG) like '116848100%' or Upper(LSARTIKELTEXTKURZ) like '%116848100%' or Upper(SVERBANDNR) like '116848100%' ) AND ( ( sartikelgesperrt = '0' ) OR ( sartikelgesperrt IS NULL ) ) and NMANDANTKEY = 1 ;fetch 20000 in "SQL_CUR05CF3188" 2010-03-01 12:00:53 CET 140.100.100.252 LOG: temporäre Datei: Pfad »base/pgsql_tmp/pgsql_tmp811.45«, Größe 19200 2010-03-01 12:00:53 CET 140.100.100.252 ANWEISUNG: declare "SQL_CUR05CF3188" cursor with hold for SELECT a.LSARTIKELTEXT,a.LSARTIKELTEXTKURZ,a.NARTIKELARTKZ,a.NARTIKELGRUPPEKZ,a.NARTIKELKEY,a.NKOMMUNIKARTKZ,a.NLIEFEKEY,a.NLIEFEPROGRAMMKEY,a.NMANDANTKEY,a.NMWSTKZ,a.NREKLAAGENTURKEY,a.NSORTIMENTKZ,a.NSTATISTIKKZ,a.NWARENGRUPPEKZ,a.SARTIKBEZEICHNUNG,a.SARTIKELARTKZ,a.SARTIKELGESPERRT,a.SARTIKELGRUPPEKZ,a.SARTIKELIDENT,a.SBESTELLSPERRE,a.SKATALOG,a.SLIEFERANTGESPERRT,a.SLIEFERANTIDENT,a.SMODELLHERSTELLER,a.SMODELLINTERN,a.SMWSTKZ,a.SNAME1,a.SOHNEBESTAND,a.SPFAD,a.SPROGBEZEICHNUNG,a.SPROGRAMMIDENT,a.SSORTIMENTKZ,a.SSTATISTIKKZ,a.SSTUECKARTIKEL,a.SVERBANDNR,a.SWARENGRUPPEKZ FROM V_ARTIKLIEFEADRESS a WHERE (Upper(SARTIKELIDENT) like '116848100%' or Upper(SLIEFERANTIDENT) like '116848100%' or Upper(SNAME1) like '116848100%' or Upper(SARTIKBEZEICHNUNG) like '116848100%' or Upper(SMODELLHERSTELLER) like '116848100%' or Upper(SMODELLINTERN) like '116848100%' or Upper(SPROGBEZEICHNUNG) like '116848100%' or Upper(LSARTIKELTEXTKURZ) like '%116848100%' or Upper(SVERBANDNR) like '116848100%' ) AND ( ( sartikelgesperrt = '0' ) OR ( sartikelgesperrt IS NULL ) ) and NMANDANTKEY = 1 ;fetch 20000 in "SQL_CUR05CF3188" 2010-03-01 12:00:53 CET 140.100.100.252 LOG: temporäre Datei: Pfad »base/pgsql_tmp/pgsql_tmp811.42«, Größe 1185512 2010-03-01 12:00:53 CET 140.100.100.252 ANWEISUNG: declare "SQL_CUR05CF3188" cursor with hold for SELECT a.LSARTIKELTEXT,a.LSARTIKELTEXTKURZ,a.NARTIKELARTKZ,a.NARTIKELGRUPPEKZ,a.NARTIKELKEY,a.NKOMMUNIKARTKZ,a.NLIEFEKEY,a.NLIEFEPROGRAMMKEY,a.NMANDANTKEY,a.NMWSTKZ,a.NREKLAAGENTURKEY,a.NSORTIMENTKZ,a.NSTATISTIKKZ,a.NWARENGRUPPEKZ,a.SARTIKBEZEICHNUNG,a.SARTIKELARTKZ,a.SARTIKELGESPERRT,a.SARTIKELGRUPPEKZ,a.SARTIKELIDENT,a.SBESTELLSPERRE,a.SKATALOG,a.SLIEFERANTGESPERRT,a.SLIEFERANTIDENT,a.SMODELLHERSTELLER,a.SMODELLINTERN,a.SMWSTKZ,a.SNAME1,a.SOHNEBESTAND,a.SPFAD,a.SPROGBEZEICHNUNG,a.SPROGRAMMIDENT,a.SSORTIMENTKZ,a.SSTATISTIKKZ,a.SSTUECKARTIKEL,a.SVERBANDNR,a.SWARENGRUPPEKZ FROM V_ARTIKLIEFEADRESS a WHERE (Upper(SARTIKELIDENT) like '116848100%' or Upper(SLIEFERANTIDENT) like '116848100%' or Upper(SNAME1) like '116848100%' or Upper(SARTIKBEZEICHNUNG) like '116848100%' or Upper(SMODELLHERSTELLER) like '116848100%' or Upper(SMODELLINTERN) like '116848100%' or Upper(SPROGBEZEICHNUNG) like '116848100%' or Upper(LSARTIKELTEXTKURZ) like '%116848100%' or Upper(SVERBANDNR) like '116848100%' ) AND ( ( sartikelgesperrt = '0' ) OR ( sartikelgesperrt IS NULL ) ) and NMANDANTKEY = 1 ;fetch 20000 in "SQL_CUR05CF3188" 2010-03-01 12:00:53 CET 140.100.100.252 LOG: temporäre Datei: Pfad »base/pgsql_tmp/pgsql_tmp811.47«, Größe 19280 2010-03-01 12:00:53 CET 140.100.100.252 ANWEISUNG: declare "SQL_CUR05CF3188" cursor with hold
Es sortiert also auf der Paltte in Verzeichnissen, anstatt im Arbeitsspeicher?
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Wobei ich noch hinzufügen möchte, dass shared_mem wohl auch so zu hoch ist. Ein kleinerer Wert macht es auch, hauptsache das OS hat genügend Cache.
Wenn die Datenbank sehr schreiblastig ist, wirst du rund um die Checkpoints auch heftige I/O-Spitzen bemerken. Schau mal, ob /proc/sys/vm/dirty_background_ratio den Wert 0 hat, ansonsten setz es darauf. Und schau, dass Memory Overcommit ausgeschaltet ist.
Die temporären Dateien kannst du mittels log_temp_files beobachten.
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
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen