Re: How to monitor resources on Linux.

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.

Thanks

Tom Lane wrote:
> John R Allgood <jallgood@the-allgoods.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?
>
>                http://archives.postgresql.org
>
>