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

Ответ 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 ревизий, и мы не заметили снижения производительности.

Ответ 2

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

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

Надеюсь, это немного облегчит ваш ум;)

Ответ 6

Я не думаю, что наша подрывная деятельность замедлила старение. В настоящее время мы имеем несколько 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% доступной емкости, я называю это холостым ходом.

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

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

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

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

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

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