The above answers, while correct, did not address the library searching that goes on with every system call that you asked about. In short, I ran a test on lightly loaded systems and the system calls against NFS took no additional, statistically significant time. I have an NFS mount point /data/media
that I added to LD_LIBRARY_PATH
and then I use strace
to track system calls and their time to execute.
For those unfamiliar with starting an executable, every shared library must be found and loaded before execution passes to main()
, which is where the probing of NFS could be a potential problem. By adding an NFS mounted directory to the library loader's path, we should be able to do simple timing tests. Obviously, if an NFS server is not responding, the execution of all new processes will likely halt, especially if the mount point is mounted as "hard," that is, without the "intr" option. This is partially because the shell will search the PATH
for a new program's name and gets stuck on the NFS mount point. That is not what we are about to measure.
Here is the shell code to run a program and document the syscall execution time. Note again that I only have one NFS mount point, /data/media
, in LD_LIBRARY_PATH just to keep it simple.
strace -T -e open java -version 2>&1 |\
perl -ne 'if (m/\/data\/media.*<(\d+\.\d+)>/) { \
print "nfs,$1\n";
} elsif (m/<(\d+\.\d+)>/) {
print "local,$1\n";
};'
The original strace output is similar to this
open("/usr/lib/jvm/java-6-sun-1.6.0.20/jre/bin/../lib/amd64/jli/tls/x86_64/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) <0.000041>
And the output is similar to this
local,0.000030
local,0.000031
nfs,0.000042
nfs,0.000029
nfs,0.000029
nfs,0.000030
local,0.000028
local,0.000027
local,0.000027
I chose perl because I'm comfortable with it, but any text filtering will do.
I threw these number in a spreadsheet and sorted them so that I could show you this table
Avg (s) Max (s) Min (s)
NFS lag (s) -0.0000072 -0.000529 0.000007
NFS lag (%) -17.84% -90.74% 36.84%
Quite obviously, you should try throwing your system cache out the window before doing this test and see if it changes things, but that's not the normal condition for your system.
In case you have trouble interpreting the table, there were cases where NFS was actually faster than the local filesystem. This is counter-intuitive until you consider that VFS caching is probably going on.
Therefore, I conclude that for at least this little tiny test, having an NFS mount point in your LD_LIBRARY_PATH does not affect load time for executables. As long as the NFS server is up...