Re: repeated out of shared memory error - not related to max_locks_per_transaction

["Alfonso Moscato (Merqurio)" <alfonso.moscato@xxxxxxxxxxx>]

Ah yes. You meant virt. It’s around 32gb. On Monday I ‘ll be more precise

Regards

On Fri, Jul 20, 2018 at 6:36 PM +0200, "Rui DeSousa" <rui@xxxxxxxxxxxxx> wrote:

Just using the common tools like htop or (ps aux);  specifically VIRT column in htop or VSZ column in ps.   Basically, how much virtual memory is allocated to the process (the total address space of the process).



> On Jul 20, 2018, at 11:38 AM, Alfonso Moscato  wrote:
> 
> Hi Rui,
> we have 100 forked postgres processes, I don't know how to determine if we are hitting the 47Gb limit.
> Any suggestion?
> 
> 
> -----Messaggio originale-----
> Da: Rui DeSousa  
> Inviato: venerdì 20 luglio 2018 17:03
> A: Alfonso Moscato 
> Cc: Tom Lane ; pgsql-admin@xxxxxxxxxxxxxxxxxxxx
> Oggetto: Re: repeated out of shared memory error - not related to max_locks_per_transaction
> 
> 
> Alfonso,
> 
> Do you happened to know how large the process is when it starts giving error messages, anywhere near 47GB? 
> 
> — but we tried with work_mem to 130mb, shared_buffer to a maximum fo 40gb,
> 
> Having  shared_buffer to 40GB would be two high for the current configuration and I would expect to see out of memory errors given that your system commit limit is 47GB; However, with shared_buffers at 23GB I don’t think you should be hitting the 47GB limit — are you?
> 
> To increase the commit limit you can add more swap and/or adjust the overcommit ratio.
> 
> 
> 
> 
> 
>