Skip site navigation (1) Skip section navigation (2)

Re: How to monitor resources on Linux.

From: John R Allgood <jallgood(at)the-allgoods(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: How to monitor resources on Linux.
Date: 2007-08-28 19:00:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Hey Tom

    Thanks for responding. This issue came around because of a situation 
yesterday with processes being killed off by the kernel.  I believe my 
co worker Geof Myers sent a post yesterday and the response was to 
adjust the vm.commit_memory=2. Several time throughout the day we see 
memory usage peak and then it will go down. We have multiple postmasters 
running for each of our division so that I we have a problem with a 
database it only affects that one. It make it diffucult to tune a system 
with this many postmasters running. Each database is tuned according to 
need. We allow anywhere between 5-50 max connections. So what I am 
looking for is?  Exactly what am I looking at with ipcs -m, free, and top.


Tom Lane wrote:
> John R Allgood <jallgood(at)the-allgoods(dot)net> writes:
>>     I have some questions on memory resources and linux. We are
>> currently running Dell Poweredge 2950 with dual core opeterons and 8GB
>> RAM. Postgres version is 7.4.17 on RHEL4. Could someone explain to me
>> how to best monitor the memory resources on this platform. Top shows a
>> high memory usage nearly all is being used.
> That's meaningless: what you have to look at is the breakdown of *how*
> it is being used.  The normal state of affairs is that there is no
> "free" memory to speak of, because the kernel will keep around cached
> disk pages as long as it can, so as to save a read if they are
> referenced again.  You're only in memory trouble when the percentage
> used for disk buffers gets real small.
>> ipcs -m shows the following
>> output. If I am looking at this correctly each of the postgres entries
>> represents a postmaster with the number of connections. If I calculate
>> the first entry it comes to around 3.4GB of RAM being used is this
>> correct.
> That's *completely* wrong.  It's shared memory, so by definition there
> is one copy, not one per process.
> One thing you have to watch out for is that "top" tends to report some
> or all shared memory as part of the address space of each attached
> process; so adding up the process sizes shown by top gives a
> ridiculously inflated estimate.  However, it's tough to tell exactly how
> much is being double-counted :-(.  I tend to look at top's aggregate
> numbers, which are pretty real, and ignore the per-process ones.
>> We have started running into memory issues
> How do you know that?
> Another good tool is to watch "vmstat 1" output.  If you see a lot of
> swapin/swapout traffic, then maybe you do indeed need more RAM.
>> We have a 2 node cluster running about 10 separate postmasters divided
>> evenly on each node.
> I was wondering why so many postgres-owned shmem segments.  Is it
> intentional that you've given them radically different amounts of
> memory?  Some of these guys are scraping along with just a minimal
> number of buffers ...
>> 0x0052ea91 163845     postgres  600        133947392  26
>> 0x00530db9 196614     postgres  600        34529280   24
>> 0x00530201 229383     postgres  600        34529280   21
>> 0x005305e9 262152     postgres  600        4915200    3
>> 0x005311a1 294921     postgres  600        34529280   28
>> 0x0052fe19 327690     postgres  600        4915200    4
> 			regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?

In response to


pgsql-admin by date

Next:From: Alvaro HerreraDate: 2007-08-28 19:11:44
Subject: Re: How to monitor resources on Linux.
Previous:From: Jeff FrostDate: 2007-08-28 18:11:16
Subject: Re: How to import CSV file?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group