причем zip слишком хороша (Mac OS X)

Я использую zip, чтобы сделать регулярное резервное копирование локального каталога на удаленную машину. Они не верят в вещи как rsync здесь, таким образом, лучше, чтобы я мог сделать (?). Вот сценарий, который я использую

echo $(date)>>~/backuplog.txt;
if [[ -e /Volumes/backup/ ]];
then 
    cd /Volumes/Non-RAID_Storage/;
    for file in projects/*; 
        do nice -n 10 zip -vru9 /Volumes/backup/nonRaidStorage.backup.zip "$file" 2>&1 | grep -v "zip info: local extra (21 bytes)">>~/backuplog.txt;
    done;
else 
    echo "backup volume not mounted">>~/backuplog.txt;
fi

Это все хорошо работает, за исключением того, что zip никогда не использует много ЦП, таким образом, это, кажется, занимает больше времени, чем это должно. Это никогда, кажется, не добирается выше 5%. Я пытался делать это хорошими-20, но это не имело никакого значения. Это - просто сужение трубы скоростей сети или скоростей диска процесс, или я делаю что-то не так?

2
задан 06.04.2010, 17:45

3 ответа

Вы, вероятно, найдете это zip проводит большую часть его времени, ожидая ввода-вывода (читающий файлы и пишущий сжатые версии), который является, почему он не использует столько ЦП, сколько Вы ожидаете. Предоставление процесса дополнительного приоритета через nice не имеет никакого эффекта на это, поскольку задача не может больше использовать процессорное время, если бы это не питаемые данные на уровне, который потребовал бы его к.

В соответствии с Linux Вы видите эту ситуацию как высокий %age, поскольку "IO Ожидают" время в выводе от top и подобные утилиты, то же может быть верным для OSX.

Причины в течение времени ожидания IO могли включать:

  1. обработка многих маленьких файлов (большое главное перемещение, читая файлы и связанные структуры каталогов)
  2. фрагментация файла
  3. конкуренция с другим действием по соответствующим дискам (пользовательские файлы копирования/перемещения/доступа, запланированные сканирования AV...), в то время как резервное копирование происходит
  4. чтение файлов по сети (современный ЦП может архивировать данные намного быстрее, чем ссылка 100Mbit/s, может когда-либо подавать его, и сетевая задержка усилит эффект много-маленьких файлов), или продвижение сжатых данных по сети (если Ваши данные не будут необычно сжимаемы, та же "zip быстрее затем, Ваша сеть на современных центральных процессорах" условие применяется, поскольку это будет читать из Ваших локальных дисков и обрабатывать daat быстрее, чем это может затем отправить результат по сети),
  5. конфликт в сети (если сервер Ваш говорит, имеет ссылку на 100 Мбит и других, использует его, это может быть проблемой, меньше если он имеет более быструю ссылку, конечно),
  6. замедлите диски или медленные интерфейсы (если какой-либо из затронутых дисков будет USB2, соединенным, то они будут иметь тенденцию передавать не больше, чем 25Mbyte/sec, иногда медленнее в зависимости от используемого адаптера USB и конкуренция Шины USB с другими быстрыми устройствами, где современный внутренний диск продвинет дважды что если не больше для объемных передач),

Если Вы хотите использовать "запасные" циклы ЦП и не можете сделать так путем сокращения задержек IO, Вы могли попытаться использовать 7zip вместо этого - это использует намного больше процессорного времени на блок данных, но достигает лучшего сжатия, чем zip некоторым полем слишком во многих случаях, уменьшая размер Ваших резервных копий. Будет ли это быстрее (потому что 7zip приводит к отправке меньшего количества данных по сети), или медленнее (потому что дополнительная вычислительная сложность означает Вас, ЦП может стать узким местом не диски/файловые системы/сеть), зависит от Ваших машин точная спецификация.

Править:

Еще одна вещь, некоторый процесс отчета об инструментах использует на ядро и некоторые на ЦП (и некоторые так или иначе в зависимости от настроек), и zip обычно является потоковым процессом. Таким образом, если у Вас есть четырехъядерный ЦП, что 5% вряд ли не будут "5% ЦП" или приблизительно 20% одного ядра (хотя это может возвращаться между ядрами, если это является единственным, распараллелил его, не будет работать больше чем на одном ни в какой данный момент).

7
ответ дан 08.12.2019, 04:51

"хороший-n 10" заставляет рассматриваемую программу быть еще "более хорошей" при помощи более низкого приоритета. Возможно, Вы имели в виду "хороший-n-10" или "хороший - 10", который делает программу менее "хорошей", и таким образом используйте больше ЦП.

1
ответ дан 08.12.2019, 04:51

вот мой сценарий как есть, если кому-либо интересно. Очевидно, существует несколько трудно кодированных путей в здесь, таким образом, Вы не можете просто выполнить его как есть. Это сохраняет журнал своих операций и использует рычание для уведомления Вас относительно любых ошибок. Если у Вас нет рычания / не хотят устанавливать его, просто комментировать / удаляют любую из строк с growlnotify в них.

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

localBaseDirectory=/Volumes/Non-RAID_Storage/;
backedUpDirectory=projects;
backupVolume=/Volumes/video-prod/Backup;
backupFile=$backupVolume/Non-RAID_Storage_backup.zip;
zipTempfile=/Volumes/B_media
localBackupTempFile=/Volumes/A_Media/backuptemp.zip;
log=~/backuplog.txt;
temp=/var/tmp/backupError.txt;
##############################################
/usr/local/bin/growlnotify -m "backing up $backedUpDirectory on $localBaseDirectory" 2>&1 >/Dev/Null  #need this redirect because growl chucks errors when run by cron;

echo $(date) > $log
if [[ -e $backupVolume ]];
then 
   if [[ -e $backupFile ]];
        then cp $backupFile $localBackupTempFile;
        mv $backupFile "$backupFile-old";
        echo "copied old backup to $backupFile-old">>$log;
    fi;
    cd $localBaseDirectory 2>$temp;
    if [[ -s $temp ]];
        #notify if there was an error cding to this directory. -s is true if the file exists and is not zero sized
        then cat $temp | /usr/local/bin/growlnotify -s;
        cat $temp >> $log;
    fi;
    for file in $backedUpDirectory/*;
    do
        /usr/local/bin/growlnotify -m "backing up $file" 2>&1 >/Dev/Null;
        #zip using verbose, recursive, update (ie don't overwrite files unless they're older), highest level compression
        #zip creates a lot of garbage errors when being verbose eo send errors to a temp file, and stdout to the log file
         nice -n 10 zip -vru9 -b $zipTempfile $localBackupTempFile "$file" 2>$temp |grep "adding:">>$log;
         #add just the important errors to the log
         cat $temp 2>/dev/null|grep "error:">>$log;
    done;
    echo "done adding to local zip file - moving to $backupFile">>$log;
    #move the local version to the remote backup file
    mv $localBackupTempFile $backupFile 2>>$log;
    echo "$(date) - backed up Non-RAID_storage">>$log
    /usr/local/bin/growlnotify -m "backed up $backedUpDirectory on $localBaseDirectory" 2>&1 >/Dev/Null;
else 
    /usr/local/bin/growlnotify -s -m "Backup volume not mounted" 2>&1 >/Dev/Null;
    echo "backup volume not mounted" >> $log;
fi;
1
ответ дан 08.12.2019, 04:51

Теги

Похожие вопросы