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

Question

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

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

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

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

Answer 1

Какой тип репо у вас есть?ФСФС или БДБ?

(Давайте предположим, что это 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 сохраняет самую последнюю версию в виде полного текста с обратными различиями.Это означает, что обновления в head всегда происходят быстро, и вы постепенно платите за то, чтобы заглянуть все дальше и дальше в историю.

Answer 3

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

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

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

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

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

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

Answer 4

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

Answer 5

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

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

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

Да, и я работал над репозиториями CVS с более чем 2 ГБ контента (код, изображения, документы) и никогда не имел проблем с производительностью.Поскольку svn — это значительное улучшение по сравнению с cvs, я не думаю, что вам стоит об этом беспокоиться.

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

Answer 6

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

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

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

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

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

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

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

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

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