Производительность SVN после многих ревизий

Question

Мой проект в настоящее время использует репозиторий SVN, который получает несколько сотен новых ревизий в день. Репозиторий находится на Win2k3-сервере и обслуживается через Apache / mod_dav_svn.

Теперь я боюсь, что со временем производительность ухудшится из-за слишком большого количества ревизий.
Этот страх разумен?
Мы уже планируем обновить до 1.5, поэтому наличие тысяч файлов в одном каталоге не будет проблемой в долгосрочной перспективе.

В Subversion хранится дельта (различия) между двумя ревизиями, поэтому это помогает сэкономить МНОГО места, особенно если вы только фиксируете код (текст) и не используете двоичные файлы (изображения и документы).

Означает ли это, что для проверки 10-й версии файла foo.baz svn примет версию 1, а затем применит дельты 2-10?

Answer 1

Какой тип репо у вас есть? FSFS или BDB?

(Давайте предположим, что FSFS сейчас, так как это по умолчанию.)

В случае FSFS каждая ревизия сохраняется как разница с предыдущей. Итак, вы думаете, что да, после многих ревизий это будет очень медленно.

Однако это не так. FSFS использует так называемые «пропуски дельт», чтобы избежать необходимости выполнять слишком много поисков на предыдущих оборотах.

(Итак, если вы используете репозиторий FSFS, ответ Брэда Уилсона неверен.)

В случае с репозиторием BDB, ревизия HEAD (самая последняя) является полнотекстовой, но более ранние ревизии строятся как серия различий против головы. Это означает, что предыдущие обороты должны пересчитываться после каждой фиксации.

Для получения дополнительной информации: http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas

P.S. Объем репо составляет около 20 ГБ, с 35 000 ревизий, и мы не заметили снижения производительности.

Answer 2

Subversion хранит самую последнюю версию в виде полного текста с обратными взглядами. Это означает, что обновления в голове всегда бывают быстрыми, а то, за что вы постепенно платите, смотрит в историю все дальше и дальше.

Answer 3

Лично я не имел дело с репозиториями Subversion с базами кодов больше 80K LOC для данного проекта. Самый большой репозиторий, который у меня был на самом деле, был около 1,2 гигабайта, но он включал все библиотеки и утилиты, которые использует проект.

Я не думаю, что повседневное использование будет сильно затронуто, но все, что нужно для просмотра различных ревизий, может немного замедлить. Это может даже не быть заметным.

Теперь, с точки зрения системного администратора, есть несколько вещей, которые могут помочь вам минимизировать узкие места в производительности. Поскольку Subversion является в основном файловой системой, вы можете сделать это:

• Поместите действительные репозитории в другой диск
• Убедитесь, что никакие приложения для блокировки файлов, кроме svn, не работают на диске выше
• Сделать диски не менее 7500 оборотов в минуту. Вы можете попытаться получить 10000 оборотов в минуту, но это может быть излишним
• Обновите локальную сеть на гигабитную, если все находятся в одном офисе.

Это может быть излишним для вашей ситуации, но это то, что я обычно делал для других приложений, интенсивно использующих файлы.

Если вы когда-нибудь "перерастете" Subversion, то Perforce станет вашим следующим шагом вверх. Это самое быстрое приложение для управления исходным кодом для очень больших проектов.

Answer 4

Мы работаем на сервере Subversion с гигабайтами кода и двоичных файлов, и его количество обновлений превышает двадцать тысяч. Замедлений пока нет.

Answer 5

Я не думаю, что наша подрывная деятельность замедляется старением. В настоящее время у нас есть несколько терабайт данных, в основном двоичные. Мы проверяем / фиксируем ежедневно до 50 гигабайт данных. Всего у нас на данный момент 50000 ревизий. Мы используем FSFS в качестве типа хранилища и взаимодействуем либо напрямую с SVN: (сервер Windows), либо через Apache mod_dav_svn (сервер Gentoo Linux).

