Comment puis-je réduire l'utilisation des ressources lors de la copie d'un gros fichier?

J'ai besoin de déplacer un gros fichier (table MySQL corrompue ~ 40 Go) sur un serveur séparé afin de le réparer. (En essayant de réparer sur mon serveur de production, cela a rapidement tué le serveur).

Pour ce faire, je souhaite resynchroniser les fichiers .frm, .MYI et .MYD de mon serveur de production vers un serveur cloud.

Je copie les fichiers depuis / var / lib / mysql / {base de données} / vers / home / {monutilisateur} afin de ne pas avoir besoin d'activer l'accès root pour la commande rsync et d'être sûr à 100% que le fichier de base de données n'est pas en cours d'utilisation (il ne doit pas être écrit ou lu, mais évidemment je ne veux pas fermer ma base de données de production pour m'en assurer).

Le premier fichier que j'ai essayé de copier était d'environ 10 Go. Je transfère d'une partie de mon serveur de production à l'autre, c'est-à-dire vers la même matrice de disques.

Malheureusement, la commande de copie "cp filename newfilename" a pris tellement de ressources qu'elle a mis le serveur à l'arrêt.

Comment puis-je utiliser moins de ressources lors de la copie du fichier dans un répertoire différent? (Peu importe le temps que cela prend).

En supposant que j'arrive à le faire, à quelle utilisation des ressources puis-je m'attendre lors de la synchronisation du fichier dans le cloud?

Quelqu'un peut-il suggérer une meilleure façon de procéder? Je manque rapidement d'espace disque, je dois donc réparer et archiver cette table dès que possible.

Avez-vous essayé de nice -n10préfixer la commande?

10est la valeur par défaut. La plage va de -20(priorité la plus élevée) à 19(la plus faible).

Outre la limitation de la bande passante rsync, deux choix:

• ionice -c 3 cp foo bar
• buffer -u 150 -m 16m -s 100m -p 75 -i foo -o bar

ionices'interface avec le planificateur d'E / S. bufferest un tampon circulaire destiné à aider les appareils de caractères à être plus efficaces, mais la -u 150pause de 150 microsecondes entre les écritures, ce qui, selon le manuel, peut être suffisant pour donner un espace disque pour respirer.

Les deux ioniceet buffersont disponibles dans une version Ubuntu d'origine. iotopest pratique si vous avez configuré CONFIG_TASK_DELAY_ACCT dans votre noyau, mais ma boîte Ubuntu ne l'a pas fait, ce qui limite gravement l'utilisabilité de la commande. Je sais déjà qui commande se noie mon disque dur, je veux juste donner une bouffée d'oxygène.

De plus, pendant que la copie est en cours, examinez la sortie de iostat -x 1(généralement dans le package sysstat) et vérifiez que le champ% occupé pour votre appareil est de 90% ou moins pendant la copie. Si elle est à 99-100%, vous affamez d'autres processus d'E / S.

utilisez rsync avec le commutateur --bwlimit = KBPS (limite la bande passante d'E / S; Koctets par seconde). jouer avec un fichier plus petit et essayer de trouver un mélange optimal entre la vitesse de transfert et l'utilisation du système. Moniteur dans le deuxième shell avec "vmstat 1"

Une alternative est:

scp -l ${KBPS} ${src} ${dest}

Mais je ne pense pas que cela fonctionnera si $ {src} est un fichier en pleine croissance ... pouvez-vous suggérer un moyen de copier et d'attendre la fermeture de la source ...