У меня есть несколько серверов, используемых для вычислений HPC / кластеров, и я заметил, что, учитывая тот факт, что часть вычислений, которые они выполняют, используют огромные файлы через NFS, это вызывает значительные узкие места. Мне интересно, как решить эту проблему.
Настройка:
Одно из вычислений, выполняемых этим кластером, включает чтение для каждого из «ведомых» очень больших наборов файлов (3Гб + 3Гб + 1,5 Гб + 750М) перед запуском различных вычислений. Я заметил, что когда это происходит, большинство ведомых устройств на самом деле тратят значительное время (несколько минут) на их чтение (в то время как фактические вычисления выполняются намного быстрее).
В настоящее время я увеличил количество потоков в демоне NFS head2 и поставил rsize и wsize до 32k в вариантах монтажа slave, но все же это серьезное узкое место.
Что я могу сделать для повышения производительности или разрешить ведомым устройствам размещать эти файлы на своих жестких дисках? Или мне использовать для хранения совершенно другую ФС?
Скорее всего, это не ограничение NFS, с которым вы здесь столкнулись.
Также примите во внимание, что эти 5 ГБ занимают как минимум 40 секунд для передачи на гигабитной проводной скорости - для каждого клиента. У вас 32 из них бьют по голове2, и они вряд ли будут запрашивать одни и те же блоки одновременно. Добавьте к этому накладные расходы Ethernet, TCP / UDP и NFS, и вы скоро получите те минуты, которые вы описали.
Итак, прежде чем вы попытаетесь заменить NFS чем-либо еще (да, есть протоколы с меньшими накладными расходами), проверьте каждую часть пути, по которой данные (начиная с дисковой подсистемы), проходят на наличие возможных узких мест. Тест, если есть сомнения.
Устранить эти узкие места (если они есть) с помощью дополнительного или лучшего оборудования будет проще, чем полностью изменить настройку программного обеспечения.
Поскольку вы проводите анализ производительности, первый вопрос должен быть таким: «На каких данных я основываю свое предположение? Существуют ли сетевые трассы или другие данные о производительности, которые подтверждают эту гипотезу?»
В такой системе много возможных узких мест, и я бы поставил под сомнение выбор сетевой файловой системы в последнюю очередь, особенно потому, что вы, похоже, не записываете значительные объемы данных и блокировку / параллелизм, а сопутствующие проблемы с задержкой будут наиболее вероятными Причины узких мест с NFS.
С другой стороны, 32 одновременных запроса на 8 ГБ данных каждый могут перегрузить любой отдельный диск SATA из-за довольно ограниченного рейтинга операций ввода-вывода в секунду для одного диска. Простой расчет, предполагающий размер блока чтения 64 КБ на запрос и 100 операций ввода-вывода в секунду для диска, даст скорость всего 6,4 МБ / с для случайных запросов чтения - это то, что вы получите с таким количеством одновременных считывателей, если только вы сильно кешируете данные.
Вам следует внимательно изучить показатели эффективности, предоставляемые iostat чтобы увидеть, не перегружен ли ваш диск. И если это так, примите соответствующие меры (например, получите приличную подсистему хранения, способную справиться с нагрузкой), чтобы исправить ситуацию.
У меня очень похожая среда (множество блейд-серверов в качестве рабочих узлов и огромные файлы на каждом из нескольких ГБ или даже ТБ). Я использую распределенную файловую систему Hadoop (HDFS). Проверять, выписываться:
http://en.wikipedia.org/wiki/Hadoop_Distributed_File_System#Hadoop_Distributed_File_System
http://hadoop.apache.org/docs/r0.18.0/hdfs_design.pdf
Однако вы можете найти его немного сложнее в настройке, чем NFS.