postgresql|数据库|启动数据库时报错:FATAL: could not map anonymous shared memory的解决

前言:

一个很偶然的出现的问题,因为我需要验证备份文件是否正确,因此,我在一台已启动了一个数据库实例的服务器上,依据全备的数据库文件在启动一个实例,当然,在此之前,已经修改了备份文件内的配置文件的端口为5444,以防止端口占用,造成第二个数据库实例无法启动。

很不幸的,不出意外的出意外了,启动报错如下:

postgres@digoal-> FATAL:  XX000: 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 3322716160 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
LOCATION:  CreateAnonymousSegment, pg_shmem.c:398

一,

问题解析:

虽然这个报错里的每一个单词我都认识,但很可惜,它们合在一起的时候我还是陷入了迷茫,我发现我并不能准确的理解这个报错。

OK,但报错里的一些关键字很显然能给我提供一些信息,例如,

shared memory: Cannot allocate memory

 那么,这个报错提示我们是一个关于内存方面的错误的设置,postgresql里关于内存的设置有如下:

#shared_memory_type = mmap              # the default is the first option
                                        # supported by the operating system:
                                        #   mmap
                                        #   sysv
                                        #   windows
                                        # (change requires restart)
dynamic_shared_memory_type = posix      # the default is the first option

但是,第一个数据库是可以正常启动的,因为第一个数据库就是使用的这样的默认配置,因此,可以排除是postgresql的配置文件内的内存设置是有问题的。

如果说postgresql配置的内存选项有问题,这个从逻辑上是说不通的

检查服务器的内存,可以看到内存剩余的也是比较充裕的。

OK,那么,关于内存的设置只有一个内核优化的部分了

其中内核优化部分,关联内存的选项有一项引起了我的注意:

vm.overcommit_memory=2

二,

关于vm.overcommit_memory

postgresql|数据库|启动数据库时报错:FATAL: could not map anonymous shared memory的解决_第1张图片

 OK,之前设置的覆盖内存值是2,表示谨慎状态,以保持系统的问题,那么,1的值是宽松状态,表示内存全部用完,不做任何限制,0则是警告状态,能不能正确运行程序内核不参与,但如果内存不够,它将会报警。

那很明显,vm.overcommit_memory的值是2的时候,内存策略限制有点严重,经free命令查看,其实内存是够的,因此,vm.overcommit_memory的值修改为1即可解决以上的报错,第二个数据库就可以正常运行了

具体操作是编辑  /etc/sysctl.conf 文件,增加vm.overcommit_memory=1 这个选项,如果没有此项的话,如果vm.overcommit_memory的值不是1,修改成1即可。

sysctl -p 激活内核优化选项,完美运行两个postgresql实例。

你可能感兴趣的:(postgresql数据库,数据库,postgresql,运维,linux,云原生)