Re: New PG14 server won't start with >2GB shared_buffers

I just don't get what all this fuss is about trying to get PG up on the
smallest possible values for shared_buffers, especially considering this
person has 1 TB of memory?

Chris Hoover wrote on 2/25/2023 8:07 AM:
> Ron,
>
> Honestly, I grabbed 500MB to get the database up, by this time I was
> very frustrated and just wanted it up.  :)  I think I was at 1500MB
> and it still would not start.  So to save what was left of my evening
> out, I just picked 500.
>
> Here is shmall:
> kernel.shmall = 17179869184
>
> Thanks,
>
>
> Chris Hoover
> Senior DBA
> AWeber.com
> Cell: (803) 528-2269
> Email: chrish(at)aweber(dot)com
>
>
>
>> On Feb 25, 2023, at 5:25 AM, Ron <ronljohnsonjr(at)gmail(dot)com> wrote:
>>
>> Why did you have to drop shared buffers to 500MB, instead of
>> something just below 2GB?
>>
>> And what's "your kernel's SHMALL parameter"?
>>
>> On 2/24/23 20:08, Chris Hoover wrote:
>>> Hello All,
>>>
>>> Have a strange issue that I can not solve.
>>>
>>> I have a new server that has 1TB ram (not a typo).  I have been
>>> fighting with this evening to start up with a shared_buffer setting
>>> over 2GB.  When the memory allocation  breaks 2GB, the database
>>> won’t start.  I’ve dropped it down to 500M to get the database
>>> online.  We’ve tried both SysV memory and mmap memory.
>>>
>>> Any ideas on what is going on and how to resolve?  I’m sure I’m
>>> missing something obvious, but it is totally eluding me.
>>>
>>> OS: Ubuntu 18.04
>>> Memory:  1007GB
>>> CPU: Intel(R) Xeon(R) CPU           X7550  @ 2.00GHz (64 cores total)
>>>
>>> Kernel Memory:
>>> kernel.shmmax = 274877906944
>>> kernel.shmall = 17179869184
>>>
>>> Postgres Config:
>>>                   name                                  |          
>>>      setting
>>>  autovacuum_max_workers                 | 3
>>>  autovacuum_work_mem                     | -1
>>>  effective_cache_size                           | 98992128
>>>  fsync                                                    | on
>>>  full_page_writes                                  | on
>>>  maintenance_work_mem                    | 2097152
>>>  shared_buffers                                    | 64000
>>>  shared_memory_type                         | sysv
>>>  temp_buffers                                       | 4096
>>>  wal_buffers                                         | 2048
>>>  work_mem                                          | 119990
>>>
>>> If you need additional parameters, please ask
>>>
>>> SysV Error:
>>> Feb 25 01:55:16 appdb-server01.production.aweberint.com
>>> postgres[34680]: FATAL:  could not create shared memory segment:
>>> Cannot allocate memory
>>> DETAIL:  Failed system call was shmget(key=2359323, size=2063564800,
>>> 03600).
>>> HINT:  This error usually means that PostgreSQL's request for a
>>> shared memory segment exceeded your kernel's SHMALL parameter.  You
>>> might need to reconfigure the kernel with larger SHMALL.
>>>
>>> Mmap Error:
>>> FATAL:  could not map anonymous shared memory: Cannot allocate memory
>>> HINT:  This error usually means that PostgreSQL's request for a
>>> shared memory segment exceeded available memory, swap space, or huge
>>> pages. To reduce the request size (currently 1635737600 bytes),
>>> reduce PostgreSQL's shared memory usage, perhaps by reducing
>>> shared_buffers or max_connections.
>>>
>>> Thanks,
>>>
>>>
>>> Chris Hoover
>>> Senior DBA
>>> AWeber.com
>>> Cell: (803) 528-2269
>>> Email: chrish(at)aweber(dot)com
>>>
>>>
>>>
>>
>> --
>> Born in Arizona, moved to Babylonia.
>

Regards,

Michael Vitale

Michaeldba(at)sqlexec(dot)com <mailto:michaelvitale(at)sqlexec(dot)com>

703-600-9343