Performances SVN après plusieurs révisions

Mon projet utilise actuellement un repository svn qui gagne 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, la performance se dégrade 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 répertoire ne sera pas un problème à long terme.

Subversion sur stocke le delta (différences), entre 2 révisions, ce qui permet d’économiser BEAUCOUP d’espace, surtout si vous ne validez que du code (texte) et pas de binarys (images et documents).

Cela signifie-t-il que pour vérifier la révision 10 du fichier foo.baz, svn prendra la révision 1 et appliquera ensuite les deltas 2-10?

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

(Supposons FSFS pour le moment, puisque 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, vous penseriez que oui, 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 des “deltas de saut” pour éviter d’avoir à effectuer trop de recherches sur les révolutions précédentes.

(Donc, si vous utilisez un repo 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 sur la tête. Cela signifie que les révolutions précédentes doivent être recalculées après chaque validation.

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

PS Notre repository est d’environ 20 Go, avec environ 35 000 révisions, et nous n’avons constaté aucune dégradation des performances.

Subversion stocke la version la plus récente en tant que texte intégral, avec des diffs rétrospectifs. Cela signifie que les mises à jour sont toujours rapides et que vous en payez de plus en plus dans l’histoire.

Personnellement, je n’ai pas traité de référentiels Subversion avec des codes plus grands que 80K LOC pour le projet actuel. Le plus grand repository que j’ai eu était d’environ 1,2 Go, mais cela incluait toutes les bibliothèques et les utilitaires utilisés par le projet.

Je ne pense pas que l’utilisation quotidienne sera autant affectée, mais tout ce qui doit passer en revue les différentes révisions pourrait ralentir un peu. Cela peut même ne pas être perceptible.

Désormais, du sharepoint vue de l’administrateur système, certaines choses peuvent vous aider à réduire les goulots d’étranglement. Comme Subversion est principalement un système basé sur des fichiers, vous pouvez le faire:

  • Placez les référentiels réels dans un lecteur différent
  • Assurez-vous qu’aucune application de locking de fichier, autre que svn, ne fonctionne sur le lecteur ci-dessus
  • Faites les disques au moins 7 500 tr / min. Vous pourriez essayer d’obtenir 10 000 tr / min, mais cela peut être excessif
  • Mettez à jour le LAN en gigabit, si tout le monde est dans le même bureau.

Cela peut être excessif pour votre situation, mais c’est ce que j’ai l’habitude de faire pour d’autres applications gourmandes en fichiers.

Si jamais vous deviez «dépasser» Subversion, Perforce sera votre prochaine étape. C’est l’application de contrôle de source la plus rapide pour les très grands projets.

Nous exécutons un serveur de subversion avec des gigaoctets de code et des binarys, et il y a plus de vingt mille révisions. Pas encore de ralentissement

Subversion ne stocke que le delta (différences), entre 2 révisions, ce qui permet d’économiser beaucoup d’espace, surtout si vous ne validez que du code (texte) et pas de binarys (images et documents).

De plus, j’ai vu beaucoup de très gros projets en utilisant svn et je ne me suis jamais plaint des performances.

Peut-être que vous êtes inquiet au sujet 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 repositorys CVS avec 2 Go de données (code, imgs, docs) et je n’ai jamais eu de problème de performance. Puisque svn est une grande amélioration sur les cvs, je ne pense pas que vous devriez vous inquiéter.

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

Je ne pense pas que notre subversion ait ralenti en vieillissant. Nous avons actuellement plusieurs TeraBytes de données, principalement binarys. Nous vérifions / validons quotidiennement jusqu’à 50 GigaByte de données. Au total, nous avons actuellement 50000 révisions. Nous utilisons FSFS comme type de stockage et nous sums en interface directe avec SVN: (serveur Windows) ou via Apache mod_dav_svn (serveur Linux Gentoo).

Je ne peux pas confirmer que cela entraîne un ralentissement de svn, car nous avons mis en place un serveur propre pour la comparaison des performances. Nous n’avons pas pu mesurer une dégradation importante.

Cependant, je dois dire que notre subversion est inhabituellement lente par défaut et que c’est évidemment la subversion elle-même que nous avons essayée avec un autre système informatique.

Pour des raisons inconnues, subversion semble être complètement limitée au CPU du serveur. Nos taux de paiement / validation sont limités à entre 15 et 30 mégaoctets / s par client, puisqu’un seul cœur de processeur est complètement utilisé. C’est la même chose pour un repository presque vide (1 GigaByte, 5 révisions) que pour notre serveur complet (~ 5 TeraByte, 50000 révisions). Le réglage comme le réglage de la compression à 0 = off n’a pas amélioré cela.

Notre bande passante haute (livre ~ 1 GigaByte / s) est inactive, les autres cœurs sont inactifs et en réseau (actuellement 1 GigaBit / s pour les clients, 10 GigaBits / s pour le serveur). Okay pas vraiment au ralenti mais si seulement 2-3% de la capacité disponible est utilisée, je l’appelle inactif.

Il n’est pas vraiment 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. Fondamentalement, je n’ai aucune idée de ce que le processus du serveur fait en consommant un seul cœur de processeur tout le temps lors de la validation / validation.

Cependant, j’essaie juste de trouver un moyen de régler la subversion. Si ce n’est pas possible, nous pourrions avoir besoin de passer à un autre système.

Par conséquent: Réponse: Aucun 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 aucun problème. Btw. tout ce qui précède s’applique à la dernière version stable de subversioon 1.7

Les seules opérations susceptibles de ralentir sont celles qui lisent des informations issues de plusieurs révisions (par exemple, le blâme SVN).

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 client, Commit était si lent que nous avons dû attendre au moins 2min pour un fichier de 1kb. Je parle d’un fichier qui n’a pas de taille de fichier importante.

Ensuite, j’ai créé un nouveau référentiel. Commencé à partir de rev. 1. Maintenant, ça marche bien. Vite. svnadmin utilisé crée xxxxxx. n’a pas vérifié si c’est FSFS ou BDB …..

Vous devriez peut-être envisager d’améliorer votre stream de travail.

Je ne sais pas si un repos aura des problèmes de perf dans ces conditions, mais vous pourrez revenir à une révision sensée.

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 sur les mises en pension d’entreprise propres en lecture seule. Vous avez fait une sélection propre à ce stade de ce que le commit doit faire en haut.

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