From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Michael Stone <mstone+postgres(at)mathom(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Vacuums on large busy databases |
Date: | 2006-09-15 01:44:28 |
Message-ID: | 1158284668.29889.245.camel@dogma.v10.wvs |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 2006-09-14 at 21:04 -0400, Michael Stone wrote:
> On Thu, Sep 14, 2006 at 05:52:02PM -0700, Jeff Davis wrote:
> >Any long-running system will have very little "free" memory. Free memory
> >is wasted memory, so the OS finds some use for it.
>
> The important part of the output of "free" in this context isn't how
> much is free, it's how much is cache vs how much is allocated to
> programs. Other os's have other ways of telling the same thing. Neither
> of those numbers generally has much to do with how much shows up in ps
> when large amounts of shared memory are in use.
Right, ps doesn't give you much help. But he didn't tell us about the
process. If a process is using all the buffer cache, and you take away
that memory, it could turn all the reads that previously came from the
buffer cache into disk reads, leading to major slowdown and interference
with the database.
Conversely, if you have a large program running, it may not use much of
it's own memory, and perhaps some rarely-accessed pages could be paged
out in favor of more buffer cache. So even if all your memory is taken
with resident programs, your computer may easily accommodate more
processes by paging out rarely-used process memory.
If he knows a little more about the process than he can make a better
determination. But I don't think it will be much of a problem with 8GB
of physical memory.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Luke Lonergan | 2006-09-15 03:36:54 | Re: RAID 0 not as fast as expected |
Previous Message | Jeff Davis | 2006-09-15 01:34:22 | Re: Vacuums on large busy databases |