Как повысить производительность обновления клиента Subversion для Windows?

Как повысить производительность обновления клиента Subversion? Он, по-видимому, связан с диском на клиенте.

Подробнее:

  • Клиент CollabNet для Windows версии 1.6.2 (r37639)
  • Windows XP SP2
  • 3 и nbsp; GB RAM с PF. Использование около 1 GB и системного кеша 1,1 GB.
  • У диска включено кэширование записи
  • Обновление занимает 7-15 минут (при очень небольшом обновлении).
  • Checkout имеет 36 083 каталогов/файлов (из списка svn)
  • Репозиторий имеет 58 750 исправлений.
  • Checkout занимает около 2,7 фунта стерлингов.
  • Монитор Perf показывает% Время записи диска во время обновления остается около 90%.
  • Макс. чтение диска на чтение/сек до 12.8M и запись до 5,2M
  • ЦП, использование файла подкачки и использование сети все невысоки.
  • Наблюдение за производительностью сервера, похоже, показывает, что это не узкое место.

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

Обновления некоторых предложений:

  • Мне нужно все это, поэтому редкие каталоги не будут работать.
  • Другой клиент (TortoiseSVN) занимает 7 минут.
  • Накладываются значки TortoiseSVN, поэтому они не вызывают проблемы.
  • Антивирус настроен так, чтобы пропускать этот каталог, поскольку он не вызывает проблемы.

ОТВЕТЫ

Ответ 1

Я переживаю то же самое. Недавно был заменен Perforce на svn, но если мы не сможем справиться с проблемами производительности на Windows, я должен рассмотреть другой инструмент. Использование svn 1.6.6, Win XP и Vista клиентов. Сервер RedHat. Мои наблюдения соответствуют вашим:

  • Огромная активность записи на диск.
  • Антивирус не является узким местом.
  • Независимо от того, используются ли svn-клиенты witch.
  • Отсутствие узкого места сервера или сети.

Дополнительная информация Операции более чем в 3 раза быстрее:

  • Linux (Ubuntu).
  • Linux (Ubuntu), работающий на VirtualBox на хосте Win Vista.
  • Win XP работает на VMWare на хосте RedHat.

Ответ 2

Вам нужен каждый бит репозитория на вашей рабочей копии? Если вы действительно заботитесь только об определенных частях дерева, посмотрите в Subversion Редкие каталоги (он же "Редкие проверки", ) особенность. Это позволяет вам манипулировать вашей рабочей копией, поэтому она содержит только те интересующие каталоги.

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

Ответ 3

Попробуйте svn client version 1.5.. Это помогло мне на моем ноутбуке Vista. Версии 1.6. очень медленны.

Ответ 4

Скорее всего, это ваша сеть и количество перемещенных данных, а также ваш клиент. Вы используете черепаху? Я считаю, что это немного медленнее, когда вы перемещаете столько данных!

Ответ 5

Используете ли вы TortoiseSVN? Если это так, Icon Overlays выполняет операции замедления. Если вы перейдете в TortoiseSVN Settings/Icon Overlays, вы можете настроить несколько параметров, чтобы контролировать уровень, на который вы хотите использовать Overlays, включая полное их отключение. Посмотрите, влияет ли это на вашу производительность.

Ответ 6

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

Ответ 7

Никто, кажется, не указывает одну причину, по которой я часто рассматриваю недостаток дизайна. Subversion создает вторую "первозданную" копию проверки для автономных операций. Если вы проверяете 4G файлов, он фактически записывает 8G на диск.

Сравните выгрузку с экспортом. Это покажет вам огромную разницу при написании этих вторых копий.

Там вы ничего не можете с этим сделать.

Ответ 8

Переход на svn 1.7

От Обсуждение медленной производительности обновления SVN:

Процесс обновления в svn 1.6 выглядит примерно так:

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

Если существует много каталогов и файлов, шаги 1 и 4 могут занимать много времени. Это будет соответствовать вашему наблюдению за длинными задержек без сетевого трафика.

Формат рабочей копии был изменен в svn 1.7. Теперь вся метаинформация хранится в базе данных SQLite в корневой папке рабочей копии, и нет необходимости выполнять шаги 1 и 4, которые больше всего потребляют большую часть времени svn update.