Re: Memory bloating
От | Ross J. Reedstrom |
---|---|
Тема | Re: Memory bloating |
Дата | |
Msg-id | 20001003142449.A31993@rice.edu обсуждение исходный текст |
Ответ на | Re: Memory bloating (Micah Anderson <micah@colltech.com>) |
Список | pgsql-general |
On Tue, Oct 03, 2000 at 02:01:43PM -0500, Micah Anderson wrote: > 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 Hmm, let's see, that's 44 new tuples in 45 min, almost exactly a tuple a minute. The ~ 2000 pages you mentioned looked to contain about 10k tuples, so your fitting on average 5 tuples per page. At that rate, it should have taken about 6 days to create the 14MB file you mentioned. BTW, what leads you to believe the large tables are causing the load increase? And the subject line says something about memory bloat. Three different resources: disk space, memory, and CPU cycles. Which is the underlying problem? The vacuum stats could be a red herring. Can you figure out which queries are running that blow the load up so high? SELECTs that grab a lot of data and sort it can be problem. What parameters are you launching the backend with? (number of buffers, sort memory, etc.) 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.
В списке pgsql-general по дате отправления: