Depends on what you have configured. That's a tunable kernel parameter. You can see what you're currently configured at by cat'ing out the sysctl's value:

Code:

[root@campusweb master]# cat /proc/sys/fs/file-max
1615740
[root@campusweb master]#

It's a tunable parameter pretty much because there isn't a correct or incorrect number. If there were only one correct answer, or only one correct way to get to the one correct answer, then the kernel/multipathd would have been designed to just do that thing and leave you out of the mix. If you're not running into any starvation issues then you're ok. I've seen 8192 before plenty of places. It's an acceptable number (but I don't know what your workload is, that number is actually incredibly low if you're going to install Oracle for instance).

The same is true for the multipath.conf setting. They try to fix sane defaults but ultimately it's a tunable because for a lot of things humans are just better at picking configuration values than machines are. Symptoms of multipathd starvation issues include it throwing warnings to messages, not all paths being detected by multipathd, etc. AFAIK there aren't many drawbacks to having a high descriptor limit with multipath, it's just giving the administrator the ability to cap it off keeps multipathd from eating up all the file descriptors if some NetApp appliance (or whatever) goes schizo and starts presenting a million paths to the same LUN.

Long and short of it is: Play around with it, find something that seems to work well on that server and just save/document it.

Basically, this parameter controls how the kernel data structures are allocated in the kernel. Higher amounts of descriptors can slow down write/read operations, while too low of numbers can lead to descriptor starvation. Playing around with this number (while not damaging in any lasting way) isn't the only way to alleviate starvation. You might consider using limits.conf to set default limits for most users and just have the process that needs the most descriptors have a higher limit than everyone else (which is SOP for installing Oracle on a RHEL box, specifically to address starvation).