Comment limiter les E / S du disque pendant la sauvegarde?

14

J'ai un cron qui fait essentiellement un simple "tar zcf" dans la nuit.

Le serveur a:

8 cœurs - Processeur Intel (R) Xeon (R) E5606 à 2,13 GHz
25 Go de RAM
Ubuntu 12.04.2 LTS
RAID 1 matériel (LSI Logic / Symbios Logic MegaRAID SAS SMC2108) avec deux disques durs de 2,728 To

Comme vous pouvez le voir sur l'hôte d'écran de surveillance:

Pendant presque tout le temps du tar, les E / S du disque vont à> 90% et ralentissent beaucoup toutes les autres applications (mysql, apache).

2 questions:

Est-il normal d'avoir des E / S de disque aussi élevées pendant la sauvegarde?
Existe-t-il un moyen de limiter les E / S du disque pour que les autres applications puissent continuer à fonctionner correctement?

Je vous remercie!

— acemtp
source

11

À côté de l'approche plutôt générale, ioniceil y a une belle cible de mappage de périphérique (ioband) qui permet un contrôle précis de la bande passante d'un périphérique de bloc (DM). Malheureusement, il ne fait pas partie du noyau standard.

De plus, vous pouvez probablement accélérer le goudron en

Lecture des noms de fichiers dans le cache disque: find /source/path -printf ""
Lecture des inodes dans le cache disque: find /source/path -perm 777 -printf ""
Faire tar lire et écrire des blocs plus grands depuis et vers le disque en utilisant par exemple un tube avec mbuffer ou tampon (avec au moins 100 Mo de RAM): tar ... | mbuffer -m 256M -P 100 -p 1 ...

— Hauke Laging
source

Pourquoi la lecture des noms de fichiers / inodes dans le cache réduit-elle les E / S disque pendant le tarage? Je m'attendrais à ce qu'il augmente le IO moyen tout en ne réduisant que légèrement le temps total.

— scai

3

@scai Cela n'aide pas avec les SSD; ma recommandation ne concerne que la rotation des disques durs. Ce qui tue la performance avec ceux-ci, c'est le mouvement de la tête. Les noms de fichiers sont stockés dans des blocs continus, les inodes sont stockés dans des blocs continus et le contenu du fichier est stocké dans des blocs continus. Si vous le faites de la manière tar, vous lisez les noms de fichier (et de sous-répertoire) d'un répertoire, accédez à l'inode d'un fichier, puis au fichier lui-même, puis à l'inode du fichier suivant, puis au fichier suivant lui-même ... provoque plus de mouvements de tête que la lecture de tous les noms et inodes l'un après l'autre.

— Hauke Laging

@scai L'impact sur les performances dépend de ce que vous faites. Il est plutôt petit pour les sauvegardes complètes (dépend probablement de la taille des fichiers) mais j'ai remarqué une grande différence pour les sauvegardes différentielles (pas pour tar, cependant, car je ne l'utilise pas mais cela devrait être un effet général).

— Hauke Laging

Juste pour être sûr d'avoir bien compris. Pour 1. et 2., il suffit d'appeler la commande find et Linux la mettra automatiquement en cache?

— acemtp

@acemtp C'est exact. findsans (par exemple) -permn'accèdera pas au fichier inode, cependant. Mais cela permet à l'optimisation d'utiliser deux findappels. Si vous effectuez le même findappel deux fois (avec peu de temps entre les deux), le second va généralement se terminer en quelques secondes (ou moins). Selon la quantité de mémoire libre et la quantité de données mises en cache à un certain point, les données sont rejetées hors du cache. Trop lire peut donc ralentir l'opération. Si vous pouvez alimenter le programme de sauvegarde avec des noms de fichiers via stdin, vous pouvez empêcher cela en lisant par exemple des blocs de 100 fichiers.

— Hauke Laging

13

Il est prévu que les E / S soient élevées pendant les sauvegardes, car elles sont généralement réalisées sur de grandes arborescences de fichiers avec de gros fichiers. Vous pouvez utiliser ionicepour hiérarchiser les travaux d'E / S sous Linux avec des classes et des niveaux. IIRC, classe 2, niveau 7 est le niveau le plus bas et non affamé qui le rendra pratiquement invisible pour les autres charges d'E / S et les utilisateurs. Voir man ionicepour l'utilisation et les détails.

— bayindirh
source

1

Je recommanderais d'abandonner le goudron et d'aller avec rsync (comme mentionné par Dogsbody). J'utilise BackupPC pour sauvegarder des fichiers sur mes systèmes Windows et Linux et il prend en charge l'utilisation de tar ainsi que rsync et prend automatiquement en charge la liaison matérielle pour vous ainsi que fournit une interface Web agréable.

http://backuppc.sourceforge.net/

— Atari911
source

0

Comme d'autres l'ont répondu, oui, c'est normal et ionicec'est un bon moyen générique de ne pas le laisser affecter votre système.

Un certain nombre de fois, j'ai vu des gens faire des tarchoses alors qu'ils n'en avaient pas besoin. Si un pourcentage des données que vous copiez n'a pas changé depuis la dernière copie, je vous suggère d' rsyncessayer.

Cela réduira les E / S en copiant uniquement les fichiers qui ont été modifiés depuis la dernière copie. vous ne pourrez pas réduire l'E / S de plus de la moitié car toutes les données devront encore être lues, mais vous réduirez considérablement la quantité de données écrites (ce qui, en fonction de votre matériel, peut également être plus lent).

Si vous souhaitez des copies / sauvegardes distinctes à chaque exécution, l'option la plus puissante est –link-dest qui vous permet de lier en dur des fichiers inchangés à une sauvegarde précédente. Cela économise d'énormes quantités d'espace sur le serveur de sauvegarde. Par exemple, je sauvegarde une machine (Fred), Fred a un disque dur de 20 Go et je sauvegarde / copie l'intégralité du disque à l'exception de / proc et / dev. J'ai maintenant un répertoire de 20 Go sur mon serveur de sauvegarde. Le lendemain, je sauvegarde à nouveau Fred et –link-dest vers la sauvegarde d'hier. Rsync compare les fichiers distants avec la copie locale et si exactement la même chose ne dérangera pas de les transférer mais liera durement le nouveau fichier au fichier d'hier. Tous les fichiers qui ont été modifiés sont copiés vers le bas (ou partiellement copiés en utilisant la sauvegarde d'hier si possible). Si seulement 100 Mo de fichiers ont changé depuis hier, j'ai maintenant deux répertoires avec 20 Go de fichiers mais seulement 20.

J'espère que cela aide et répond toujours à votre question.

— Bon à tout faire
source