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

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

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

Subversion on stores the delta (differences), between 2 revisions, so this helps saving a LOT of space, specially if you only commit code (text) and no binaries (images and docs).

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

Ответы на вопрос(9)

I don't know if a repos will have perf issues in these conditions, but you ability to go back to a sane revision will.

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

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

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

 10 апр. 2012 г., 19:36
Согласно приведенному здесь ответу, вы оба правы: «Subversion использует прямые дельты в репозиториях FSFS и обратные дельты в репозиториях BDB».stackoverflow.com/questions/8824597/…
 03 янв. 2012 г., 09:11
Subversion использует прогнозные дельты.

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

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

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

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

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

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

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

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

Решение Вопроса

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

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

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

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

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

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

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

 18 дек. 2008 г., 23:12
В вашем репо объемом 20 ГБ он хранится как FSFS или BDB?
 07 апр. 2009 г., 16:02
Это интересная информация. У меня есть хранилище с 73000 файлами (примерно 350 МБ), и это невероятно медленно. Я должен узнать, что они используют.
 27 янв. 2009 г., 01:38
Это FSFS (по крайней мере, сейчас). В течение 1-го года жизни нашего репо он был BDB (FSFS еще не существовало). В какой-то момент мы сделали цикл дампа / загрузки для преобразования в FSFS. У нас не было особых проблем с BDB, но FSFS кажется лучше с архитектурной точки зрения (следовательно, FSFS теперь используется по умолчанию).
 17 февр. 2010 г., 07:44
Как примечание, хранилище PHP хранится в Subversion с (на момент написания) 295 197 ревизиями.svn.php.net/repository/php/php-src/trunk

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

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

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

Put the actual repositories in a different drive Make sure that no file locking apps, other than svn, are working on the drive above Make the drives at least 7,500 RPM. You could try getting 10,000 RPM, but it may be overkill Update the LAN to gigabit, if everybody is in the same office.

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

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

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

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

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

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

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

 16 нояб. 2016 г., 14:43
& quot; В настоящее время у нас есть несколько терабайт данных, в основном двоичные. Мы проверяем / фиксируем ежедневно до 50 гигабайт данных. Всего на данный момент у нас 50000 ревизий. Это невероятно! С тех пор, как вы написали это в 2013 году, вы заметили какое-либо улучшение упомянутой вами проблемы с использованием ЦП, перейдя на более новые версии Subversion (если вы мигрировали; возможно, это адский перенос такого огромного репо)?

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

Ваш ответ на вопрос