Блог

У нас есть вызывающе параллельная проблема — мы запускаем большое количество экземпляров одной программы с разными наборами данных для каждого; мы делаем это просто путем многократной отправки приложения в пакетную очередь с разными параметрами каждый раз.

Однако при большом количестве заданий не все из них завершаются. Похоже, что это не проблема в очереди — все задания запущены.

Проблема, по-видимому, заключается в том, что при большом количестве запущенных экземпляров приложения множество заданий завершается примерно в одно и то же время и, таким образом, все пытаются записать свои данные в параллельную файловую систему практически в одно и то же время.

Тогда проблема, по-видимому, заключается в том, что либо программа не может выполнить запись в файловую систему и каким-то образом выходит из строя, либо просто сидит там в ожидании записи, а система пакетной очереди завершает задание после того, как оно простояло в ожидании слишком долго. (Из того, что я собрал по проблеме, большинство заданий, которые не завершаются, если не все, не оставляют основных файлов)

Каков наилучший способ запланировать запись на диск, чтобы избежать этой проблемы? Я упоминаю, что наша программа возмутительно параллельна, чтобы подчеркнуть тот факт, что каждый процесс не знает о других — они не могут общаться друг с другом, чтобы каким-то образом запланировать свои записи.

Хотя у меня есть исходный код программы, мы хотели бы решить проблему без необходимости изменять это, если это возможно, поскольку мы не поддерживаем и не разрабатываем его (плюс большинство комментариев на итальянском).

У меня было несколько мыслей по этому поводу:

1. Каждое задание сначала записывается на локальный (scratch) диск узла. Затем мы можем запустить другое задание, которое время от времени проверяет, какие задания завершены, и перемещает файлы с локальных дисков в параллельную файловую систему.
2. Используйте MPI-оболочку вокруг программы в системе master / slave, где master управляет очередью заданий и отправляет их каждому подчиненному устройству; а подчиненная оболочка запускает приложения и перехватывает исключение (могу ли я сделать это надежно для тайм-аута файловой системы в C или, возможно, Java?) и отправляет сообщение обратно ведущему устройству для повторного запуска задания

Тем временем мне нужно обратиться к своим руководителям за дополнительной информацией о самой ошибке — я никогда не сталкивался с этим лично, но мне не приходилось использовать программу для очень большого количества наборов данных (пока).

На случай, если это полезно: мы запускаем Solaris в нашей системе HPC с системой пакетных очередей SGE (Sun GridEngine). Файловая система — NFS4, а серверы хранения также работают под управлением Solaris. HPC-узлы и серверы хранения обмениваются данными по каналам fibre channel.

Большинство параллельных файловых систем, особенно в суперкомпьютерных центрах, предназначены для приложений HPC, а не для устройств типа последовательной фермы. В результате они тщательно оптимизированы для пропускной способности, а не для IOPs (операций ввода-вывода в секунду) — то есть они нацелены на большие (более 1000 процессов) задания, записывающие несколько гигантских файлов, а не на миллиарды маленьких заданий, выводящих октиллионы крошечных файлов. Пользователям слишком просто запускать что-то, что работает нормально (ish) на их рабочем столе, и наивно масштабировать до сотен одновременных заданий, чтобы истощить систему IOPs, зависая на своих заданиях и, как правило, на других в тех же системах.

Главное, что вы можете здесь делать, — это агрегировать, агрегировать, агрегировать. Было бы лучше, если бы вы могли сообщить нам, где вы работаете, чтобы мы могли получить больше информации о системе. Но есть несколько проверенных стратегий:

1. Если вы выводите много файлов за задание, измените стратегию вывода таким образом, чтобы каждое задание записывало один файл, содержащий все остальные. Если у вас есть локальный ramdisk, вы можете сделать что-то столь же простое, как записать их на ramdisk, а затем перенести в реальную файловую систему.
2. Пишите в двоичном формате, а не в ascii. Большие данные никогда не передаются в формате ascii. Двоичные форматы в ~ 10 раз быстрее для записи, несколько меньше, и вы можете записывать большие куски за раз, а не несколько чисел в цикле, что приводит к:
3. Большие операции записи лучше, чем маленькие. Каждая операция ввода-вывода — это то, что должна выполнять файловая система. Делайте несколько больших операций записи, а не зацикливайтесь на крошечных операциях записи.
4. Аналогично, не записывайте в форматах, которые требуют от вас поиска для записи в разные части файла в разное время. Поиск выполняется медленно и бесполезно.
5. Если вы выполняете много заданий на узле, вы можете использовать тот же трюк с ramdisk, что и выше (или локальный диск), чтобы настроить все выходные данные заданий и отправить их все сразу в параллельную файловую систему.

Приведенные выше предложения улучшат производительность ввода-вывода вашего кода везде, а не только в параллельных файловых системах. Ввод-вывод везде медленный, и чем больше вы можете сделать в памяти и чем меньше фактических операций ввода-вывода вы выполняете, тем быстрее это произойдет. Некоторые системы могут быть более чувствительными, чем другие, поэтому вы можете не заметить этого на своем ноутбуке, но это поможет.

Аналогично, наличие меньшего количества больших файлов вместо большого количества маленьких ускорит все, от списков каталогов до резервных копий в вашей файловой системе; это хорошо для всех.