The Tor manual states:
Tor will ask the OS for as many file descriptors as the OS will allow (you can find this by "ulimit -H -n"). If this number is less than ConnLimit, then Tor will refuse to start.
This number appears to be the denominator of the fraction you see in Nyx (4064). It's returned from tor to Stem by the process/descriptor-limit control message.
The number of in-use file descriptors (4074) comes directly from Stem, which simply counts the number of items in /proc/$pid/fd.
return len(os.listdir('/proc/%i/fd' % pid))
The Tor source code also has a tuning document that describes how to increase the number of available file descriptors if you are running low.
Most operating systems limit an amount of TCP sockets that can be used
simultaneously. It is possible for a busy Tor relay to run into these
limits, thus being unable to fully utilize the bandwidth resources it
has at its disposal. Following system-specific tips might be helpful
to alleviate the aforementioned problem.
Linux
Use 'ulimit -n' to raise an allowed number of file descriptors to be
opened on your host at the same time.
The Nyx source code shows that it logs a warning message if the file descriptor usage is above 90%. You should check for this message.
log_msg = "Tor's file descriptor usage is at %s%%. If you run out Tor will be unable to continue functioning." % fd_percent
log.log_once('fd_used_at_ninety_percent', log.WARN, log_msg)
It would probably be a good idea to raise the limit in the kernel and see what happens. I wouldn't be sure that you'll get much more traffic, as some Tor relays aren't getting the max bandwidth that they specify in their torrc.
