19 votes

mikeymo avatar

Meilleure compression pour les envois/récupérations ZFS

Demandé el 14 de Octobre, 2009
Quand la question a-t-elle été
21388 affichage
Nombre de visites la question a
4 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

J'envoie des instantanés ZFS incrémentiels sur une ligne T1 point à point et nous en sommes à un point où l'équivalent d'une journée d'instantanés peut à peine passer le fil avant que la sauvegarde suivante ne commence. Notre commande d'envoi/récupération est la suivante :

zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | bzip2 -c | \
ssh offsite-backup "bzcat | zfs recv -F tank/vm"

J'ai beaucoup de cycles de CPU à épargner. Existe-t-il un meilleur algorithme de compression ou une méthode alternative que je peux utiliser pour faire passer moins de données sur la ligne ?

Demandé el 14 de Octobre, 2009 par mikeymo

1 votes

Avatar de Matt Hanson

H

Commenté el 14 de Octobre, 2009 par Matt Hanson

0 votes

Avatar de mikeymo

Y

Commenté el 14 de Octobre, 2009 par mikeymo

3 votes

Avatar de vartec

H

Commenté el 17 de Octobre, 2009 par vartec
Afficher 1 autres commentaires

Réponses

Trop de publicités?

0voto

Dan Buhler avatar
Dan Buhler Points 446

Vous devrez tester avec vos données. Il suffit de les envoyer dans un fichier et de les compresser avec chaque méthode.

Pour nous, gzip a fait une énorme différence et nous faisons tout passer par là, mais il n'y avait même pas 1% de différence entre gzip et bzip ou 7z.

Si vous êtes sur une ligne T1 lente, vous devrez le stocker dans un fichier et le transférer par rsync.

Pour ceux (pas vous) qui sont un peu plus limités par le CPU que par la bande passante, comme lstvan l'a dit, un chiffrement différent comme arcfour128 accélère les choses. Nous l'utilisons en interne lorsque nous déplaçons des objets.

Répondu el 20 de Juin, 2012 par Dan Buhler (446 Points )

0voto

venkatachalam avatar
venkatachalam Points 18235

Expérimenter l'activation de la déduplication pour zfs send avec -D. Les économies dépendent de la quantité de duplication dans vos données, bien sûr.

Répondu el 22 de Août, 2012 par venkatachalam (18235 Points )

0 votes

Avatar de cyphun

Puisqu'il utilise -i qui implique une sauvegarde "incrémentale", il n'y a pas beaucoup d'espoir que la -D donnerait n'importe quoi.

Commenté el 25 de Janvier, 2017 par cyphun

0 votes

Avatar de venkatachalam

@poige dépend de la nature de leurs données. S'ils génèrent beaucoup de données avec des blocs dupliqués, c'est une grande victoire. Je ne vois pas en quoi -i rendrait plus ou moins probable la présence de blocs dupliqués. Si vous créez normalement des données qui ont beaucoup de duplication, vous allez probablement créer beaucoup de duplication à l'intérieur tous les jours, donc -i n'aide pas ou ne nuit pas.

Commenté el 25 de Janvier, 2017 par venkatachalam

0 votes

Avatar de cyphun

Si vous avez beaucoup de doublons, une compression suffira de toute façon à les éliminer.

Commenté el 25 de Janvier, 2017 par cyphun
Afficher 2 autres commentaires

0voto

MattK avatar
MattK Points 7319

Après avoir fait zfs send tank@datasnapshot > /dev/null J'ai réalisé que je n'allais pas saturer mon réseau 10Gbit de toute façon, donc j'ai décidé de laisser le pool de sauvegarde utiliser zfs set compression=gzip .

Les chiffres s'avèrent être similaires.

C'est assez dur pour le CPU, mais l'utilisation de mbuffer aide beaucoup.

expéditeur : zfs send -v dank/data@snapshot | mbuffer -s 128k -m 10G -O s2dna:9090

récepteur : mbuffer -s 128k -m 10G -I 9090 | zfs receive -s -v backuppool/engram/data

Ce grand tampon est utilisé lorsque le CPU est occupé à compresser... il sera occasionnellement plein, donc il pourrait être plus grand.

Dans l'ensemble, je suis satisfait du débit, qui était à deux chiffres sans mbuffer : bmon throughput for zfs send with mbuffer

cpu hates gzip

Répondu el 6 de Mars, 2020 par MattK (7319 Points )

-1voto

TuxOtaku avatar
TuxOtaku Points 59

Avez-vous envisagé de régler votre pile TCP/IP de manière à ce que la taille de votre tampon TCP et de vos fenêtres soit un peu plus grande ? Vous pouvez utiliser la fonction ndd sur Solaris pour cela ou l'outil sysctl sur Linux/BSD/Mac OSX. Sur Solaris, vous recherchez l'outil /dev/tcp tcp_max_buf y /dev/tcp tcp_cwnd_max et sur Linux sysctl, vous recherchez net.ipv4.tcp_mem , net.ipv4.tcp_rmem y net.ipv4.tcp.wmem valeurs.

Ces liens peuvent également vous être utiles :

Optimisation des performances TCP de Solaris

Il y a un ensemble de liens au bas de cette page qui expliquent comment faire de même pour Linux/BSD/OSX.

Répondu el 8 de Mai, 2014 par TuxOtaku (59 Points )

1 votes

Avatar de frameworkninja

1. C'est une question vieille de 5 ans que vous déterrez. 2. Il n'a pas dit que le lien était sous-utilisé et a posé une question sur la compression, à laquelle vous ne faites pas référence. 3. De nos jours, la plupart des systèmes d'exploitation ajustent automatiquement la taille de la fenêtre. L'information que vous mettez en lien était vieille de 3 ans lorsque l'auteur l'a postée.

Commenté el 8 de Mai, 2014 par frameworkninja

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X