Как повысить производительность обновления клиента 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
.