Hallo,

ich habe mal einige Werte meiner Datenbank angehängt.
Wo ist noch Tuningspotenzial?
Der Server ist ein 2,8GHz mit 512MB RAM auf SCSI RAID1
Es handelt sich um postgreSQL 7.4.8 auf SuSE Linux 9.1

tcpip_socket =3D true
max_connections =3D 100
port =3D 5432
authentication_timeout =3D 60
shared_buffers =3D 1000
stats_start_collector =3D true
stats_command_string =3D false
stats_block_level =3D false
stats_row_level =3D false

Mehr Werte hab ich nicht geändert. Mir kommt es aber so vor,
als ob der Server mehr schläft als wirklich arbeitet und große
Abfragen über eine Tabelle von 700MB trotz Indizes sehr lange
(30 Sekunden) dauert und die Serverauslastung bei etwa 4%
liegt.

Hoffe ihr könnt mir da weiterhelfen.

Daniel Seichter


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

am 08.12.2005, um 10:31:22 +0100 mailte Daniel Seichter folgendes:
> Hallo,
>
> ich habe mal einige Werte meiner Datenbank angehängt.
> Wo ist noch Tuningspotenzial?
> Der Server ist ein 2,8GHz mit 512MB RAM auf SCSI RAID1
> Es handelt sich um postgreSQL 7.4.8 auf SuSE Linux 9.1

Allgemein: RAM, Platte, CPU

RAM kostet heute quasi nix mehr.



>
> tcpip_socket =3D true
> max_connections =3D 100
> port =3D 5432
> authentication_timeout =3D 60
> shared_buffers =3D 1000
> stats_start_collector =3D true
> stats_command_string =3D false
> stats_block_level =3D false
> stats_row_level =3D false

10:44 < akretschmer> ??tuning
10:44 < rtfm_please> For information about tuning
10:44 < rtfm_please> see http://www.powerpostgresql.com
10:44 < rtfm_please> or http://www.powerpostgresql.com/PerfList
10:44 < rtfm_please> or http://www.varlena.com/varlena/GeneralBits/116.ph=
p

schau mal diese Links Dir an.


>
> Mehr Werte hab ich nicht geändert. Mir kommt es aber so vor,
> als ob der Server mehr schläft als wirklich arbeitet und große
> Abfragen über eine Tabelle von 700MB trotz Indizes sehr lange
> (30 Sekunden) dauert und die Serverauslastung bei etwa 4%

Du solltest einfach mal mit explain analyse schauen, wo da was hängt.
Und ja: mit 8.1 gehen bitmap index scans, das bringt u.U. 4-6 fache
Steigerung bei mehreren Indexen, angeblich wohl sogar bis 20-fach.

Btw.: obige Links sind vom doc_bot aus dem Chat zu PG, #postgresql,
#postgresql-de. Vielleicht villst Du dahin mal einen /join machen...


Andreas
--
Andreas Kretschmer (Kontakt: siehe Header)
Heynitz: 035242/47212, D1: 0160/7141639
GnuPG-ID 0x3FFF606C http://wwwkeys.de.pgp.net
=3D=3D=3D Schollglas Unternehmensgruppe =3D=3D=3D

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On 08.12.2005, at 10:31 Uhr, Daniel Seichter wrote:


> große Abfragen über eine Tabelle von 700MB trotz Indizes sehr lange
> (30 Sekunden) dauert

Kannst Du mal ein "explain analyse select ..." von einer solchen
"großen" Anfrage posten?

Ansonsten hat der Server recht wenig RAM für die restliche
Ausstattung. Was läuft denn noch auf der Kiste? Kommt er evtl. ins
Swappen, wenn er eine solche Query zu bearbeiten hat?

Ansonsten: wie greifst Du auf die Datenbank zu? Womit wurden die 30s
gemessen?

cug


--
PharmaLine, Essen, GERMANY
Software and Database Development



---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Hallo Daniel,

> Mehr Werte hab ich nicht geändert. Mir kommt es aber so vor,
> als ob der Server mehr schläft als wirklich arbeitet und große
> Abfragen über eine Tabelle von 700MB trotz Indizes sehr lange
> (30 Sekunden) dauert und die Serverauslastung bei etwa 4%
> liegt.
Es wäre interessant zu Wissen, ob überhaupt ein Index benutzt wird. Has=
t Du
mal ein explain (oder war es explore?) probiert?

Michael König

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly

In article <200512081045.42199.michael [at] koenig-bln-privat.de>,
Michael Koenig <michael [at] koenig-bln-privat.de> writes:

> Hallo Daniel,
>> Mehr Werte hab ich nicht geändert. Mir kommt es aber so vor,
>> als ob der Server mehr schläft als wirklich arbeitet und große
>> Abfragen über eine Tabelle von 700MB trotz Indizes sehr lange
>> (30 Sekunden) dauert und die Serverauslastung bei etwa 4%
>> liegt.
> Es wäre interessant zu Wissen, ob überhaupt ein Index benutzt wird. H=
ast Du
> mal ein explain (oder war es explore?) probiert?

EXPLAIN ANALYZE - und das führt zur nächsten Gegenfrage: gibt es eine
vernünftige Policy für VACUUM ANALYZE?


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo [at] postgresql.org so that your
message can get through to the mailing list cleanly