j'ai besoin de recopier une base de donn=E9es de 100+ Go.
apr=E8s avoir effectuer qqs tests avec rsync, je ne suis pas convaincu
par cette solution technique.
temps observ=E9s pour 1 Go :
copie initiale sur un fs en local : 73s
idem sur un fs sur un san : 126s =E0 155s
recopie sans modif : 35s
maj avec 10% de modif : 64s
maj avec 20% de modif : 97s
maj avec 30% de modif : 118s
les temps de maj sont quasiment identique que l'on soit sur un fs en
local ou sur un san !
en fait, les temps en fonction du % de modif est lin=E9aire.
il n'y a pas de diff=E9rences des mesures du fait que les modifs soient
r=E9parties ou contigu=EB.
ce qui donne, par extrapolation, pour 100 Go :
0% 58min
10% 1h48
20% 2h46
30% 3h44
existe-il un rsync thread=E9 qui travaillerai sur des parties du m=EAme
fichier en // plut=F4t dans dans sa globalit=E9, ce qui permettrai tr=E8s=
certainement de booster tout le toutim ?
autre question, pourquoi un rsync de fs =E0 fs se comporte tel un simple
cp et n'utilise pas son algo de recherche par somme de contr=F4le ?
ce qui oblige de passer par localhost... =E0 ce propos, il y a tr=E8s peu=
de diff=E9rences entre le protocol rsync et ssh !
pour finir, unison ne semble pas mieux faire. rdiff-backup n'a pas=20
encore =E9t=E9 test=E9.
PS : version de rsync utilis=E9 : 2.6.3
Cordialement,
Cyrille Lefevre.
--=20
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
Cette extrapolation n'est pas valable : 1 Go, de nos jours, ça tient en RAM, donc tout se retrouve dans le cache, et c'est le CPU le facteur limitan t. Au contraire, 100 Go, ça ne tient pas en RAM, donc c'est le disque le fa cteur limitant (à moins que le disque ne soit très rapide par rapport au CPU).
même en changeant de fichier à chaque fois ?
autre question, pourquoi un rsync de fs à fs se comporte tel un simp le cp et n'utilise pas son algo de recherche par somme de contrôle ?
L'algorithme de rsync consiste en ceci :
- lecture complète du fichier source pour construire une signature fo rmée de sommes de contrôle par blocs ;
- transfert de la signature ;
- lecture complète du fichier destination pour rechercher, par sommes de contrôle glissante, les blocs déjà présents ;
- transfert des blocs manquants et construction du fichier destination.
On notera que, dans le meilleur des cas, quand le fichier cible est dé jà quasiment identique au fichier source, rsync exige toujours deux lectur es complètes non parallélisables. L'intérêt premier de rsync est d e minimiser les données échangées entre les deux extrémités.
j'avais bien compris, autrement dit, rsync est certainement bien adapté aux transferts en réseau mais pas en local...
Quand il s'agit d'une copie locale, le transfert ne coûte rien, une b ête copie demande une lecture complète et une écriture complètes, parallélisables : même dans le meilleur des cas, ça fait mieux qu e rsync.
Il y a quelques cas capilotractés où on peut vouloir préférer q ue rsync fasse ses deux lectures complètes. On peut imaginer par exemple que l a cible soit sur un support dont les écritures sont très lentes ou très c oûteuses par rapport aux lectures. Mais c'est marginal.
c'est pour cela que j'ai pu penser que 2 lectures plus qqs pourcents d'écritures seraient plus rapide qu'une lecture/écriture complète, autrement dit, mauvaise assertion :-(
L'autre intérêt d'utiliser rsync en local, c'est pour la possibilit é de considérer que le fichier cible est identique au fichier source dès que la taille et le mtime concordent. Dans les cas favorables (où personne n e va faire exprès de falsifier le mtime pour tromper l'ennemi), c'est trè s pratique.
(Une remarque au passage : les filesystems FAT stockent le mtime à de ux secondes près, ce qui fait échouer cette heuristique une fois sur d eux ; chercher FAT dans le man de rsync pour la contre-mesure.)
ce cas ne me concerne pas dans l'immédiat, mais j'avais déjà remarq uer l'option : --modify-window=NUM compare mod-times with reduced accuracy
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Le 06/06/2010 10:21, Nicolas George a écrit :
Cyrille Lefevre wrote in message<hubuvl$1nl3$1@talisker.lacave.net>:
ce qui donne, par extrapolation, pour 100 Go :
0% 58min
10% 1h48
20% 2h46
30% 3h44
Cette extrapolation n'est pas valable : 1 Go, de nos jours, ça tient en RAM,
donc tout se retrouve dans le cache, et c'est le CPU le facteur limitan t. Au
contraire, 100 Go, ça ne tient pas en RAM, donc c'est le disque le fa cteur
limitant (à moins que le disque ne soit très rapide par rapport au CPU).
même en changeant de fichier à chaque fois ?
autre question, pourquoi un rsync de fs à fs se comporte tel un simp le
cp et n'utilise pas son algo de recherche par somme de contrôle ?
L'algorithme de rsync consiste en ceci :
- lecture complète du fichier source pour construire une signature fo rmée de
sommes de contrôle par blocs ;
- transfert de la signature ;
- lecture complète du fichier destination pour rechercher, par sommes de
contrôle glissante, les blocs déjà présents ;
- transfert des blocs manquants et construction du fichier destination.
On notera que, dans le meilleur des cas, quand le fichier cible est dé jà
quasiment identique au fichier source, rsync exige toujours deux lectur es
complètes non parallélisables. L'intérêt premier de rsync est d e minimiser
les données échangées entre les deux extrémités.
j'avais bien compris, autrement dit, rsync est certainement bien adapté
aux transferts en réseau mais pas en local...
Quand il s'agit d'une copie locale, le transfert ne coûte rien, une b ête
copie demande une lecture complète et une écriture complètes,
parallélisables : même dans le meilleur des cas, ça fait mieux qu e rsync.
Il y a quelques cas capilotractés où on peut vouloir préférer q ue rsync
fasse ses deux lectures complètes. On peut imaginer par exemple que l a cible
soit sur un support dont les écritures sont très lentes ou très c oûteuses
par rapport aux lectures. Mais c'est marginal.
c'est pour cela que j'ai pu penser que 2 lectures plus qqs pourcents
d'écritures seraient plus rapide qu'une lecture/écriture complète,
autrement dit, mauvaise assertion :-(
L'autre intérêt d'utiliser rsync en local, c'est pour la possibilit é de
considérer que le fichier cible est identique au fichier source dès que la
taille et le mtime concordent. Dans les cas favorables (où personne n e va
faire exprès de falsifier le mtime pour tromper l'ennemi), c'est trè s
pratique.
(Une remarque au passage : les filesystems FAT stockent le mtime à de ux
secondes près, ce qui fait échouer cette heuristique une fois sur d eux ;
chercher FAT dans le man de rsync pour la contre-mesure.)
ce cas ne me concerne pas dans l'immédiat, mais j'avais déjà remarq uer
l'option : --modify-window=NUM compare mod-times with reduced accuracy
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
Cette extrapolation n'est pas valable : 1 Go, de nos jours, ça tient en RAM, donc tout se retrouve dans le cache, et c'est le CPU le facteur limitan t. Au contraire, 100 Go, ça ne tient pas en RAM, donc c'est le disque le fa cteur limitant (à moins que le disque ne soit très rapide par rapport au CPU).
même en changeant de fichier à chaque fois ?
autre question, pourquoi un rsync de fs à fs se comporte tel un simp le cp et n'utilise pas son algo de recherche par somme de contrôle ?
L'algorithme de rsync consiste en ceci :
- lecture complète du fichier source pour construire une signature fo rmée de sommes de contrôle par blocs ;
- transfert de la signature ;
- lecture complète du fichier destination pour rechercher, par sommes de contrôle glissante, les blocs déjà présents ;
- transfert des blocs manquants et construction du fichier destination.
On notera que, dans le meilleur des cas, quand le fichier cible est dé jà quasiment identique au fichier source, rsync exige toujours deux lectur es complètes non parallélisables. L'intérêt premier de rsync est d e minimiser les données échangées entre les deux extrémités.
j'avais bien compris, autrement dit, rsync est certainement bien adapté aux transferts en réseau mais pas en local...
Quand il s'agit d'une copie locale, le transfert ne coûte rien, une b ête copie demande une lecture complète et une écriture complètes, parallélisables : même dans le meilleur des cas, ça fait mieux qu e rsync.
Il y a quelques cas capilotractés où on peut vouloir préférer q ue rsync fasse ses deux lectures complètes. On peut imaginer par exemple que l a cible soit sur un support dont les écritures sont très lentes ou très c oûteuses par rapport aux lectures. Mais c'est marginal.
c'est pour cela que j'ai pu penser que 2 lectures plus qqs pourcents d'écritures seraient plus rapide qu'une lecture/écriture complète, autrement dit, mauvaise assertion :-(
L'autre intérêt d'utiliser rsync en local, c'est pour la possibilit é de considérer que le fichier cible est identique au fichier source dès que la taille et le mtime concordent. Dans les cas favorables (où personne n e va faire exprès de falsifier le mtime pour tromper l'ennemi), c'est trè s pratique.
(Une remarque au passage : les filesystems FAT stockent le mtime à de ux secondes près, ce qui fait échouer cette heuristique une fois sur d eux ; chercher FAT dans le man de rsync pour la contre-mesure.)
ce cas ne me concerne pas dans l'immédiat, mais j'avais déjà remarq uer l'option : --modify-window=NUM compare mod-times with reduced accuracy
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Cyrille Lefevre
Le 05/06/2010 02:49, Cyrille Lefevre a écrit :
Le 05/06/2010 02:00, LENHOF Jean-Yves a écrit :
Le 05/06/2010 00:33, Cyrille Lefevre a écrit :
j'ai besoin de recopier une base de données de 100+ Go.
Tu peux préciser de où à où parce que c'est pas si clair ?
copie locale avec tentative d'optimisation via rsync sans succès. l'idée était que s'il y a moins d'écriture, ça va plus vite, ma is dans la vrai vie, ça ne se passe pas comme ça du fait de la lecture des 2 fichiers + calcul du checksum. bref, je suis déçu sur ce coup là. d'où l'idée de trouver un rsync threadé qui travaille sur des bou ts d'un même fichier en //. mais rien à l'horizon.
Bonsoir,
tests du jour, un cp like via dd en //, résultats similaires à cp/cpio/pax/etc.
le fait de paralléliser les transferts n'améliorent pas le temps tota l de la copie, il semble donc que je sois déjà au débit nominal des disques, les multiples cpu n'aident en rien, point-barre. dommage :-(
l'idée était qqc comme (toujours pour 1 Go) :
for i in 0 1 2 3 4 5 6 7 8 9; do dd if=path/to/source of=/path/to/target skip=$i seek=$i count=1 bs8M conv=notrunc done
sur le san, je plafonne toujours entre 25 et 40s que ce soit avec cp ou les dd, soit 25-40Mo/s, sur disque interne, je passe à 13-25s, soit 40-80Mo/s. (pas fait gaffe si je suis sur le même disque, mais il me semble que non).
pour autant, un rsync parallélisé vaudrait peut-être le coup du fai t des checksums en // à défaut d'effectuer les copies en // ? :-)
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Le 05/06/2010 02:49, Cyrille Lefevre a écrit :
Le 05/06/2010 02:00, LENHOF Jean-Yves a écrit :
Le 05/06/2010 00:33, Cyrille Lefevre a écrit :
j'ai besoin de recopier une base de données de 100+ Go.
Tu peux préciser de où à où parce que c'est pas si clair ?
copie locale avec tentative d'optimisation via rsync sans succès.
l'idée était que s'il y a moins d'écriture, ça va plus vite, ma is dans
la vrai vie, ça ne se passe pas comme ça du fait de la lecture des 2
fichiers + calcul du checksum. bref, je suis déçu sur ce coup là.
d'où l'idée de trouver un rsync threadé qui travaille sur des bou ts d'un
même fichier en //. mais rien à l'horizon.
Bonsoir,
tests du jour, un cp like via dd en //, résultats similaires à
cp/cpio/pax/etc.
le fait de paralléliser les transferts n'améliorent pas le temps tota l
de la copie, il semble donc que je sois déjà au débit nominal des
disques, les multiples cpu n'aident en rien, point-barre. dommage :-(
l'idée était qqc comme (toujours pour 1 Go) :
for i in 0 1 2 3 4 5 6 7 8 9; do
dd if=path/to/source of=/path/to/target
skip=$i seek=$i count=1 bs=128M conv=notrunc
done
sur le san, je plafonne toujours entre 25 et 40s que ce soit avec cp
ou les dd, soit 25-40Mo/s, sur disque interne, je passe à 13-25s, soit
40-80Mo/s. (pas fait gaffe si je suis sur le même disque, mais il me
semble que non).
pour autant, un rsync parallélisé vaudrait peut-être le coup du fai t des
checksums en // à défaut d'effectuer les copies en // ? :-)
Cordialement,
Cyrille Lefevre.
--
mailto:Cyrille.Lefevre-news%nospam@laposte.net.invalid
supprimer "%nospam% et ".invalid" pour me repondre.
j'ai besoin de recopier une base de données de 100+ Go.
Tu peux préciser de où à où parce que c'est pas si clair ?
copie locale avec tentative d'optimisation via rsync sans succès. l'idée était que s'il y a moins d'écriture, ça va plus vite, ma is dans la vrai vie, ça ne se passe pas comme ça du fait de la lecture des 2 fichiers + calcul du checksum. bref, je suis déçu sur ce coup là. d'où l'idée de trouver un rsync threadé qui travaille sur des bou ts d'un même fichier en //. mais rien à l'horizon.
Bonsoir,
tests du jour, un cp like via dd en //, résultats similaires à cp/cpio/pax/etc.
le fait de paralléliser les transferts n'améliorent pas le temps tota l de la copie, il semble donc que je sois déjà au débit nominal des disques, les multiples cpu n'aident en rien, point-barre. dommage :-(
l'idée était qqc comme (toujours pour 1 Go) :
for i in 0 1 2 3 4 5 6 7 8 9; do dd if=path/to/source of=/path/to/target skip=$i seek=$i count=1 bs8M conv=notrunc done
sur le san, je plafonne toujours entre 25 et 40s que ce soit avec cp ou les dd, soit 25-40Mo/s, sur disque interne, je passe à 13-25s, soit 40-80Mo/s. (pas fait gaffe si je suis sur le même disque, mais il me semble que non).
pour autant, un rsync parallélisé vaudrait peut-être le coup du fai t des checksums en // à défaut d'effectuer les copies en // ? :-)
Cordialement,
Cyrille Lefevre. -- mailto:Cyrille.Lefevre-news% supprimer "%nospam% et ".invalid" pour me repondre.
Emmanuel Florac
Le Tue, 08 Jun 2010 00:35:27 +0200, Cyrille Lefevre a écrit:
sur le san, je plafonne toujours entre 25 et 40s que ce soit avec cp ou les dd, soit 25-40Mo/s, sur disque interne, je passe à 13-25s, soit 40-80Mo/s. (pas fait gaffe si je suis sur le même disque, mais il me semble que non).
C'est quand même très faible, c'est curieux. as-tu essayé d'ajuster le read-ahead de tes disques avec blockdev --setra (valeur type : 1024 * nombre de disques de données)?
-- I have noticed even people who claim everything is predestined, and that we can do nothing to change it, look before they cross the road. Stephen Hawking.
Le Tue, 08 Jun 2010 00:35:27 +0200, Cyrille Lefevre a écrit:
sur le san, je plafonne toujours entre 25 et 40s que ce soit avec cp ou
les dd, soit 25-40Mo/s, sur disque interne, je passe à 13-25s, soit
40-80Mo/s. (pas fait gaffe si je suis sur le même disque, mais il me
semble que non).
C'est quand même très faible, c'est curieux. as-tu essayé d'ajuster le
read-ahead de tes disques avec blockdev --setra (valeur type : 1024 *
nombre de disques de données)?
--
I have noticed even people who claim everything is predestined, and
that we can do nothing to change it, look before they cross the road.
Stephen Hawking.
Le Tue, 08 Jun 2010 00:35:27 +0200, Cyrille Lefevre a écrit:
sur le san, je plafonne toujours entre 25 et 40s que ce soit avec cp ou les dd, soit 25-40Mo/s, sur disque interne, je passe à 13-25s, soit 40-80Mo/s. (pas fait gaffe si je suis sur le même disque, mais il me semble que non).
C'est quand même très faible, c'est curieux. as-tu essayé d'ajuster le read-ahead de tes disques avec blockdev --setra (valeur type : 1024 * nombre de disques de données)?
-- I have noticed even people who claim everything is predestined, and that we can do nothing to change it, look before they cross the road. Stephen Hawking.
