Я - пользователь кластера, использующий NFS для хранения данных. Недавно я запустил конвейер с очень большим количеством операций ввода-вывода во время некоторых операций.
Программа, которая, по нашему мнению, является причиной проблемы, называется Bowtie, выравниватель биоинформатических конвейеров. Короче говоря, у нас есть алфавитные последовательности во фрагментированных файлах по 1 миллиону строк на файл, которые сравниваются с другим файлом, содержащим весь словарь. (Это чрезмерное упрощение алгоритма)
Этот словарь отображается в памяти во время процедуры. У меня есть права на отправку очереди для трех узлов в кластере.
Узлы: Узел1 Узел2 Узел3 Узел4 Узел5 Узел6 Узел7
Мое право: Узел1 Узел2 Узел3
Количество доступных мне процессоров: 128 процессоров или 128 слотов рабочей очереди.
Для работы в кластере основной файл делится на блоки по 1 миллион строк каждый, а затем все задания запускаются с использованием SGE.
Словарь в этот момент загружается в память на каждый узел, то есть на узлы 1, 2 и 3.
Для каждого задания, активного в слоте очереди, у меня открыты следующие обработчики файлов
1 Файл задания, содержащий код для запуска 1 файл кода, содержащий код выхода процесса 1 Сгенерированный SGE файл STDOUT 1 Сгенерированный SGE файл STDERR 1 Фрагмент файла 1 Выходной файл
Это означает, что во время этого процесса у меня открыто 768 + 3 файловых обработчика в удаленном хранилище данных, хотя первые четыре файла являются постоянными для каждого отдельного скрипта в конвейере.
Всякий раз, когда это происходит, происходит сбой сервера NFS в хранилище данных, и весь наш кластер выходит из строя, потому что хранилище перестает отвечать.
Наши ИТ-специалисты предположили, что это может быть связано с большим количеством операций ввода-вывода во время этого процесса и, возможно, NFS когда-либо предназначалась только для небольших кластеров, а не для крупных.
Таким образом, мы работали над решением, в котором мы планируем запустить этот процесс на одном из узлов. Но тогда смысл наличия кластера в нашем распоряжении теряется, потому что мы будем записывать на диск узла, а не в хранилище данных, общее для всех кластеров.
Я не могу поверить в то, что NFS была создана для небольших кластеров и никогда не была успешно реализована на крупных корпоративных решениях. Может ли существовать еще одна причина, по которой NFS внезапно разрывает сетевое соединение?
Я уверен, что вопрос в том, что процесс является причиной зависания кластера, но я не уверен, что требуемая скорость чтения / записи является причиной сбоя. У кого-нибудь из вас раньше была такая проблема? Является ли полная миграция протокола единственным решением, которое у нас есть?
Несколько предложений усвоили с годами.
установить параметры экспорта NFS: async,insecure,no_subtree_check
установить параметры монтирования NFS soft,noatime,nodiratime,nolock,vers=3
также установите: noatime,nodiratime при монтировании data / tmp / scratch. Убедитесь, что шифрование NFS отключено, чтобы снизить нагрузку. Остановить процесс блокировки NFS.
Попробуйте включить кадры JUMBO для сети на всех хостах (если они поддерживаются сетевым оборудованием) - установите MTU равным 9 КБ или около того.
Убедитесь, что хранилище raid10 используется (избегайте raid5 / 6 любой ценой) для произвольной записи IO. Какие-нибудь SSD?
Максимально увеличьте количество открытых дескрипторов FS (в некоторых системах по умолчанию - 2 КБ), установите его на 1 МБ или около того.
Есть ли шанс скопировать базу данных сопоставления с входными данными в локальное хранилище рабочих узлов, а затем объединить / отсортировать полученные файлы sam в качестве отдельного шага?
Увеличьте размер обрабатываемого фрагмента (чтобы он обрабатывался не менее 30 минут или больше.
Если возможно разделение рабочих мест на максимально возможном уровне (попробуйте сопоставить / отсортировать 10 отдельных геномов / образцов на 10 разных узлах параллельно вместо того, чтобы пытаться сопоставить каждый геном последовательно с использованием 10 хостов). Попытаться установить контрольную точку после завершения всех процессов.
Измените источник программы, чтобы он считывал данные большими фрагментами - например, 1M вместо 4k.
Помните о конфликте между ЦП и ОЗУ (особенно в системах AMD с 4-8 сокетами), иногда выполнение 12-24 потоков на 48-ядерном блоке намного быстрее, чем 48 потоков. Попробуйте разные уровни использования. Убедитесь, что NUMA включен и настроен для многопроцессорных систем. Перекомпилируйте с включенным NUMA.
PS: Управление эффективным кластером аналогично планированию / управлению строительной площадкой с более чем тысячами рабочих ...