Re: out of memory errors

From: Bruce McAlister <bruce(dot)mcalister(at)blueface(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: out of memory errors
Date: 2014-06-16 15:30:07
Message-ID: 539F0D7F.1040601@blueface.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I was reading in to the parameter a little more and it appears that the
defuault for vm.overcommit_ratio is 50%, I am considering bumping this
up to 95% so the sums look like this:

max memory allocation for process = swap + ratio of physical memory

21 + (16 * 0.95) = 36.2GB

This in theory should always leave me with roughly 1GB of free physical
memory, swap may be blown though :) (if my understanding of this
parameter is correct).

What I dont understand is, even at its default, the overcommit ratio is
50% of physical, which would make it 21GB + 8GB, ending up at around
29GB (which looks about right in the meminfo output below), so, assuming
my understanding is correct:

[1] How can an analyze process run out of memory on this setting if
it is asking for, at most, maintenance_work_mem (plus some overhead) 128MB
[2] How can a new connection run out of memory, I presume work_mem
+ some overhead, I'm guessing around 2MB memory?

I'm beginning to wonder if my issue is somewhere else now.

Thanks for the tip though at looking at vm.overcommit_ratio, I obvisouly
overlooked this setting when setting vm.overcommit_memory = 2

Any other pointers would be greatly appreciated :)

Reference:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-captun.html

Thanks
Bruce

On 16/06/2014 14:21, Bruce McAlister wrote:
> Hi,
>
> On 16/06/2014 14:15, Andres Freund wrote:
>> Hi,
>>
>> On 2014-06-16 13:56:23 +0100, Bruce McAlister wrote:
>>> [1] 3 x ESX VM's
>>> [a] 8 vCPU's each
>>> [b] 16GB memory each
>>> # Dont hand out more memory than neccesary
>>> vm.overcommit_memory = 2
>> So you haven't tune overcommit_ratio at all? Can you show
>> /proc/meminfo's contents?
>> My guess is that the CommitLimit is too low...
>>
>
> No I have not tune overcommit_ratio.
>
> Below is the /proc/meminfo contents. One note though, the database is
> currently not running on this node, just in case i need to make some
> changes that require a restart.
>
> [root(at)bfievdb01 heartbeat]# cat /proc/meminfo
> MemTotal: 16333652 kB
> MemFree: 2928544 kB
> Buffers: 197216 kB
> Cached: 1884032 kB
> SwapCached: 0 kB
> Active: 4638780 kB
> Inactive: 1403676 kB
> Active(anon): 4006088 kB
> Inactive(anon): 7120 kB
> Active(file): 632692 kB
> Inactive(file): 1396556 kB
> Unevictable: 65004 kB
> Mlocked: 56828 kB
> SwapTotal: 22015984 kB
> SwapFree: 22015984 kB
> Dirty: 3616 kB
> Writeback: 0 kB
> AnonPages: 4026228 kB
> Mapped: 82408 kB
> Shmem: 45352 kB
> Slab: 197052 kB
> SReclaimable: 106804 kB
> SUnreclaim: 90248 kB
> KernelStack: 4000 kB
> PageTables: 15172 kB
> NFS_Unstable: 0 kB
> Bounce: 0 kB
> WritebackTmp: 0 kB
> CommitLimit: 30182808 kB
> Committed_AS: 4342644 kB
> VmallocTotal: 34359738367 kB
> VmallocUsed: 7004496 kB
> VmallocChunk: 34352726816 kB
> HardwareCorrupted: 0 kB
> AnonHugePages: 3868672 kB
> HugePages_Total: 0
> HugePages_Free: 0
> HugePages_Rsvd: 0
> HugePages_Surp: 0
> Hugepagesize: 2048 kB
> DirectMap4k: 10240 kB
> DirectMap2M: 16766976 kB
>
> Thanks
> Bruce

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Nathaniel Talbott 2014-06-16 18:01:19 (Relatively) Oversized Checkpoint
Previous Message Tom Lane 2014-06-16 14:24:42 Re: eclipse-gdb