Я не уверен, как ядро Linux обрабатывает несколько драйверов файловой системы, и если поиск inode для каждой данной точки монтирования в файловой системе мешает другим точкам монтирования, или есть что-то еще, что замедлит работу системы в случае медленного файла системный драйвер в ядре, но смонтированная файловая система, управляемая этим драйвером, почти не используется.
Меня беспокоит NFS. Так замедляет ли драйвер NFS ядро Linux и / или пользовательское пространство, если операция, требующая быстрого ввода-вывода на диск, выполняется в локальной файловой системе?
Я предполагаю, что имея LD_LIBRARY_PATH или PATH может замедлить работу системы, так как ld и / или bash будет пытаться искать информацию в каталогах на NFS. Но действительно ли NFS как-то мешает, когда я открываю файл в локальной файловой системе?
Спасибо.
Каждый индексный дескриптор указывает на одну файловую систему, и ввод-вывод в / из этого индексного дескриптора обрабатывается исключительно этим драйвером файловой системы, независимо от того, какие другие драйверы файловой системы загружены в ядро.
В частности, NFS сама по себе не замедляет другие операции ввода-вывода. Конечно, если система забивается через NFS, то локальный ввод-вывод для этой файловой системы будет медленнее, но это из-за высокой скорости ввода-вывода для общего ресурса (дисков, лежащих в основе файловой системы), а не из-за чего-то особенного для NFS. IOW, если подсистема NFS простаивает, это никоим образом не должно влиять на локальный ввод-вывод.
И нет, NFS не будет мешать, если вы ищите файл в локальной файловой системе.
Я монтирую nfs с удаленного сервера в / nfs (50 каталогов и 100000 файлов). Затем пять раз создайте, запишите и прочтите файлы в другом месте:
time for i in {1..1000};do touch $i;done
time for i in {1..1000};do echo "$i" > $i;done
time for i in {1..1000};do cat "$i" > /dev/null;done
create: average 7.903s
write: average 0.068s
read: average 7.682s
Затем размонтируйте / nfs и снова протестируйте
create: average 7.923s
write: average 0.048s
read: average 7.782s
Затем перезапустите сервер и снова протестируйте (без / nfs)
create: average 7.901s
write: average 0.052s
read: average 7.582s
Если эффект есть, то он очень мал. Сервер: HP ProLiant DL160 G6, Linux 2.6.32-24-generic-pae
Приведенные выше ответы, хотя и верные, не касались поиска в библиотеке, который выполняется при каждом системном вызове, о котором вы спрашивали. Короче говоря, я провел тест на слегка загруженных системах, и системные вызовы NFS не потребовали дополнительного статистически значимого времени. У меня есть точка монтирования NFS /data/media что я добавил к LD_LIBRARY_PATH а затем я использую strace для отслеживания системных вызовов и времени их выполнения.
Для тех, кто не знаком с запуском исполняемого файла, каждая разделяемая библиотека должна быть найдена и загружена до того, как выполнение перейдет к main(), и именно здесь проверка NFS может стать потенциальной проблемой. Добавив смонтированный каталог NFS к пути загрузчика библиотеки, мы сможем выполнять простые временные тесты. Очевидно, что если сервер NFS не отвечает, выполнение всех новых процессов, скорее всего, остановится, особенно если точка монтирования установлена как «жесткая», то есть без опции «intr». Частично это связано с тем, что оболочка будет искать PATH для имени новой программы и застревает в точке монтирования NFS. Это не то, что мы собираемся измерять.
Вот код оболочки для запуска программы и документирования времени выполнения системного вызова. Еще раз обратите внимание, что у меня есть только одна точка монтирования NFS, /data/mediaв LD_LIBRARY_PATH просто для простоты.
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";
};'
Исходный вывод strace похож на этот
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>
И вывод похож на этот
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
Я выбрал Perl, потому что он мне удобен, но подойдет любая фильтрация текста.
Я бросил эти числа в электронную таблицу и отсортировал их, чтобы я мог показать вам эту таблицу
Avg (s) Max (s) Min (s)
NFS lag (s) -0.0000072 -0.000529 0.000007
NFS lag (%) -17.84% -90.74% 36.84%
Совершенно очевидно, что вы должны попробовать выбросить свой системный кеш в окно перед выполнением этого теста и посмотреть, изменит ли он что-то, но это не нормальное состояние для вашей системы.
Если у вас возникли проблемы с интерпретацией таблицы, были случаи, когда NFS на самом деле была быстрее, чем локальная файловая система. Это нелогично, пока вы не решите, что кэширование VFS, вероятно, происходит.
Поэтому я прихожу к выводу, что, по крайней мере, для этого небольшого теста наличие точки монтирования NFS в вашем LD_LIBRARY_PATH не влияет на время загрузки исполняемых файлов. Пока сервер NFS работает ...