Hallo Liste,

ich hab hier ein kleines Problem mit unserer PSQL Datenbank. Wir haben
ein Uploadtool welches die hochgeladenen Dateien in der Datenbank in
einem Feld vom Typ bytea speichert.

In letzter Zeit können wir nur noch kleinere Dateien hochladen, vor ner=

Woche 5 MB, heute morgen nur noch 3 MB und nun steigt der schon bei <
1MB aus.

Immer mit der Fehlermeldung
PDOException' with message 'SQLSTATE[53200]: Out of memory: 7 ERROR: out
of memory DETAIL: Failed on request of size 16777216.'



Gibts da irgendwelche Lösungen? Hab das gefühl der Speicher läuft
einfach irgendwann voll, was aber komisch ist.

Datenbankserver ist Solaris SunOS 5.10, Postgres Version: psql 8.1.9
(server 8.2.0).
Nochmal ein Auszug aus dem Top

load averages: 1.52, 1.72, 1.76; up 285+00:43:12
17:20:21
55 processes: 53 sleeping, 2 on cpu
CPU states: % idle, % user, % kernel, % iowait, % swa=
p
Memory: 8064M phys mem, 2206M free mem, 16G swap, 16G free swap

PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
12755 pgsql 1 59 0 3871M 3865M sleep 320:56 0.00% postgres
15491 pgsql 1 59 0 11M 4140K sleep 180:54 0.00% postgres
12760 pgsql 1 59 0 7296K 984K sleep 65:29 0.00% postgres
129 daemon 5 59 0 4588K 2388K sleep 51:24 0.00% kcfd
9 root 15 59 0 9428K 3528K sleep 33:55 0.00% svc.configd
15489 pgsql 1 60 0 3873M 3867M sleep 23:06 0.00% postgres
22137 nrpe 1 59 0 1740K 892K sleep 19:30 0.00% nrpe
22400 root 30 59 0 4060K 2680K sleep 12:13 0.00% nscd
5604 root 1 100 -20 1956K 1228K sleep 11:11 0.00% xntpd
29023 daemon 2 60 -20 2152K 1048K sleep 8:31 0.00% nfsd
251 root 3 59 0 4064K 1768K sleep 7:25 0.00% inetd
5440 root 1 59 0 6600K 1500K sleep 6:29 0.00% sendmail
29010 daemon 4 59 0 693M 432M sleep 6:26 0.00% nfsmapid
23714 root 1 59 0 3336K 1104K sleep 4:39 0.00% sshd
308 root 1 59 0 2904K 1408K sleep 4:19 0.00% rpc.metad


Auf der Kiste läuft eigentlich nur der Postgres, sonst nix grosses weit=
er.

Danke schonmal für eure Hilfe.

Gruss,

Oli

--
Oliver Baer

Entwicklung
PressWatch GmbH
Telemannstr. 56a
20255 Hamburg

Tel: +49.40.37 85 48-60
Fax: +49.40.37 85 48-20
oliver.baer [at] presswatch.de
www.presswatch.de
www.presswatch.eu

Geschäftsführer: Jörg Kramer
Amtsgericht Hamburg: HRB 101855


This message (including any attachments) contains information that may be=
confidential and/or privileged. It is intended only for the person(s) to=
whom it is addressed.

If you are not the intended recipient, please notify the sender by replyi=
ng to this message with "Received in error" as the subject and thendelete=
it from your mailbox.

If you are not the intended recipient, you are not authorized to read, pr=
int, retain, copy or disseminate this message or any part of it, and any =
unauthorized use may be unlawful.

The sender is not responsible for the accuracy or completeness of this me=
ssage when it has been transmitted over a public network, as Internet
communication is not secure.


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Hallo,

Am 04.09.2007 um 17:24 schrieb Oliver Baer:

> Hab das gefühl der Speicher läuft einfach irgendwann voll,

> PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
> 12755 pgsql 1 59 0 3871M 3865M sleep 320:56 0.00% postgres
> 15489 pgsql 1 60 0 3873M 3867M sleep 23:06 0.00% postgres

Na, die beiden sind ja auch recht fett. Könnte also gut sein.

> was aber komisch ist.

Warum?

Wie siehts nach einem Neustart aus?

> Postgres Version: psql 8.1.9 (server 8.2.0).

Passt das zu einander? Protokoll?

> Wir haben ein Uploadtool welches die hochgeladenen Dateien
> in der Datenbank in einem Feld vom Typ bytea speichert.

Kannst Du uns das Skript zeigen?

