Jeff Janes writes:
> I apologize if it is bad form to respond to a message that is two
> months old, but I did not see this question answered elsewhere and
> thought it would be helpful to have it answered. This my rough
> understanding. Oracle never "takes" a snapshot, it computes one the
> fly
On Thu, 4 Jun 2009 06:57:57 -0400, Robert Haas wrote
in http://archives.postgresql.org/pgsql-performance/2009-06/msg00065.php :
> I think I see the distinction you're drawing here. IIUC, you're
> arguing that other database products use connection pooling to handle
> rapid connect/disconnect cyc
This is postgres 8.4 BTW.
It says 2.9Gb of RESIDENT memory, that also seems to be shared. Is
this the writer sharing the records it wrote in a shared buffer?
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
11088 postgres 13 -2 3217m 3.0g 3.0g S0 39.5 0:14.23 postgres
Tom Lane wrote:
> Craig James writes:
> > 8.4 has vastly improved the warm-standby features, but it looks to me like
> > this is still an installation-wide backup, not a per-database backup. That
> > is, if you have (say) a couple hundred databases, and you only want
> > warm-backup on one of
Craig James writes:
> 8.4 has vastly improved the warm-standby features, but it looks to me like
> this is still an installation-wide backup, not a per-database backup. That
> is, if you have (say) a couple hundred databases, and you only want
> warm-backup on one of them, you can't do it (exc
8.4 has vastly improved the warm-standby features, but it looks to me like this
is still an installation-wide backup, not a per-database backup. That is, if
you have (say) a couple hundred databases, and you only want warm-backup on one
of them, you can't do it (except using other solutions li
On 8/14/09 11:00 AM, "Jeremy Carroll"
wrote:
> I am confused about what the OS is reporting for memory usage on CentOS 5.3
> Linux. Looking at the resident memory size of the processes. Looking at the
> resident size of all postgres processes, the system should be using around
> 30Gb of physical
I'm betting it's shared_buffers that have been swapped out (2G swapped
out on his machine) for kernel cache.The RES and SHR being the
same says the actual processes are using hardly any ram, just hitting
shared_buffers.
On Fri, Aug 14, 2009 at 2:20 PM, Jeremy
Carroll wrote:
> But the kernel ca
On Fri, Aug 14, 2009 at 12:00 PM, Jeremy
Carroll wrote:
> I am confused about what the OS is reporting for memory usage on CentOS 5.3
> Linux. Looking at the resident memory size of the processes. Looking at the
> resident size of all postgres processes, the system should be using around
> 30Gb of
But the kernel can take back any of the cache memory if it wants to. Therefore
it is free memory.
This still does not explain why the top command is reporting ~9GB of resident
memory, yet the top command does not suggest that any physical memory is being
used.
On 8/14/09 2:43 PM, "Reid Thomps
On Fri, 2009-08-14 at 14:00 -0400, Jeremy Carroll wrote:
> I am confused about what the OS is reporting for memory usage on
> CentOS 5.3 Linux. Looking at the resident memory size of the
> processes. Looking at the resident size of all postgres processes, the
> system should be using around 30Gb of
I am confused about what the OS is reporting for memory usage on CentOS 5.3
Linux. Looking at the resident memory size of the processes. Looking at the
resident size of all postgres processes, the system should be using around 30Gb
of physical ram. I know that it states that it is using a lot of
12 matches
Mail list logo
