Re: Still problems with memory swapping and server load
От | Markus Wollny |
---|---|
Тема | Re: Still problems with memory swapping and server load |
Дата | |
Msg-id | 2266D0630E43BB4290742247C891057501B13035@dozer.computec.de обсуждение исходный текст |
Ответ на | Still problems with memory swapping and server load ("Markus Wollny" <Markus.Wollny@computec.de>) |
Список | pgsql-general |
Hi! I don't know exactly how to find the offending queries. All I was able to come up with is check top-output, nail down the pid and then scan over the logfile to get some queries - but of course there's lots of queries using this very pid subsequently. How do I determine the details? Right now all I could see was that all the queries where using the begin|declare sql_cursor|fetch|close sql_cursor|end-pattern induced by the odbc-driver, I presume. How do I pinpoint the specific offender? Regards, Markus > -----Ursprüngliche Nachricht----- > Von: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Gesendet: Mittwoch, 26. Juni 2002 16:59 > An: Markus Wollny > Cc: pgsql-general@postgresql.org > Betreff: Re: [GENERAL] Still problems with memory swapping and server > load > > > "Markus Wollny" <Markus.Wollny@computec.de> writes: > > I'm still "being hosed over big time" as Curt Sampson put > it. It's still > > the same machine and database: 1GB RAM, 4xPIII550Xeon, > dumpall.sql is > > ~300MB (see "[GENERAL] Urgent: Tuning strategies?"). It all > starts with > > a humble 8MB swap being used (I expect that's just the > empty swap with > > nothing in it but some system overhead). Then after a short > time, memory > > usage climbs slow but continuously until it hits physical > RAM ceiling > > and starts using swap - with not very nice results for the database. > > It sort of looks like you are seeing a memory-leak problem. I thought > we'd largely eliminated that class of trouble in recent releases, but > maybe there's still one or two left. Can you identify the exact query > or queries that cause individual backends' memory usage to grow? > > regards, tom lane >
В списке pgsql-general по дате отправления: