Есть ли какие-либо недостатки против использования qsub для выполнения задач все время?
Я вслепую не полагался бы на то, что Вы называете хорошей ОС, которая не делает паники ядра в каждом месяце. Факт, когда системы растут и становятся все более сложными, всегда будут времена, когда некоторые новые ошибки пробьются к магистрали. И я полагаю, что это верно для любого типа ОС или программы. Linux может иметь большую репутацию устойчивости (как закон Linus об ошибках предполагает), но тем не менее это - вопрос "рано или поздно".
Только предположите, что только критическая ошибка, которая инициировала панику ядра, может привести к катастрофическому отказу между действиями как 1 и 2 описанных сюда. Вы даже не могли бы знать, что повреждение произошло и было зафиксировано
fsckво время начальной загрузки благодаря журналу. Хуже, чем это, Вы не могли бы теперь, когда Ваша файловая система нежурналирования была повреждена, пока в какой-то момент вовремя некоторая программа не начинает отказывать из-за этого.Взгляд на Сравнение файловых систем - существует причина, почему даже последние типы файловой системы используют некоторую форму журналирования или эквивалентного механизма безопасности, разве Вы не думаете? И что все "нормальные" дистрибутивы используют его по умолчанию.
Другими словами: уверенный, можно попытаться быть более умными, чем файловая система и разработчики дистрибутива Linux или просто протестировать, как далеко можно обойтись без помощи функций как журналирование - но быть готовы не кричать, когда в какой-то момент вещи действительно разлагаются.
В этих случаях я открыл бы другой терминал. Какова причина, что Вы не хотите делать это?
Оборотная сторона выполнения qsub, то, что необходимо записать крошечный файл сценария для тривиальной операции, которая берет Вас некоторое время. Я не знаю, сколько другие пользователи работают над той же сетью, но цель предназначена как планировщик для заданий нескольких пользователей на кластере. Особенно, если не будет никаких свободных доступных ядер, то Ваше простое задание закончится в очереди, беря Вас больше времени.
Вы рассматривали screen как альтернатива? С screen можно запустить и приостановить другую сессию в том же терминале. Рабочий процесс был бы похож на это
- работа в терминале
$ screen- Ваши крошечные задания
- Экран отсоединения (Ctrl-d Ctrl-a)
- работа в терминале
$ screen -r(для возобновления)- Проверьте состояние этого крошечного задания
$ exit- И Вы вернулись
Я не вижу преимущества использования qsub по стандарту at. at команда возьмет "сценарий" и выполнит его в определенное время (как "теперь"), с помощью текущей среды. Затем можно проверить состояние с atq или удалите задание с atrm.
$ nohup ./myscript myargs & # put script in the background
# almost the same as
$ echo ./myscript myargs | at now # computer runs script independent of terminals
Действительно необходимо удостовериться что Ваш myscript не будет искать вход.
Самостоятельно, я использую screen на единственном терминальном сеансе везде я иду, как Bernhard предполагает. Откройте новое окно (в screen), запустите сценарий, переключатель назад к оригиналу screen окно.
Я не вижу недостатка к использованию qsub к фоновым заданиям, которые я обычно выполнял бы в интерактивном режиме в экране. Если Вы имеете кластер в наличии, то это - оптимальное решение.
Хотя мы имеем планировщик заданий в наличии, в течение долгого времени я был склонен использовать экран для фона продолжительные задания или достигать параллелизма без большой qsub записи сценария наверху. В конечном счете ограничения этого подхода стали очевидными, и я записал эту qsub обертку qgo позволить мне заменять & и screen с qsub:
#!/bin/bash
mkdir -p qsubscripts
qsub -w $(pwd)/qsubscripts -d $(pwd) -M user@addr.com $@ -S /bin/zsh -
Обратите внимание, что я использую свою предпочтительную оболочку (zsh), но конечно можно удалить этот аргумент или добавить других. Использование $@ допускает включение спецификаций ресурса как -l ncpus=4 по мере необходимости. Вот то, как Вы использовали бы сценарий:
echo 'command -a 23 -b zz' | qgo | tee jobids
STDERR.* и STDOUT.* файлы будут записаны в qsubscripts в текущем рабочем каталоге. На идентификаторах задания обеспечивают The working directory for the job is set as thecwd' также, который помогает записать эти короткие сценарии.