Bonjour,
j'ai besoin de recopier une base de données de 100+ Go.
Bonjour,
j'ai besoin de recopier une base de données de 100+ Go.
Bonjour,
j'ai besoin de recopier une base de données de 100+ Go.
Bonjour,
j'ai besoin de recopier une base de données de 100+ Go.
Bonjour,
j'ai besoin de recopier une base de données de 100+ Go.
Bonjour,
j'ai besoin de recopier une base de données de 100+ Go.
existe-il un rsync threadé qui travaillerai sur des parties du même
fichier en // plutôt dans dans sa globalité, ce qui permettrai trè s
certainement de booster tout le toutim ?
autre question, pourquoi un rsync de fs à fs se comporte tel un simpl e
cp et n'utilise pas son algo de recherche par somme de contrôle ?
PS : version de rsync utilisé : 2.6.3
existe-il un rsync threadé qui travaillerai sur des parties du même
fichier en // plutôt dans dans sa globalité, ce qui permettrai trè s
certainement de booster tout le toutim ?
autre question, pourquoi un rsync de fs à fs se comporte tel un simpl e
cp et n'utilise pas son algo de recherche par somme de contrôle ?
PS : version de rsync utilisé : 2.6.3
existe-il un rsync threadé qui travaillerai sur des parties du même
fichier en // plutôt dans dans sa globalité, ce qui permettrai trè s
certainement de booster tout le toutim ?
autre question, pourquoi un rsync de fs à fs se comporte tel un simpl e
cp et n'utilise pas son algo de recherche par somme de contrôle ?
PS : version de rsync utilisé : 2.6.3
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 ?
Pour certains rsync d'un serveur à un autre, on est repassé de ssh à rsh
au taff (je sais chiant parce que pas secure, mais bon) parce que ssh
limite le débit fortement (Il y a des patchs pour openssh, voir des
forks, mais il y a vraiment qq chose à faire sur le long terme)...
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 ?
Pour certains rsync d'un serveur à un autre, on est repassé de ssh à rsh
au taff (je sais chiant parce que pas secure, mais bon) parce que ssh
limite le débit fortement (Il y a des patchs pour openssh, voir des
forks, mais il y a vraiment qq chose à faire sur le long terme)...
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 ?
Pour certains rsync d'un serveur à un autre, on est repassé de ssh à rsh
au taff (je sais chiant parce que pas secure, mais bon) parce que ssh
limite le débit fortement (Il y a des patchs pour openssh, voir des
forks, mais il y a vraiment qq chose à faire sur le long terme)...
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.
Salut Jean-Yves,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, mais 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 bouts d'un
même fichier en //. mais rien à l'horizon.
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.
Salut Jean-Yves,
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, mais 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 bouts d'un
même fichier en //. mais rien à l'horizon.
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.
Salut Jean-Yves,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, mais 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 bouts d'un
même fichier en //. mais rien à l'horizon.
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, m ais 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 bo uts d'un
même fichier en //. mais rien à l'horizon.
Tu peux redéfinir ton besoin initial ?
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, m ais 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 bo uts d'un
même fichier en //. mais rien à l'horizon.
Tu peux redéfinir ton besoin initial ?
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, m ais 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 bo uts d'un
même fichier en //. mais rien à l'horizon.
Tu peux redéfinir ton besoin initial ?
environnement RHEL 4 ou 5
pas le droit aux miroirs linux, même en LVM
baies SAN EMC avec snap ou clone, pas de bcv ni de srdf car baie locale
le snap consomme 15 à 20% de perf
pour info, un miroir sous AIX consomme également 15 à 20% de perf
l'idée est d'impacter au minimum les perf de la base de prod
pb : recopier cette base de prod sur un autre serveur tout en impactant au
minimum les perfs et dans un temps record (moins de 2h pour 120 Go)
un test a été effectué via un cp depuis un snap sur une base de 80Go
résultat : 2h pour 80 Go ! on est dedans pour 120 Go...
environnement RHEL 4 ou 5
pas le droit aux miroirs linux, même en LVM
baies SAN EMC avec snap ou clone, pas de bcv ni de srdf car baie locale
le snap consomme 15 à 20% de perf
pour info, un miroir sous AIX consomme également 15 à 20% de perf
l'idée est d'impacter au minimum les perf de la base de prod
pb : recopier cette base de prod sur un autre serveur tout en impactant au
minimum les perfs et dans un temps record (moins de 2h pour 120 Go)
un test a été effectué via un cp depuis un snap sur une base de 80Go
résultat : 2h pour 80 Go ! on est dedans pour 120 Go...
environnement RHEL 4 ou 5
pas le droit aux miroirs linux, même en LVM
baies SAN EMC avec snap ou clone, pas de bcv ni de srdf car baie locale
le snap consomme 15 à 20% de perf
pour info, un miroir sous AIX consomme également 15 à 20% de perf
l'idée est d'impacter au minimum les perf de la base de prod
pb : recopier cette base de prod sur un autre serveur tout en impactant au
minimum les perfs et dans un temps record (moins de 2h pour 120 Go)
un test a été effectué via un cp depuis un snap sur une base de 80Go
résultat : 2h pour 80 Go ! on est dedans pour 120 Go...
ce qui donne, par extrapolation, pour 100 Go :
0% 58min
10% 1h48
20% 2h46
30% 3h44
autre question, pourquoi un rsync de fs à fs se comporte tel un simple
cp et n'utilise pas son algo de recherche par somme de contrôle ?
ce qui donne, par extrapolation, pour 100 Go :
0% 58min
10% 1h48
20% 2h46
30% 3h44
autre question, pourquoi un rsync de fs à fs se comporte tel un simple
cp et n'utilise pas son algo de recherche par somme de contrôle ?
ce qui donne, par extrapolation, pour 100 Go :
0% 58min
10% 1h48
20% 2h46
30% 3h44
autre question, pourquoi un rsync de fs à fs se comporte tel un simple
cp et n'utilise pas son algo de recherche par somme de contrôle ?
Le 05/06/2010 13:23, LENHOF Jean-Yves a écrit :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, mais 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 bouts d'un
même fichier en //. mais rien à l'horizon.
Tu peux redéfinir ton besoin initial ?
environnement RHEL 4 ou 5
pas le droit aux miroirs linux, même en LVM
baies SAN EMC avec snap ou clone, pas de bcv ni de srdf car baie locale
le snap consomme 15 à 20% de perf
autre alternative envisagé, découpage au max de la base (un table space
par fs) pour multiplier les axes, pour autant, ej ne sais pas si cela
est faisable côté projet.
d'où l'idée de départ de passer par un rsync amélioré...
Le 05/06/2010 13:23, LENHOF Jean-Yves a écrit :
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, mais 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 bouts d'un
même fichier en //. mais rien à l'horizon.
Tu peux redéfinir ton besoin initial ?
environnement RHEL 4 ou 5
pas le droit aux miroirs linux, même en LVM
baies SAN EMC avec snap ou clone, pas de bcv ni de srdf car baie locale
le snap consomme 15 à 20% de perf
autre alternative envisagé, découpage au max de la base (un table space
par fs) pour multiplier les axes, pour autant, ej ne sais pas si cela
est faisable côté projet.
d'où l'idée de départ de passer par un rsync amélioré...
Le 05/06/2010 13:23, LENHOF Jean-Yves a écrit :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, mais 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 bouts d'un
même fichier en //. mais rien à l'horizon.
Tu peux redéfinir ton besoin initial ?
environnement RHEL 4 ou 5
pas le droit aux miroirs linux, même en LVM
baies SAN EMC avec snap ou clone, pas de bcv ni de srdf car baie locale
le snap consomme 15 à 20% de perf
autre alternative envisagé, découpage au max de la base (un table space
par fs) pour multiplier les axes, pour autant, ej ne sais pas si cela
est faisable côté projet.
d'où l'idée de départ de passer par un rsync amélioré...
Qq autres idées :
- Dans cette veine, as-tu envisagé la piste cpio "en parallèle"...
suivant les cas cela pourrait être plus rapide si tu as plusieurs axe s
et plusieurs processeurs.
Infos ici :
http://rightsock.com/~kjw/Ramblings/tar_v_cpio.html
- Le dd est une autre piste pour recopier aussi...
- Sinon le snapshot LVM est-il une piste envisageable ou pas ?
Qq autres idées :
- Dans cette veine, as-tu envisagé la piste cpio "en parallèle"...
suivant les cas cela pourrait être plus rapide si tu as plusieurs axe s
et plusieurs processeurs.
Infos ici :
http://rightsock.com/~kjw/Ramblings/tar_v_cpio.html
- Le dd est une autre piste pour recopier aussi...
- Sinon le snapshot LVM est-il une piste envisageable ou pas ?
Qq autres idées :
- Dans cette veine, as-tu envisagé la piste cpio "en parallèle"...
suivant les cas cela pourrait être plus rapide si tu as plusieurs axe s
et plusieurs processeurs.
Infos ici :
http://rightsock.com/~kjw/Ramblings/tar_v_cpio.html
- Le dd est une autre piste pour recopier aussi...
- Sinon le snapshot LVM est-il une piste envisageable ou pas ?