OSX apparently defaults to 256 maximum file descriptors and bad things happen #2522

1. 
   gmaxwell commented at 11:47 PM on April 13, 2013: contributor

   I'm able to make leveldb alone use >500 FDs when txindex=1 is enabled. When we run out, it crashes. By default leveldb uses up to 1024 FDs, this is probably potentially problematic even on linux systems (which normally have a 1024 limit). I could see this becoming another non-deterministic fork producing issue in the future once our databases are much bigger (e.g. the network forking into txindex=0 vs 1 nodes)... though right now it looks like the nodes simply go down when they bump into the process limit.

   We can reduce the number of FDs that leveldb may use, we can look into increasing the allowed FDs on OSX. I suppose we should probably do both.

2. 
   laanwj commented at 8:28 AM on April 14, 2013: member

   Seems people are experiencing the same problem on other Unixes. It's not just MacOSX: https://code.google.com/p/leveldb/issues/detail?id=60

   Interestingly, Mike Hearn already mentions this problem in his first post about using LevelDB for Bitcoin:

   Another gotcha was the number of file descriptors, LevelDB defaults to
   1000 per DB. We originally used multiple DBs, one for each of the
   indices, but it was easy enough to combine everything into one table,
   thereby solving the fd issue. (Lowering the file descriptor limit also
   works of course, but if you lower it too much, LevelDB will start to
   spend a lot of time opening and closing files, so I believe combining
   your tables into one is the better option.)
   

   1000 is still too many even on Linux, as Bitcoin potentially uses lots of FDs for the network connections as well, both P2P and RPC.

   Changing the limit per database is a matter of setting options.max_open_files where the database is created. What would be a safe number?

   Maybe it would it be an idea to query the OS's limit using ulimit, then set it to a percentage of that? This leaves the number of allowed FDs as a tuning knob to the user on the OS level.

3. 
   sipa commented at 8:42 PM on April 23, 2013: member

   Anyone feel like benchmarking with options.max_open_files set to 50 or 100 or so? My guess: no difference.

4. 
   sipa commented at 11:28 PM on April 29, 2013: member

   Closed via #2557 and #2568

5. sipa closed this on Apr 29, 2013

   ---

6. MarcoFalke locked this on Sep 8, 2021

Milestone
v0.8.2