zip sendo muito legal (Mac OS X)

Question

Eu uso o zip para fazer um backup regular de um diretório local em uma máquina remota. Eles não acreditam em coisas como o rsync aqui, então é o melhor que posso fazer (?). Aqui está o script que eu uso

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

Isso tudo funciona bem, exceto que o zip nunca usa muita CPU, então parece estar demorando mais do que deveria. Nunca parece ficar acima de 5%. Tentei torná-lo legal -20, mas isso não fez nenhuma diferença. É apenas a rede ou o disco que acelera o processo ou estou fazendo algo errado?

    

Answer 1

Você provavelmente descobrirá que zip está gastando a maior parte do tempo esperando por E / S (lendo arquivos e gravando as versões compactadas) e é por isso que não está usando a quantidade de CPU que você espera. Dar prioridade extra ao processo via nice não tem efeito sobre isso, pois a tarefa não pode usar mais tempo de CPU se não estiver sendo alimentada com dados a uma taxa que exigiria isso.

No Linux, você pode ver essa situação como uma% de idade alta como o tempo "IO Wait" na saída de top e utilitários semelhantes, o mesmo pode ser verdade para o OSX.

Os motivos para o tempo de espera do pedido de veiculação podem incluir:

1. processando muitos arquivos pequenos (muito movimento da cabeça lendo os arquivos e estruturas de diretório relacionadas)
2. fragmentação de arquivos
3. competindo com outras atividades nas unidades relevantes (usuários copiando / movendo / acessando arquivos, verificações AV agendadas, ...) enquanto o backup ocorre
4. ler os arquivos em uma rede (uma CPU moderna pode compactar dados muito mais rapidamente do que um link de 100Mbit / s pode alimentá-los e a latência da rede exacerbará o efeito de muitos arquivos pequenos) ou empurrando os dados compactados rede (a menos que seus dados sejam excepcionalmente compactáveis, a mesma condição "zip é mais rápido que sua rede em CPUs modernas" se aplica, pois lerá suas unidades locais e processará o daat mais rápido do que pode enviar o resultado pela rede)
5. contenção de rede (se o servidor com o qual você está falando tem um link de 100 Mbits e outros estão usando, isso pode ser um problema, menos ainda se ele tiver um link mais rápido, é claro)
6. unidades lentas ou interfaces lentas (se alguma das unidades envolvidas estiver conectada via USB2, elas tenderão a transferir não mais do que 25Mbyte / s, às vezes mais lento, dependendo do adaptador USB usado e da contenção do barramento USB com outros dispositivos rápidos. drive interno moderno vai empurrar o dobro que se não mais para transferências em massa)

Se você quiser usar os ciclos de CPU "sobressalentes" e não puder reduzir os atrasos de IO, pode tentar usar o 7zip - isso usa muito mais tempo de CPU por bloco de dados, mas alcança melhor compactação do que zip por bastante margem também em muitos casos, reduzindo o tamanho de seus backups. Se isso será mais rápido (porque o 7zip resulta no envio de menos dados pela rede) ou mais lento (porque a complexidade computacional extra significa que a CPU pode se tornar o gargalo não os discos / sistemas de arquivos / rede) depende das especificações exatas da sua máquina.

Editar:

Uma outra coisa, algumas ferramentas relatam o uso do processo por núcleo e algumas por CPU (e algumas dependendo das configurações), e o zip geralmente é um processo encadeado. Então, se você tem uma CPU quad-core, é improvável que 5% seja "5% da CPU", ou aproximadamente 20% de um núcleo (embora possa estar saltando entre os núcleos, se for single threaded, não estar sendo executado em mais de um em um determinado instante).

    

Answer 2

"nice -n 10" torna o programa em questão ainda mais "bonito" usando uma prioridade mais baixa. Talvez você quisesse dizer "nice -n -10" ou "nice --10", o que torna o programa menos "legal" e, portanto, usa mais CPU.

    

Answer 3

aqui está meu roteiro, se alguém estiver interessado. Obviamente, existem alguns caminhos codificados aqui, então você não pode simplesmente executá-lo como está. Ele mantém um log de suas operações e usa o growl para notificá-lo de quaisquer erros. Se você não tem growl / não quer instalá-lo, apenas comente / remova qualquer uma das linhas com growlnotify nelas.

Uma das outras alterações que fiz foi copiar o arquivo zip remoto para uma unidade local antes de adicionar os arquivos. O que estava acontecendo era que o zip estava copiando o arquivo para o arquivo temporário local, fazendo as alterações e, em seguida, movendo o arquivo temporário de volta para a unidade remota, para cada arquivo / pasta no diretório de nível superior. Então agora só faz a pesada rede levantar uma vez. Eu estou meio que pensando que eu deveria estar olhando para o alcatrão para esse tipo de coisa ..

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;