Come limitare gli I / O del disco durante il backup?

14

Ho un cron che fondamentalmente fa un semplice "tar zcf" nella notte.

Il server ha:

8 core: CPU Intel (R) Xeon (R) E5606 a 2,13 GHz
25 GB di RAM
Ubuntu 12.04.2 LTS
Hardware RAID 1 (LSI Logic / Symbios Logic MegaRAID SAS SMC2108) con due hard disk da 2,728 TB

Come puoi vedere sullo screenhost di monitoraggio:

Durante quasi tutto il tempo del tar, l'I / O del disco arriva a> 90% e fa rallentare molto tutte le altre app (mysql, apache).

2 domande:

È normale avere un I / O del disco così alto durante il backup?
Esiste un modo per limitare l'I / O del disco in modo che altre app possano continuare a funzionare correttamente?

Grazie!

— acemtp
fonte

11

Oltre all'approccio piuttosto generale con ionicec'è un bel target di mappatore di dispositivi (ioband) che consente un controllo preciso sulla larghezza di banda a un dispositivo a blocchi (DM). Sfortunatamente non fa parte del kernel standard.

Inoltre puoi probabilmente accelerare il catrame di

Lettura dei nomi dei file nella cache del disco: find /source/path -printf ""
Lettura degli inode nella cache del disco: find /source/path -perm 777 -printf ""
Fare tar leggere e scrivere blocchi più grandi da e sul disco usando ad esempio una pipe con mbuffer o buffer (con almeno 100 MiB di RAM): tar ... | mbuffer -m 256M -P 100 -p 1 ...

— Hauke Laging
fonte

Perché la lettura dei nomi / inode dei file nella cache riduce l'IO del disco durante il taring? Mi aspetterei che aumenti l'IO medio riducendo il tempo totale solo leggermente.

— scai,

3

@scai Questo non aiuta con gli SSD; la mia raccomandazione si riferisce solo alla rotazione dei dischi rigidi. Ciò che uccide le prestazioni con questi è il movimento della testa. I nomi dei file sono memorizzati in blocchi continui, gli inode sono memorizzati in blocchi continui e il contenuto del file è memorizzato in blocchi continui. Se lo fai in modo tar, leggi i nomi di file (e sottodirectory) di una directory, accedi all'inode per un file, quindi al file stesso, quindi all'inode per il file successivo, quindi al file successivo stesso ... provoca più movimento della testa rispetto alla lettura reciproca di tutti i nomi e gli inode.

— Hauke Laging,

@scai L'impatto sulle prestazioni dipende da ciò che fai. È piuttosto piccolo per i backup completi (probabilmente dipende dalle dimensioni del file) ma ho notato una grande differenza per i backup differenziali (non per tar, tuttavia, poiché non lo uso ma questo dovrebbe essere un effetto generale).

— Hauke Laging,

Solo per essere sicuro di aver capito bene. Per 1. e 2., dobbiamo solo chiamare il comando find e Linux lo memorizzerà automaticamente nella cache?

— acemtp,

@acemtp È corretto. findsenza (ad es.) -permnon accederà all'inode del file, comunque. Ma ciò consente all'ottimizzazione di utilizzare due findchiamate. Se si effettua la stessa findchiamata due volte (con poco tempo in mezzo), la seconda termina di solito entro pochi secondi (o meno). A seconda della quantità di memoria libera e della quantità di dati memorizzati nella cache in un determinato punto, i dati vengono eliminati dalla cache. Leggere troppo può quindi rallentare l'operazione. Se è possibile alimentare il programma di backup con nomi di file tramite stdin, è possibile impedirlo leggendo ad esempio blocchi di 100 file.

— Hauke Laging,

13

Si prevede che gli I / O siano elevati durante i backup perché sono generalmente realizzati su alberi di file di grandi dimensioni con file di grandi dimensioni. È possibile utilizzare ioniceper assegnare la priorità ai lavori I / O in Linux con classi e livelli. IIRC, classe 2, livello 7 è il livello più basso e non affamato che lo renderà praticamente invisibile ad altri carichi I / O e utenti. Vedi man ioniceper uso e dettagli.

— bayindirh
fonte

1

Consiglierei di abbandonare il catrame e andare con rsync (come menzionato da Dogsbody). Uso BackupPC per eseguire il backup dei file sui miei sistemi Windows e Linux e supporta l'utilizzo di tar e rsync e si occupa automaticamente del collegamento reale per te, oltre a fornire una bella interfaccia web.

http://backuppc.sourceforge.net/

— Atari911
fonte

0

Come altri hanno risposto, sì, questo è normale ed ioniceè un buon modo generico per non lasciare che influisca sul sistema.

Diverse volte ho visto tarcose di persone quando non ne avevano bisogno. Se una qualsiasi percentuale dei dati che stai copiando non è cambiata dall'ultima copia, ti suggerisco di rsyncprovare.

Ciò ridurrà l'I / O copiando solo i file che sono stati modificati dall'ultima copia. non sarai in grado di ridurre di oltre la metà l'IO poiché tutti i dati dovrebbero ancora essere letti, ma ridurrai significativamente la quantità di dati scritti (che a seconda dell'hardware può anche essere un'operazione più lenta).

Se si desidera eseguire copie / backup separati ogni volta che viene eseguito, l'opzione più potente è –link-dest che consente di collegare in modo rigido i file invariati a un backup precedente. Ciò consente di risparmiare enormi quantità di spazio sul server di backup. ad es. eseguo il backup di una macchina (Fred), Fred ha un HD da 20 GB e eseguo il backup / copia dell'intero disco escludendo / proc e / dev. Ora ho una directory da 20 GB sul mio server di backup. Il giorno dopo eseguo nuovamente il backup di Fred e –link-dest al backup di ieri. Rsync confronta i file remoti con la copia locale e, se esattamente lo stesso, non si preoccuperà di trasferirli ma collegherà il nuovo file al file di ieri. Tutti i file che sono stati modificati vengono copiati di nuovo (o parzialmente copiati utilizzando il backup di ieri, se possibile). Se solo 100 MB di file sono cambiati da ieri, ora ho due directory entrambe con 20 GB di file, ma ne occupano solo 20.

Spero che ciò aiuti e risponda ancora alla tua domanda.

— dogsbody
fonte