The autovac may have done most of the work before you killed it ...
I'm new to Postgres, but from limited subjective experience, it seems
it's a lot faster to vaccum ranges of blocks that are were recently
vacuumed (at minimum, a good chunk of table will have been brought
into buffer cache by both
On Thu, Nov 12, 2009 at 9:58 AM, Wayne Beaver wrote:
>> Quoting Scott Marlowe :
>>
On Thu, Nov 12, 2009 at 9:14 AM, Wayne Beaver wrote:
I'd seen autovacs running for hours and had mis-attributed this to
growing
query times on those tables - my thought was that "shrinking" the
Quoting Scott Marlowe :
On Thu, Nov 12, 2009 at 9:14 AM, Wayne Beaver wrote:
I'd seen autovacs running for hours and had mis-attributed this to growing
query times on those tables - my thought was that "shrinking" the tables
"more quickly" could make them "more-optimized", more often. Sounds l
This is just a heads-up for anyone using Ruby on Rails (with
ActiveRecord) on JRuby who sees performance degradation over time. Each
Ruby runtime instance will degrade query performance slightly. You can
see this if the minimum and maximum number of active runtimes are not
configured to the same
On Thu, Nov 12, 2009 at 9:33 AM, Scott Marlowe wrote:
> On Thu, Nov 12, 2009 at 9:14 AM, Wayne Beaver wrote:
>> Hmm, looks like I've been myth-busted here.
>>
>> $ top | grep -E '29343|31924|29840|PID'; echo
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 29840 postgres
On Thu, Nov 12, 2009 at 9:14 AM, Wayne Beaver wrote:
> Hmm, looks like I've been myth-busted here.
>
> $ top | grep -E '29343|31924|29840|PID'; echo
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 29840 postgres 15 0 2150m 203m 194m S 0 2.5 0:00.59 postmaster
> 293
Hmm, looks like I've been myth-busted here.
$ top | grep -E '29343|31924|29840|PID'; echo
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
29840 postgres 15 0 2150m 203m 194m S0 2.5 0:00.59 postmaster
29343 postgres 15 0 2137m 360m 356m S1 4.5 0:00.92 postm
On Thu, Nov 12, 2009 at 7:33 AM, Wayne Beaver wrote:
> Hi All,
>
> Running Pg 8.3RC2, Linux server, w/8GB RAM, OpenSuSE 10.2 OS (yes, I know
> that's old). I have seen *really* long-running autovacs eating up system
> resources. While the below is not an example of *really* long, it shows how
> I
Wayne Beaver writes:
> Running Pg 8.3RC2, Linux server, w/8GB RAM, OpenSuSE 10.2 OS (yes, I
> know that's old). I have seen *really* long-running autovacs eating up
> system resources. While the below is not an example of *really* long,
> it shows how I killed an autovac which had been runni
Hi All,
Running Pg 8.3RC2, Linux server, w/8GB RAM, OpenSuSE 10.2 OS (yes, I
know that's old). I have seen *really* long-running autovacs eating up
system resources. While the below is not an example of *really* long,
it shows how I killed an autovac which had been running for more than
1
Hi !
Here is my plan :
- rebuilding a spare with ext3, raid10, without lvm
- switch the slony master to this new node.
We'll see ...
Thx for all the info !!!
--
Ker2x
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www
Hi all
Why age (datfrozenxid) in postgres becomes 1073742202 not zero after vacuum
of database.
Thanks in advance
Brahma Prakash Tiwari
DBA
_
Think before you print.|Go green
12 matches
Mail list logo
