Re: Memory bloating

Ross,

I put debug level to 2 and let it go a cycle (which I define as bringing the
CPU load to at least 20 and then seeing it drop down again), about 45
minutes or so. The logfile is pretty big so I dont want to send it to you in
email, but I didn't really see anything unusual (but then again, I dont know
what unusual would be), most everything was selects. I counted 19 UPDATE
lines, which is VERY few, and 25 DELETE, amidst about 2500 SELECTs.

Micah

On Tue, Oct 03, 2000 at 12:26:53PM -0500, Ross J. Reedstrom wrote:
> On Tue, Oct 03, 2000 at 11:55:45AM -0500, Micah Anderson wrote:
> > Hello,
> >
> > We are using postgresql exclusively for our database backend for a
> > high-traffic site, sustaining 3-4 pages per second, in many cases
> > bursting well over that. At least half of those accesses are pgsql
> > SELECT, we rarely, if at all, use DELETE. It seems worst on tables with
> > more than about 1000 rows or 1000 hits an hour, or both.
> >
>
> Hmm, how about UPDATE? The exploding files and VACUUM stats indicate that
> you're creating no longer valid tuples _somehow_. Any recent changes in
> SQL scripts? I'd be suspicious of a 'view' page that got cloned from an
> 'edit' page, and is updating the 'modified' field, as an example.
>
> You could turn on a higher level of logging, and capture the actual
> queries, for a time, and find the culprit that way. Use of varchar isn't
> the problem: there's got to be either UPDATE or DELETE going on.
>
> Ross
> --
> Open source code is like a natural resource, it's the result of providing
> food and sunshine to programmers, and then staying out of their way.
> [...] [It] is not going away because it has utility for both the developers
> and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.

--
Micah Anderson
Collective Technologies
www.colltech.com

"To be and not to do is not to be at all"