在一个JAVA应用程序的Ubuntu 14.04服务器上，我们得到Postgres太多的Open文件错误（使用Postgresql 9.5）。
我们在/etc/security/limits.conf中设置以下内容
* soft nofile 16384 * hard nofile 16384 root soft nofile 16384 root hard nofile 16384 postgres soft nofile 16384 postgres hard nofile 16384 还要在/etc/sysctl.conf中设置以下内容
kern.maxfiles=20480 kern.maxfilesperproc=18000
另外请以Postgres用户身份运行时查看以下结果：
-> ulimit -Hn 16384 -> ulimit -Sn 16384 -> cat /proc/sys/fs/file-max 100268
在重新启动服务器并检查Postgres 100268的ulimit。但在检查postgres进程下的打开文件的限制仍然是1024和4096
# cat /proc/1072/limits Max open files 1024 4096 files
当我们重新启动postgres服务，它变成了
#cat /proc/1759/limits Max open files 16384 16384 files
但它似乎没有受到影响，因为我们仍然得到“太多打开文件”的错误。
另外在服务器目录/etc/security/limits.d/和/etc/security/conf.d/中是空的。 所以任何人都可以请指导我。
啊…已知的问题。
通常人们开始编辑“/etc/security/limits.conf”文件，但忘记这个文件只适用于通过pam系统login的用户。
如果使用init脚本手动启动数据库，那么数据库过程将inheritance您的修改后的限制，如果数据库在启动时启动，或者由systemd启动，则不会。
有一些文件是Debian的“/ etc / defaults / $ service”和“RedHat的”/ etc / sysconfig / $ service。 在守护进程运行之前，这些文件是init脚本的源代码。 将ulimit -s unlimited或somethig这样的文件添加到这些文件中。 这些限制将被应用在init脚本shell中，并会影响数据库进程。
内核最大文件也应该被设置。
@dilyin感谢您的更新。
我们更新了PostgreSQL启动脚本中的ulimit值，但问题仍然存在。
最后，我们通过将max_files_per_process从默认值1000降低到200来解决这个问题。该参数在postgresql.conf文件中，这个参数设置允许每个服务器子max_files_per_process同时打开文件的最大数量。