Nice rsync su macchina remota


25

Quando si utilizza rsync + ssh per accedere a una macchina remota, esiste un modo per "semplificare" il processo rsync sulla macchina remota (per ridurne la priorità)?

Modifica della domanda per chiarire:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
backups  16651 86.2  0.1   3576  1636 ?        Rs   11:06   0:06 rsync --ser...

(rsync line snipped)

Questo è un cron job di backup che normalmente viene eseguito alle 4 del mattino, ma quando mi capita di essere sveglio (e commettere, o usando Bugzilla ospitato su quella stessa macchina), uccide le prestazioni del server, quindi volevo un veloce "hack" per provare a risolvere un po '.

Risposte:


35

È possibile utilizzare l' --rsync-pathopzione, ad es.

rsync --rsync-path="nice rsync" foo remotebox:/tmp/

15
Potresti considerare di usare anche ionice , ad esempio --rsync-path="ionice -c 3 nice rsync", sebbene i moderni Linux riducano automaticamente la priorità di I / O per i processi più belli (vedi la pagina man che ho collegato).
Jo Liss,

Ci ho già provato, ma il mio SSH è ancora in esecuzione anice 0
Felipe Alvarez il

su sistemi come FreeBSD dove non hai ionice, impostare l' --bwlimitopzione è buona per una rsync più piacevole.
deed02392,

1
Ho anche avuto un problema con questa opzione senza fare alcuna differenza. Si è scoperto che il server a cui mi connettevo era configurato in authorized_keys per accettare solo un comando rsync specifico, che stava sovrascrivendo l' --rsync-pathopzione che stavo specificando.
Andy Beverley,

7
  • Prendendo l' --rsync-pathopzione che hairsync --rsync-path="ionice -c 3 nice -n 12 rsync" localDirectory remoteHost:/tmp/
  • Prendendo l' opzione del file di configurazione è possibile modificare o rimuovere il commento nel file /etc/default/rsyncdal RSYNC_NICE='17'valore e dal RSYNC_IONICE='-c3'valore

Per entrambi il valore ionico sarà la priorità del disco rigido

  • 1 -> tempo reale
  • 2 -> Miglior sforzo
  • 3 -> Ildle (quando nessun altro processo non utilizza l'HD)

Si noti che per Linux solo lo cfqscheduler implementa realmente le classi e le priorità IO. Se l'amministratore di sistema remoto ha optato per lo scheduler IO noop, deadlineo qualche variante più esotica, potresti scoprire che ionicenon fa davvero nulla. Uno dovrebbe essere in grado di ottenere alte prestazioni da cfqed essere ancora in grado di utilizzare le classi e le priorità IO ottimizzando correttamente cfq .

per un buon valore per la priorità del processore

  • -20 (più favorevole al processo)
  • (valore predefinito 10) se -n non è specificato
  • 19 (meno favorevole al processo)

Di chi è responsabile /etc/default/rsync? Rsync stesso sta leggendo questo file o è fatto da linux-flavour / distribution?
Guettli,

... Penso di aver trovato la soluzione /etc/default/rsyncè il file predefinito per la modalità demone rsync. Immagino che si applichi solo se ti connetti al demone rsync tramite il protocollo rsync. Immagino che non si applichi se lo chiami via ssh.
Guettli,

2

Una soluzione rapida e sporca sarebbe quella di creare un piccolo script wrapper chiamato 'rsync' che ombreggia $ PATH prima del vero binario rsync come:

#!/bin/sh
nice -10 /path/to/proper/rsync $*

Oppure imposta il file authorized_keys in modo che esegua il nicing di rsync. (Supponendo che tu stia usando i tasti ssh).

esempio:

command=”/home/user/bin/nice-rsync.sh" ssh-dss asdf....

Ora nel tuo /home/user/bin/nice-rsync.sh

#!/bin/sh
case $SSH_ORIGINAL_COMMAND in
  rsync\ --server*)
    nice -10 $SSH_ORIGINAL_COMMAND
    ;;
  *)
    $SSH_ORIGINAL_COMMAND
    ;;
esac

HTH


2

È possibile disabilitare la compressione lungo la rete, non includendo l' -zargomento, che potrebbe far risparmiare tempo alla CPU su entrambi i lati. O cambia il modo in cui rsync usa i checksum, guarda--checksum


Ho accettato la risposta di Hasturkun (dal momento che ha risposto alla mia domanda), ma hai sollevato un buon punto: ho fatto un benchmark con compressione vs senza compressione, e ha aggiunto solo 2 minuti al lavoro. Mi sono appena abituato a usare -avz come flag che non ho mai pensato di far cadere -z.
derisione del

La mia abitudine è usare -aPh, raramente uso -z
Rory il

0

Rsync non dovrebbe usare molta CPU. Dubito che tu possa forzare una certa gentilezza dall'altra parte, ma ciò che potresti fare è limitare la larghezza di banda che rsync sta usando con un firewall, il che alla fine ridurrebbe la quantità di elaborazione che potrebbe fare in X tempo.


Aggiunti alcuni output da 'ps aux' per mostrare cosa sta facendo per quanto riguarda la CPU. Sto andando su un collegamento lento, quindi ho l'opzione --compress attivata, ma sta anche causando una buona quantità di accesso al disco, che speravo di abbattere usando nice (effetto collaterale non intenzionale)
mwalling

L'impostazione di un buon valore di solito influisce anche sulla gentilezza dell'I / O, che è ciò che di solito si desidera.
Bram Schoenmakers,

rsyncnon richiede molta CPU ma potrebbe apparire topcomunque a seconda che il kernel corrente consideri I / O wait come occupato. Inoltre, se qualsiasi altro processo deve accedere allo spazio di archiviazione e rsyncpuò essere eseguito a pieno ritmo, tutti gli altri processi verranno rallentati di conseguenza.
Mikko Rantalainen, il

-7

Non credo, hai bisogno di una soluzione personalizzata per quello .. usa ftp


6
Sai, è una buona idea. Chi ha bisogno di tutte le funzionalità di rsync come poter correre su ssh senza bisogno di un demone in esecuzione sul computer remoto (e la crittografia intrinseca di ssh), trasferire la compressione, riprendere i download, trasferire solo le differenze ... tutto qui gonfiare. Adesso corro a casa e userò il mio sistema 60 PS / 2 per FTP alcuni anime!
derisione del

Elimina questa risposta poiché non risponde alla domanda e offre un'alternativa significativamente peggiore rispetto all'esempio nella domanda.
user1133275
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.