Performances SVN après plusieurs révisions

Question

Mon projet utilise actuellement un référentiel svn qui génère plusieurs centaines de nouvelles révisions par jour. Le référentiel réside sur un serveur Win2k3 et est servi via Apache / mod_dav_svn.

Je crains maintenant qu'avec le temps, les performances se dégradent en raison de trop de révisions.
Cette crainte est-elle raisonnable?
Nous prévoyons déjà de passer à la version 1.5, donc avoir des milliers de fichiers dans un seul répertoire ne posera pas de problème à long terme.

  

Subversion on enregistre le delta (différences), entre 2 révisions, ce qui permet de gagner beaucoup d’Espace, en particulier si vous ne commettez que du code (texte) et aucun binaire (images et docs).

Est-ce que cela signifie que pour vérifier la révision 10 du fichier foo.baz, svn utilisera la révision 1, puis appliquera les deltas 2-10?

Answer 1

Quel type de pension avez-vous? FSFS ou BDB?

(Supposons FSFS pour l'instant, car c'est la valeur par défaut.)

Dans le cas de FSFS, chaque révision est stockée sous forme de diff par rapport à la précédente. Donc, on pourrait penser qu’en effet, après de nombreuses révisions, ce serait très lent.

Cependant, ce n'est pas le cas. FSFS utilise ce que l’on appelle "ignorer les deltas". pour éviter d'avoir à faire trop de recherches sur les régimes précédents.

(Donc, si vous utilisez un dépôt FSFS, la réponse de Brad Wilson est fausse.)

Dans le cas d'un référentiel BDB, la révision HEAD (la plus récente) est en texte intégral, mais les révisions antérieures sont construites sous la forme d'une série de diffs par rapport à l'en-tête. Cela signifie que les tours précédents doivent être recalculés après chaque validation.

Pour plus d'informations: http: //svn.apache. org / repos / asf / subversion / trunk / notes / skip-deltas

P.S. Notre pension fait environ 20 Go, avec environ 35 000 révisions, et nous n’avons constaté aucune dégradation des performances.

Answer 2

Subversion stocke la version la plus récente en texte intégral, avec des diffs rétrospectives. Cela signifie que les mises à jour de la tête sont toujours rapides et que vous payez progressivement de plus en plus loin dans l'histoire.

Answer 3

Personnellement, je n'ai pas traité de référentiels Subversion avec des bases de code supérieures à 80K LOC pour le projet actuel. Le plus grand dépôt que j’ai eu en réalité a été d’environ 1,2 Go, mais cela inclut toutes les bibliothèques et tous les utilitaires utilisés par le projet.

Je ne pense pas que l’utilisation quotidienne en soit affectée autant, mais tout ce qui doit être examiné à travers les différentes révisions risque de ralentir un peu. Il se peut même que cela ne soit pas perceptible.

Maintenant, du point de vue de l’administrateur système, certains éléments peuvent vous aider à réduire les goulots d’étranglement liés aux performances. Puisque Subversion est principalement un système basé sur des fichiers, vous pouvez le faire:

• Placez les référentiels dans un autre lecteur
• Assurez-vous qu'aucune application de verrouillage de fichier, autre que svn, ne fonctionne sur le lecteur situé au-dessus de
.
• Faites que les disques durent au moins 7 500 tr / min. Vous pouvez essayer d’obtenir 10 000 tr / min, mais c’est peut-être excessif
• Mettez le réseau local à niveau en gigabits, si tout le monde est dans le même bureau.

Cela peut sembler excessif dans votre cas, mais c'est ce que je fais habituellement pour d'autres applications gourmandes en fichiers.

Si vous avez déjà "dépassé" " Subversion, puis Perforce sera votre prochaine étape. Il s’agit de l’application de contrôle de code source la plus rapide pour les très grands projets.

Answer 4

Nous exploitons un serveur de subversion avec une valeur de giga-octets de code et de fichiers binaires pouvant aller jusqu'à plus de vingt mille révisions. Pas encore de ralentissements.

Answer 5

Subversion ne stocke que les différences (delta), entre 2 révisions, ce qui permet de gagner beaucoup d’Espace, en particulier si vous ne commettez que du code (texte) et aucun binaire (images et docs).

De plus, j'ai vu beaucoup de très gros projets utilisant svn et je ne me suis jamais plaint de la performance.

Peut-être vous inquiétez-vous des heures de départ? alors je suppose que ce serait vraiment un problème de réseau.