Я не могу подтвердить, что это приводит к замедлению работы svn, так как мы настроили чистый сервер для сравнения производительности, с которым мы могли бы сравнивать. Мы НЕ МОЖЕМ измерить значительное ухудшение.

Однако я должен сказать, что наша subversion по умолчанию необычайно медленная и, очевидно, это сама Subversion, как мы пытались с другой компьютерной системой.

По некоторым неизвестным причинам Subversion, по-видимому, полностью ограничен ЦП сервера. Наши скорости проверки / фиксации ограничены 15-30 Мегабайтами / с на клиента, потому что тогда одно ядро ​​ЦП сервера полностью израсходовано. Это то же самое для почти пустого репозитория (1 гигабайт, 5 ревизий) и для нашего полного сервера (~ 5 терабайт, 50000 ревизий). Настройка, например, установка сжатия на 0 = выкл, не улучшила это.

Наш High Bandwith (обеспечивает ~ 1 Гигабайт / с) FC-массива холостого хода, остальные ядра бездействуют и сеть (в настоящее время 1 Гигабит / с для клиентов, 10 Гигабит / с для сервера) также не работают Хорошо, на самом деле не на холостом ходу, но если используется только 2-3% доступной емкости, я называю это холостым ходом.

Не очень интересно видеть все компоненты на холостом ходу, и нам нужно подождать, пока наши рабочие копии будут извлечены или найдены. По сути, я понятия не имею, что делает процесс сервера, полностью потребляя одно ядро ​​ЦП все время во время извлечения / фиксации.

Однако я просто пытаюсь найти способ настроить подрывную деятельность. Если это невозможно, нам может потребоваться перейти на другую систему.

Поэтому: Ответ: Нет SVN не ухудшает производительность, это изначально медленно.

Конечно, если вам не нужна (высокая) производительность, у вас не будет проблем. Btw. все вышеперечисленное относится к последней стабильной версии subversioon 1.7

Answer 6

Subversion сохраняет только дельту (различия) между двумя ревизиями, так что это помогает сэкономить МНОГО места, особенно если вы только фиксируете код (текст) и не используете двоичные файлы (изображения и документы).

Кроме того, я видел много очень больших проектов, использующих svn, и никогда не жаловался на производительность.

Может быть, вы беспокоитесь о времени оформления заказа? тогда я думаю, что это действительно будет проблема с сетью.

О, и я работал над CVS-репозиториями с объемом содержимого более 2 ГБ (код, imgs, docs) и никогда не имел проблем с производительностью. Так как svn - отличное улучшение для cvs, я не думаю, что вам стоит беспокоиться.

Надеюсь, это немного поможет вашему уму;)

Answer 7

Единственными операциями, которые могут замедляться, являются вещи, которые читают информацию из нескольких ревизий (например, SVN Blame).

Answer 8

Может быть, вам стоит подумать об улучшении вашего рабочего процесса.

Я не знаю, будут ли репозитории иметь проблемы с производительностью в этих условиях, но у вас будет возможность вернуться к нормальной версии.

В вашем случае вы можете захотеть включить процесс проверки, поэтому команда фиксирует в репо руководителя группы, и каждый из них фиксирует репо менеджера команды, который фиксирует чистые репо компании только для чтения. На этом этапе вы сделали чистый выбор того, какой коммит должен идти наверх.

Таким образом, любой может вернуться к чистой копии с легким просмотром истории. Слияния намного проще, и dev все еще может фиксировать их беспорядок сколько угодно.

Answer 9

Я не уверен ..... Я использую SVN с apache на Centos 5.2. Работает нормально Номер ревизии был 8230 примерно такой ... И на всех клиентских машинах Commit был настолько медленным, что нам пришлось ждать как минимум 2 минуты файла размером 1 КБ. Я говорю об одном файле, который не имеет большого размера.

Затем я сделал новый репозиторий. Начинается с рев. 1. Теперь работает нормально. Быстро. использовал свнадмин создать хххххх. не проверял, это FSFS или BDB .....