On 2020-01-03 13:01, Amit Kapila wrote:
> 2020-01-02 19:51:05.687 CET [24138:3] FATAL: insufficient file
> descriptors available to start server process
> 2020-01-02 19:51:05.687 CET [24138:4] DETAIL: System allows 19, we
> need at least 20.
> 2020-01-02 19:51:05.687 CET [24138:5] LOG: database system is shut down
>
> Here, I think it is clear that the failure happens because we are
> setting the value of max_files_per_process as 26 which is low for this
> machine. It seems to me that the reason it is failing is that before
> reaching set_max_safe_fds, it has already seven open files. Now, I
> see on my CentOS system, the value of already_open files is 3, 6 and 6
> respectively for versions HEAD, 12 and 10. We can easily see the
> number of already opened files by changing the error level from DEBUG2
> to LOG for elog message in set_max_safe_fds. It is not very clear to
> me how many files we can expect to be kept open during startup? Can
> the number vary on different setups?
Hm, where does it get the limit from? Is it something we set?
Why is this machine different from everybody else when it comes to this
limit?
ulimit -a says:
$ ulimit -a
time(cpu-seconds) unlimited
file(blocks) unlimited
coredump(blocks) unlimited
data(kbytes) 262144
stack(kbytes) 4096
lockedmem(kbytes) 672036
memory(kbytes) 2016108
nofiles(descriptors) 1024
processes 1024
threads 1024
vmemory(kbytes) unlimited
sbsize(bytes) unlimited
Is there any configuration setting I could do on the machine to increase
this limit?
/Mikael