前言：

一个很偶然的出现的问题，因为我需要验证备份文件是否正确，因此，我在一台已启动了一个数据库实例的服务器上，依据全备的数据库文件在启动一个实例，当然，在此之前，已经修改了备份文件内的配置文件的端口为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

 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实例。