Werden Verbindungen korrekt beendet?
Transaktionen abgeschlossen?

Gruß, Christian


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Christian Voelker schrieb:
> Hallo,
>
> Am 04.09.2007 um 17:24 schrieb Oliver Baer:
>
>> Hab das gefühl der Speicher läuft einfach irgendwann voll,
>
>> PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
>> 12755 pgsql 1 59 0 3871M 3865M sleep 320:56 0.00% postgres
>> 15489 pgsql 1 60 0 3873M 3867M sleep 23:06 0.00% postgres
>
> Na, die beiden sind ja auch recht fett. Könnte also gut sein.
>
denen sind aber auch 4GB Speicher zugewiesen, die DB ist recht gross.
>> was aber komisch ist.
>
> Warum?
>
> Wie siehts nach einem Neustart aus?
>
Das hab ich noch nicht probiert, sollte ich vielleicht mal tun.

>> Postgres Version: psql 8.1.9 (server 8.2.0).
>
> Passt das zu einander? Protokoll?
>
das ist nur der PSQL auf einem anderen Server mit dem ich mich connected
habe, damit mache ich keinerlei Operationen.

>> Wir haben ein Uploadtool welches die hochgeladenen Dateien
>> in der Datenbank in einem Feld vom Typ bytea speichert.
>
> Kannst Du uns das Skript zeigen?

Mmmh das Script kann ich schlecht zeigen, geht durch bestimmt 10
verschiedene durch bis es letztlich in der DB ankommt, da müsste ich
hier unser Framework posten ;)
>
> Werden Verbindungen korrekt beendet?
> Transaktionen abgeschlossen?
Soweit ich das beurteilen kann ja. Alles wird commited.
>
> Gruß, Christian
>
Glaub mir bleibt nur der neustart des ganzen.

Danke schonmal für die Mühe

Oli

--
Oliver Baer

Entwicklung
PressWatch GmbH
Telemannstr. 56a
20255 Hamburg

Tel: +49.40.37 85 48-60
Fax: +49.40.37 85 48-20
oliver.baer [at] presswatch.de
www.presswatch.de
www.presswatch.eu

Geschäftsführer: Jörg Kramer
Amtsgericht Hamburg: HRB 101855


This message (including any attachments) contains information that may be=
confidential and/or privileged. It is intended only for the person(s) to=
whom it is addressed.

If you are not the intended recipient, please notify the sender by replyi=
ng to this message with "Received in error" as the subject and thendelete=
it from your mailbox.

If you are not the intended recipient, you are not authorized to read, pr=
int, retain, copy or disseminate this message or any part of it, and any =
unauthorized use may be unlawful.

The sender is not responsible for the accuracy or completeness of this me=
ssage when it has been transmitted over a public network, as Internet
communication is not secure.


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Am Dienstag, 4. September 2007 17:53 schrieb Christian Voelker:
> > Postgres Version: psql 8.1.9 (server 8.2.0).
>
> Passt das zu einander? Protokoll?

Ja, es passt.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

--On Dienstag, September 04, 2007 17:24:58 +0200 Oliver Baer
<oliver.baer [at] presswatch.de> wrote:

> Hallo Liste,
>
> ich hab hier ein kleines Problem mit unserer PSQL Datenbank. Wir haben
> ein Uploadtool welches die hochgeladenen Dateien in der Datenbank in
> einem Feld vom Typ bytea speichert.
>
> In letzter Zeit k=C3=B6nnen wir nur noch kleinere Dateien hochladen, vor =
ner
> Woche 5 MB, heute morgen nur noch 3 MB und nun steigt der schon bei < 1MB
> aus.
>
> Immer mit der Fehlermeldung
> PDOException' with message 'SQLSTATE[53200]: Out of memory: 7 ERROR: out
> of memory DETAIL: Failed on request of size 16777216.'

Hmm er versucht 16MByte Speicher zu allokieren....sehr gro=C3=9Fe und krumm=
e
Zahlen deuten manchmal auf korrupte Tupelheader hin. Ist das immer
diesselbe Gr=C3=B6=C3=9Fe und f=C3=BCr deinen Upload reproduzierbar? Die Fe=
hlermeldung
mit der 7 ist auch ein wenig suspekt....

