При использовании GNU Parallel это выглядит так:
parallel pngquant --my-options ::: *.png
или:
ls | grep \\.png | parallel pngquant --my-options
По умолчанию используется одно задание на ядро ЦП. В вашем случае вы можете запустить на одно задание больше, чем у вас есть ядер:
ls | grep \\.png | parallel -j+1 pngquant --my-options
Это связано с тем, что pngquant
использует время как для чтения, так и для записи данных. В это время он ожидает диск и почти не использует ЦП, поэтому у вас может быть некоторое время простоя ЦП. Единственный способ узнать наверняка — измерить и посмотреть, что быстрее.
GNU Parallel — это универсальный распараллеливатель, который позволяет легко выполнять задания параллельно на одной машине или на нескольких машинах, к которым у вас есть доступ по ssh.
Если у вас есть 32 разных задания, которые вы хотите запустить на 4 ЦП, прямой способ распараллеливания — запустить 8 заданий на каждом ЦП:
GNU Parallel вместо этого порождает новый процесс по завершении одного из них -, сохраняя активность ЦП и тем самым экономя время:
Установка
Из соображений безопасности вам следует установить GNU Parallel с помощью вашего менеджера пакетов, но если GNU Parallel не упакован для вашего дистрибутива, вы можете выполнить персональную установку, которая не требует root-доступа. Это можно сделать за 10 секунд, сделав это:
(wget -O - pi.dk/3 || curl pi.dk/3/ || fetch -o - http://pi.dk/3) | bash
Другие варианты установки см. вhttp://git.savannah.gnu.org/cgit/parallel.git/tree/README
Узнать больше
Посмотреть другие примеры:http://www.gnu.org/software/parallel/man.html
Посмотрите вступительные видеоролики:https://www.youtube.com/playlist?list=PL284C9FF2488BC6D1
Прохождение обучения:http://www.gnu.org/software/parallel/parallel_tutorial.html
Подпишитесь на список адресов электронной почты, чтобы получить поддержку:https://lists.gnu.org/mailman/listinfo/parallel
Вы просите меня угадать и установить для него верхнюю границу.
Могу попробовать поделиться своим опытом. Я не говорю, что вы не должны требовать высоких стандартов, я просто хочу реалистично относиться к стандарту, которому в настоящее время соответствует Linux :-).
С вашим объемом ОЗУ, подкачкой и типом хранилища. Если использование оперативной памяти связано с несколькими интерактивными приложениями. Взаимодействие происходит только с одним из них. Вы не оставили операцию запущенной ни в одном из других приложений. А в других приложениях нет большого количества вкладок с анимированной рекламой :). В таком случае, я думаю, вы делаете хорошее замечание! Моя текущая интуиция подсказывает, что необычно 10 минут для того, чтобы система прояснилась и заработала.
Считаю ли я, что вам стоит когда-нибудь подождать 10 минут , надеясь, что курсор мыши заработает и свет диска снова успокоится?
Не совсем так. Если надежда состоит в том, чтобы дождаться, пока графический интерфейс установится и станет пригодным для использования? Если для использования графического интерфейса потребуется даже 2 минуты , и моя цель состоит не только в том, чтобы начать закрывать некоторые окна текущего приложения переднего плана? Вы ожидаете, что эта задержка будет продолжаться снова. Это явно слишком долго.
Но, во-вторых, это может быть связано с различными возможными проблемами. Например, если половина проблемы заключается в параллельной операции во второй программе, о которой я не знаю, то рабочий набор системы может быть больше, чем ОЗУ. В таком случае, да, система может работать больше часов, чем вы можете сосчитать . Таким образом, вы не хотели бы ждать.
Если бы я пытался понять, что происходит не так , мой максимальный тайм-аут мог бы быть 15 минут . Это будет общее время ожидания для получения данных из последовательности, такой как:
sudo tmux
-текстовый оконный менеджер. Теперь я могу запускать несколько команд от имени пользователя root и переключаться между ними без задержек при входе в систему или sudo. atop -R
-я упоминал, что люблю atop
? iotop
-Ужасные задержки обычно связаны с вводом-выводом. Это хороший инструмент, который делает одну вещь :-). journalctl --since=-1hour -f