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 <alfonso.moscato@xxxxxxxxxxx> 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 <rui@xxxxxxxxxxxxx> > Inviato: venerdì 20 luglio 2018 17:03 > A: Alfonso Moscato <alfonso.moscato@xxxxxxxxxxx> > Cc: Tom Lane <tgl@xxxxxxxxxxxxx>; 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. > > > > > >