>
>
>
> Gibts da irgendwelche L=C3=B6sungen? Hab das gef=C3=BChl der Speicher l=
=C3=A4uft
> einfach irgendwann voll, was aber komisch ist.
>
> Datenbankserver ist Solaris SunOS 5.10, Postgres Version: psql 8.1.9
> (server 8.2.0).
> Nochmal ein Auszug aus dem Top
>
> load averages: 1.52, 1.72, 1.76; up 285+00:43:12
> 17:20:21
> 55 processes: 53 sleeping, 2 on cpu
> CPU states: % idle, % user, % kernel, % iowait, % swap
> Memory: 8064M phys mem, 2206M free mem, 16G swap, 16G free swap
>
> PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
> 12755 pgsql 1 59 0 3871M 3865M sleep 320:56 0.00% postgres

So, mal ein Schu=C3=9F ins Blaue: kann es irgendwie sein, dass ihr eine 32-=
Bit
PostgreSQL-Instanz laufen habt? Ich hatte letztens einen =C3=A4hnlichen Fal=
l,
wo ein 32-Bit Build fast genau mit derselben RAM-Usage ausgestiegen ist
(allerdings auf ner pSeries....).

Wieviel shared_buffer und (maintenance_)work_mem ist dieser Instanz
zugewiesen?


--
Thanks

Bernd

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

> --On Dienstag, September 04, 2007 17:24:58 +0200 Oliver Baer
> <oliver.baer [at] presswatch.de> wrote:
>
>> Hallo Liste,
>>
>> ich hab hier ein kleines Problem mit unserer PSQL Datenbank. Wir haben
>> ein Uploadtool welches die hochgeladenen Dateien in der Datenbank in
>> einem Feld vom Typ bytea speichert.
>>
>> In letzter Zeit k=C3=B6nnen wir nur noch kleinere Dateien hochladen, v=
or ner
>> Woche 5 MB, heute morgen nur noch 3 MB und nun steigt der schon bei <
>> 1MB
>> aus.
>>
>> Immer mit der Fehlermeldung
>> PDOException' with message 'SQLSTATE[53200]: Out of memory: 7 ERROR: o=
ut
>> of memory DETAIL: Failed on request of size 16777216.'
>
> Hmm er versucht 16MByte Speicher zu allokieren....sehr gro=C3=9Fe und k=
rumme
> Zahlen deuten manchmal auf korrupte Tupelheader hin. Ist das immer
> diesselbe Gr=C3=B6=C3=9Fe und f=C3=BCr deinen Upload reproduzierbar? Di=
e Fehlermeldung
> mit der 7 ist auch ein wenig suspekt....
>
das müsste ich auch noch mal überprüfen.

>>
>>
>> Gibts da irgendwelche L=C3=B6sungen? Hab das gef=C3=BChl der Speicher =
l=C3=A4uft
>> einfach irgendwann voll, was aber komisch ist.
>>
>> Datenbankserver ist Solaris SunOS 5.10, Postgres Version: psql 8.1.9
>> (server 8.2.0).
>> Nochmal ein Auszug aus dem Top
>>
>> load averages: 1.52, 1.72, 1.76; up 285+00:43:12
>> 17:20:21
>> 55 processes: 53 sleeping, 2 on cpu
>> CPU states: % idle, % user, % kernel, % iowait, %
>> swap
>> Memory: 8064M phys mem, 2206M free mem, 16G swap, 16G free swap
>>
>> PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
>> 12755 pgsql 1 59 0 3871M 3865M sleep 320:56 0.00% postgres
>
> So, mal ein Schu=C3=9F ins Blaue: kann es irgendwie sein, dass ihr eine=
32-Bit
> PostgreSQL-Instanz laufen habt? Ich hatte letztens einen =C3=A4hnlichen=
Fall,
> wo ein 32-Bit Build fast genau mit derselben RAM-Usage ausgestiegen ist
> (allerdings auf ner pSeries....).
>
> Wieviel shared_buffer und (maintenance_)work_mem ist dieser Instanz
> zugewiesen?
>
Das haben wir zugewiesen:

shared_buffers =3D 3800MB
work_mem =3D 10240


> --
> Thanks
>
> Bernd
>


dank euch

Oli


