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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

P.S. Наше репо составляет около 20 ГБ, около 35 000 исправлений, и мы не заметили каких-либо ухудшений производительности.

Answer 2

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

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

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

О, и я работал над репозиториями CVS с 2Gb + материала (код, imgs, docs) и никогда не имел проблемы с производительностью. Поскольку svn является большим улучшением на cvs, я не думаю, что вам следует беспокоиться.

Надеется, что это помогает легко ваш уму немного;)

Answer 3

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

Answer 4

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

Answer 5

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

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

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

• Поместите фактические хранилища в другом диске
• Убедитесь, что файл не блокировки приложений, кроме SVN, работает на диске выше
• Сделайте диски не менее 7 500 об/мин.Вы можете попробовать получить 10 000 об/мин, но это может быть перебор.
• Обновите LAN до гигабита, если все в одном офисе.

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

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

Answer 9

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

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

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

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

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

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

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

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

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