Oh, et j’ai travaillé sur des référentiels CVS avec plus de 2 Go d’objets (code, images, documents) et n’ai jamais eu de problème de performances. Puisque svn est une grande amélioration sur CVS, je ne pense pas que vous devriez vous inquiéter.

J'espère que cela vous aidera à détendre un peu votre esprit;)

Answer 6

Je ne pense pas que notre subversion ait été ralentie par le vieillissement. Nous avons actuellement plusieurs TeraBytes de données, principalement binaires. Nous empruntons / engageons quotidiennement jusqu'à 50 GigaByte de données. Au total, nous avons actuellement 50000 révisions. Nous utilisons FSFS comme type de stockage et interfacons directement avec SVN: (serveur Windows) ou via Apache mod_dav_svn (serveur Gentoo Linux).

Je ne peux pas confirmer que SVN ralentisse dans le temps car nous avons configuré un serveur propre pour la comparaison des performances, auquel nous pourrions comparer. Nous ne pourrions PAS mesurer une dégradation importante.

Cependant, je dois dire que notre subversion est inhabituellement lente par défaut et qu’il s’agit bien évidemment de la subversion elle-même, comme nous l’avons essayé avec un autre système informatique.

Pour des raisons inconnues, subversion semble totalement limité par le nombre de processeurs du serveur. Nos débits de sortie / validation sont limités à 15-30 Mo / s par client car un seul cœur de CPU serveur est complètement utilisé. Il en va de même pour un référentiel presque vide (1 GigaByte, 5 révisions) que pour notre serveur complet (~ 5 TeraByte, 50000 révisions). Un réglage similaire à la compression 0 = off n’a pas amélioré la situation.

Notre bande passante élevée (fournit environ 1 Go / s) de FC-Array au repos, les autres cœurs en veille et le réseau (actuellement 1 GigaBits / s pour les clients, 10 GigaBits / s pour le serveur) également. D'accord, pas vraiment au ralenti, mais si seulement 2-3% de la capacité disponible est utilisée, je l'appelle ralenti.

Il n’est pas amusant de voir tous les composants tourner au ralenti et nous devons attendre que nos copies de travail soient vérifiées ou validées. En gros, je n'ai aucune idée de ce que fait le processus serveur en consommant entièrement un cœur de processeur tout au long de l'extraction / de la validation.

Cependant, j'essaie simplement de trouver un moyen de régler la subversion. Si cela n’est pas possible, nous aurons peut-être besoin de passer à un autre système.

Par conséquent: Réponse: Non, le SVN ne dégrade pas ses performances, il est initialement lent.

Bien sûr, si vous n’avez pas besoin de performances (élevées), vous n’aurez pas de problème. Btw. tout ce qui précède s’applique à la dernière version stable de subversioon 1.7

Answer 7

Les seules opérations susceptibles de ralentir sont les choses qui lisent les informations de plusieurs révisions (par exemple, SVN Blame).

Answer 8

Je ne suis pas sûr ..... J'utilise SVN avec Apache sur Centos 5.2. Fonctionne bien. Le numéro de révision était 8230 quelque chose comme ça ... Et sur toutes les machines clientes, Commit était si lent que nous avons dû attendre au moins 2 minutes pour un fichier de 1 Ko. Je parle de 1 fichier qui n'a pas de grande taille.

Ensuite, j'ai créé un nouveau référentiel. Commencé du rev. 1. Maintenant, ça va. Vite. utilisé svnadmin create xxxxxx. n'a pas vérifié s'il s'agit de FSFS ou de BDB .....

Answer 9

Peut-être devriez-vous envisager d'améliorer votre flux de travail.

Je ne sais pas si un dépôt aura des problèmes de performance dans ces conditions, mais vous pourrez revenir à une révision saine.

Dans votre cas, vous souhaiterez peut-être inclure un processus de validation afin qu'une équipe s'engage dans un référentiel de chef d'équipe et que chacun d'entre eux s'engage dans le référentiel de responsable d'équipe qui s'engage dans les référentiels de société propres en lecture seule. Vous avez fait un choix précis au stade de ce que l’engagement doit aller au sommet.

De cette façon, tout le monde peut revenir à une copie vierge, avec un historique facile à parcourir. La fusion est beaucoup plus facile, et les développeurs peuvent toujours commettre leurs désordres autant de fois qu'ils le souhaitent.