---------------------------(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

--On Dienstag, September 04, 2007 20:20:14 +0200 oliverbaer [at] presswatch.de=

wrote:

>> So, mal ein Schu=C3=83=C5=B8 ins Blaue: kann es irgendwie sein, dass ihr=
eine
>> 32-Bit PostgreSQL-Instanz laufen habt? Ich hatte letztens einen
>> =C3=83=C2=A4hnlichen Fall, wo ein 32-Bit Build fast genau mit derselben
>> RAM-Usage ausgestiegen ist (allerdings auf ner pSeries....).
>>
>> Wieviel shared_buffer und (maintenance_)work_mem ist dieser Instanz
>> zugewiesen?
>>
> Das haben wir zugewiesen:
>
> shared_buffers =3D 3800MB
> work_mem =3D 10240

Nachgehakt: Ist aber eine 64bittige PostgreSQL-Instanz?

--
Thanks

Bernd

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Bernd Helmle schrieb:
>> Das haben wir zugewiesen:
>>
>> shared_buffers = 3800MB
>> work_mem = 10240
>
> Nachgehakt: Ist aber eine 64bittige PostgreSQL-Instanz?
>

ne, ist ne 32bit instanz. Ich werd die morgen mal auf die 8.2.4
upgraden, heut mit einem gesprochenen der hatte ein hnliches problem.

Dachte auch erst irgendwas stimmt mit dem PHP PDO nicht, aber da scheint
alles in ordnung zu sein. Trotzdem werd ich auch PHP upgraden, die
neueste Version hat da n haufen verbesserungen.

Werde mal berichten ob es geklappt hat oder nicht.

Danke

Oli


---------------------------(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

--On Mittwoch, September 05, 2007 23:14:42 +0200 Oliver Baer
<oliver.baer [at] presswatch.de> wrote:

> > Nachgehakt: Ist aber eine 64bittige PostgreSQL-Instanz?
> >
>
> ne, ist ne 32bit instanz. Ich werd die morgen mal auf die 8.2.4
> upgraden, heut mit einem gesprochenen der hatte ein hnliches problem.

Yepp, mit 32 Bit und dieser Gr=C3=B6=C3=9Fe des shared_buffer bewegt ihr eu=
ch an
der Grenze des machbaren. Alternativ k=C3=B6nnt ihr auch die shared_buffers=

halbieren und so der Datenbank mehr Luft verschaffen. Wollt ihr mehr,
braucht ihr unbedingt ein 64-Bit Kompilat.

--
Thanks

Bernd

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Am Donnerstag, 6. September 2007 10:40:16 schrieb Bernd Helmle:
> --On Mittwoch, September 05, 2007 23:14:42 +0200 Oliver Baer
>
> <oliver.baer [at] presswatch.de> wrote:
> > > Nachgehakt: Ist aber eine 64bittige PostgreSQL-Instanz?
> >
> > ne, ist ne 32bit instanz. Ich werd die morgen mal auf die 8.2.4
> > upgraden, heut mit einem gesprochenen der hatte ein hnliches problem.
>
> Yepp, mit 32 Bit und dieser Gr=C3=B6=C3=9Fe des shared_buffer bewegt ihr =
euch an
> der Grenze des machbaren. Alternativ k=C3=B6nnt ihr auch die shared_buffe=
rs
> halbieren und so der Datenbank mehr Luft verschaffen. Wollt ihr mehr,
> braucht ihr unbedingt ein 64-Bit Kompilat.

Das scheint mir nicht plausibel. Entweder sollte die DB dicke Bin=C3=A4r-H=
appen
fressen oder nicht. Aber nicht Anfangs ja und dann immer weniger.

Bin gespannt ob das was am Grund-Problem =C3=A4ndert. Bitte berichten!!

Gru=C3=9F
Olaf

---------------------------(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

--On Donnerstag, September 06, 2007 11:13:20 +0200 Olaf Radicke
<olaf_rad [at] gmx.de> wrote:

> Am Donnerstag, 6. September 2007 10:40:16 schrieb Bernd Helmle:
>> --On Mittwoch, September 05, 2007 23:14:42 +0200 Oliver Baer
>>
>> <oliver.baer [at] presswatch.de> wrote:
>> > > Nachgehakt: Ist aber eine 64bittige PostgreSQL-Instanz?
>> >
>> > ne, ist ne 32bit instanz. Ich werd die morgen mal auf die 8.2.4
>> > upgraden, heut mit einem gesprochenen der hatte ein hnliches problem.
>>
>> Yepp, mit 32 Bit und dieser Gr=C3=B6=C3=9Fe des shared_buffer bewegt ihr=
euch an
>> der Grenze des machbaren. Alternativ k=C3=B6nnt ihr auch die shared_buff=
ers
>> halbieren und so der Datenbank mehr Luft verschaffen. Wollt ihr mehr,
>> braucht ihr unbedingt ein 64-Bit Kompilat.
>
> Das scheint mir nicht plausibel. Entweder sollte die DB dicke
> Bin=C3=A4r-Happen fressen oder nicht. Aber nicht Anfangs ja und dann imm=
er
> weniger.
>

Deswegen ja "Schu=C3=9F ins Blaue". Ich mu=C3=9F zugeben dass ich auch nich=
t
unbedingt dran glaube. So oder so sollte man ein wenig sparsamer mit den
shared_buffers umgehen, wenn man nur eine 32-Bit Instanz hat, lieber ein
wenig mehr in work_mem und maintenance_work_mem investieren.

--
Thanks

Bernd

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

http://archives.postgresql.org

Bernd Helmle schrieb:
> Deswegen ja "Schu=C3=9F ins Blaue". Ich mu=C3=9F zugeben dass ich auch =
nicht
> unbedingt dran glaube. So oder so sollte man ein wenig sparsamer mit
> den shared_buffers umgehen, wenn man nur eine 32-Bit Instanz hat,
> lieber ein wenig mehr in work_mem und maintenance_work_mem investieren.
>
So das Problem ist soweit gel=C3=B6st. Die Datenbank frisst wieder riesig=
e
Brocken.

Wir haben den shared_buffers runtergedreht auf 3 GB, damit hat es dann
letztlich geklappt. Der Speicher war bis Oberkante Unterlippe f=C3=BCr di=
e
DB, da ists klar das der bei der kleinsten Datei die Gr=C3=A4tsche macht.

\u [at] \h \w >/usr/ucb/ps auxw | head -1
USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
\u [at] \h \w >/usr/ucb/ps auxw | grep postgres
pgsql 27381 21.0 48.839678803962852 ? O 11:00:00 0:40
/opt/local/postgres8.2.4/bin/postgres -D /presswatch/pwpostgres/databa
pgsql 27024 1.3 48.839717683966008 ? S 10:56:37 0:52
/opt/local/postgres8.2.4/bin/postgres -D /presswatch/pwpostgres/databa
pgsql 24395 0.5 0.111416 3888 ? S 19:16:13 13:28
/opt/local/postgres8.2.4/bin/postgres -D /presswatch/pwpostgres/databa
pgsql 27448 0.2 48.839723403966536 ? S 11:00:17 0:00
/opt/local/postgres8.2.4/bin/postgres -D /presswatch/pwpostgres/databa
pgsql 24393 0.1 48.739660323959580 ? S 19:16:13 2:31
/opt/local/postgres8.2.4/bin/postgres -D /presswatch/pwpostgres/databa
pgsql 24389 0.1 48.739640483958240 ? S 19:16:09 1:15
/opt/local/postgres8.2.4/bin/postgres -D /presswatch/pwpostgres/databa
pgsql 24391 0.0 0.1 7304 1252 ? S 19:16:12 0:19
/opt/local/postgres8.2.4/bin/postgres -D /presswatch/pwpostgres/databa
pgsql 24394 0.0 0.1 7312 1424 ? S 19:16:13 0:01
/opt/local/postgres8.2.4/bin/postgres -D /presswatch/pwpostgres/databa
pgsql 25877 0.0 48.739665683961496 ? S 10:46:45 0:00
/opt/local/postgres8.2.4/bin/postgres -D /presswatch/pwpostgres/databa
pgsql 27505 0.0 0.0 1012 708 pts/1 S 11:00:41 0:00 grep postgre=
s

4000,95MB benutzt von psql

konnt ja nicht klappen :)

naja vielen dank allen die sich die m=C3=BChe gemacht haben mein problem
anzuschauen.

Sch=C3=B6nes Wochenende

Oli



--
Oliver Baer

Entwicklung
PressWatch GmbH
Telemannstr. 56a
20255 Hamburg

Tel: +49.40.37 85 48-60
Fax: +49.40.37 85 48-20
oliver.baer [at] presswatch.de
www.presswatch.de
www.presswatch.eu

Gesch=C3=A4ftsf=C3=BChrer: J=C3=B6rg Kramer
Amtsgericht Hamburg: HRB 101855


This message (including any attachments) contains information that may be=
confidential and/or privileged. It is intended only for the person(s) to=
whom it is addressed.

If you are not the intended recipient, please notify the sender by replyi=
ng to this message with "Received in error" as the subject and thendelete=
it from your mailbox.

If you are not the intended recipient, you are not authorized to read, pr=
int, retain, copy or disseminate this message or any part of it, and any =
unauthorized use may be unlawful.

The sender is not responsible for the accuracy or completeness of this me=
ssage when it has been transmitted over a public network, as Internet
communication is not secure.


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings