Производительность SVN после многих ревизий
Мой проект в настоящее время использует svn-репозиторий, который получает несколько сотен новых ревизий в день. Репозиторий находится на Win2k3-сервере и обслуживается через Apache/mod_dav_svn.
Теперь я боюсь, что со временем производительность ухудшится из-за слишком большого количества изменений.
Этот страх разумен?
Мы уже планируем обновить до 1.5, поэтому наличие тысяч файлов в одном каталоге не будет проблемой в долгосрочной перспективе.
Subversion сохраняет дельту (различия) между двумя ревизиями, так что это помогает сэкономить много места, особенно если вы только фиксируете код (текст) и не используете двоичные файлы (изображения и документы).
Означает ли это, что для проверки 10-й версии файла foo.baz svn будет принимать 1-ю версию, а затем применять дельты 2-10?
9 ответов
Какой тип репо у вас есть? FSFS или BDB?
(Давайте предположим, что FSFS сейчас, так как это по умолчанию.)
В случае FSFS каждая ревизия сохраняется как разница с предыдущей. Итак, вы думаете, что да, после многих пересмотров, это будет очень медленно.
Однако это не так. FSFS использует так называемые "пропуски дельт", чтобы избежать необходимости выполнять слишком много поисков на предыдущих оборотах.
(Так что, если вы используете репозиторий FSFS, ответ Брэда Уилсона неверен.)
В случае с репозиторием BDB ревизия HEAD (последняя) является полнотекстовой, но более ранние ревизии строятся в виде серии различий в голове. Это означает, что предыдущие обороты должны пересчитываться после каждого коммита.
Для получения дополнительной информации: http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas
PS Объем репо составляет около 20 ГБ, с 35 000 ревизий, и мы не заметили снижения производительности.
Subversion хранит самую последнюю версию в виде полного текста с обратными взглядами. Это означает, что обновления в голове всегда бывают быстрыми, а то, за что вы постепенно платите, смотрит в историю все дальше и дальше.
Лично я не имел дело с репозиториями Subversion с базами кодов больше 80K LOC для данного проекта. Самый большой репозиторий, который у меня был на самом деле, был около 1,2 гигабайта, но он включал в себя все библиотеки и утилиты, которые использует проект.
Я не думаю, что повседневное использование будет сильно затронуто, но все, что нужно для просмотра различных ревизий, может немного замедлить. Это может даже не быть заметным.
Теперь, с точки зрения системного администратора, есть несколько вещей, которые могут помочь вам минимизировать узкие места в производительности. Поскольку Subversion в основном файловая система, вы можете сделать это:
- Поместите фактические репозитории в другой диск
- Убедитесь, что на диске выше не работают никакие приложения для блокировки файлов, кроме svn
- Сделайте диски не менее 7500 об / мин. Вы можете попытаться получить 10000 оборотов в минуту, но это может быть излишним
- Обновите локальную сеть на гигабитную, если все находятся в одном офисе.
Это может быть излишним для вашей ситуации, но это то, что я обычно делал для других приложений с интенсивным использованием файлов.
Если вы когда-нибудь "перерастете" Subversion, то Perforce станет вашим следующим шагом вверх. Это самое быстрое приложение для управления исходным кодом для очень больших проектов.
У нас работает сервер 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
Subversion сохраняет только дельту (различия) между двумя ревизиями, так что это помогает сэкономить много места, особенно если вы только фиксируете код (текст) и не используете двоичные файлы (изображения и документы).
Кроме того, я видел много очень больших проектов, использующих SVN, и никогда не жаловался на производительность.
Может быть, вы беспокоитесь о времени оформления заказа? тогда я думаю, что это действительно будет проблема с сетью.
О, и я работал над CVS-репозиториями с объемом более 2 Гб (код, imgs, docs) и никогда не имел проблем с производительностью. Так как svn - отличное улучшение для cvs, я не думаю, что вам стоит беспокоиться.
Надеюсь, это немного поможет вашему разуму;)
Единственные операции, которые могут замедляться, это вещи, которые читают информацию из нескольких ревизий (например, SVN Blame).
Я не уверен..... Я использую SVN с apache на Centos 5.2. Работает нормально Номер ревизии был 8230 примерно такой... И на всех клиентских машинах Commit был настолько медленным, что нам пришлось ждать как минимум 2 минуты для файла размером 1 КБ. Я говорю об одном файле, который не имеет большого размера.
Затем я сделал новый репозиторий. Начинается с рев. 1. Теперь работает нормально. Быстро. использовал свнадмин создать хххххх. не проверял это FSFS или BDB.....
Возможно, вам стоит подумать об улучшении вашего рабочего процесса.
Я не знаю, будут ли репозитории иметь проблемы с производительностью в этих условиях, но у вас будет возможность вернуться к нормальной версии.
В вашем случае вы можете захотеть включить процесс проверки, поэтому команда фиксируется в репо руководителя группы, и каждый из них фиксирует репозиторий руководителя группы, который фиксирует чистые репо компании только для чтения. На этом этапе вы должны сделать правильный выбор того, какой коммит должен идти на вершину.
Таким образом, любой может вернуться к чистой копии с легким просмотром истории. Слияние намного проще, и dev все еще может фиксировать их беспорядок сколько угодно.