Тигель Atlassian, очень медленный на большом репозитории
Мы используем Тенденцию для наших Серверов и Рабочих станций и как он вполне немного. Это - довольно легкий вес, и легкий настроить и развернуться. Экран управления действительно требует IE, так как это - весь управляемый ActiveX, таким образом, это вниз сторона.
Существует известная ошибка с ним и Windows 2008, где Брандмауэр может вывести сервер (даже если брандмауэр не включен в административном средстве). Я имею пару сотни серверов, выполняющих его, и имел 1 машину, имеют проблему. Просто снимите флажок с брандмауэром в свойствах Network на машине, и это зафиксировало его.
Они, как предполагается, работают над фиксацией так, чтобы, когда Брандмауэр отключен, он был на самом деле отключен, не работающий со всеми открытыми портами.
Начиная с миграции на MySQL имел заметное значение для некоторых репозиториев, рассмотрите настройку базы данных для дальнейшего совершенствования. Изменение некоторых my.cnf значения от значений по умолчанию могут иметь огромное значение. Посмотрите Основы Оптимизации Работы InnoDB для получения дополнительной информации. Также проверьте на медленные запросы путем включения медленного запроса, регистрируют и добавляют индексы в соответствующих случаях.
Мое следующее предположение было бы скоростью сети: Ваш Тигельный экземпляр в той же проводной локальной сети как Ваши репозитории SVN? Вы могли бы также попытаться дать Тиглю пробный шанс на той же машине как Ваше первичное хранилище, если это возможно, для устранения сетевой задержки как преступник.
И я знаю, что это могло бы быть трудно в зависимости от Вашей рабочей среды, но рабочий Тигель в VM, вероятно, не помогает вещам; Atlassian обращает внимание на это на их очень кратких Лучших практиках для страницы Crucible Configuration. Я уверен, что Вы уже столкнулись с ним, но я также упомяну страницу Tuning FishEye для других читателей.
Я также имею проблемы производительности для крупных проектов, но приписываю большое замедление к тяжелому веб-интерфейсу Тигля. Это особенно верно после нажатия вокруг некоторое время (ранее просмотренные страницы в обзоре остаются в окне браузера, даже когда скрытый от вида). Наши разработчики заметили небольшое увеличение скорости путем переключения на Google Chrome. Также проверьте Коннектор IDE Atlassian, если совместимый плагин существует для Вашей среды разработки. Коннектор Eclipse IDE имел собственные проблемы в прошлый раз, когда я использовал его (много месяцев назад), но он мог, по крайней мере, обработать большие наборы файла без зависания.
В зависимости от методов разработки Вашей компании Вы могли прекратить сканировать большое количество ответвлений кода (предполагающий, что многие из них больше не активны), и отключите репозитории для завершенных/мертвых проектов, пока они не необходимы. Моя компания использует очень малочисленные команды на большом количестве проектов, поэтому большую часть времени мы работаем, прежде всего, над trunk, создание ответвлений исключение; мы поэтому явно добавляем ответвления для сканирования вместо включения всех ответвлений по умолчанию. Также удостоверьтесь, что Вы случайно не сканируете теги.
Как Ваше использование ЦП на поле Crucible? Если Вы используете SVN позади Apache HTTPD, исследуете, сколько соединений используется Тиглем во время большого сканирования репозитория. Кроме этого, я не уверен, на что еще Вы могли посмотреть (возможно, скорость диска? Частота сканирования репозитория?), но надо надеяться вышеупомянутые подсказки помогут немного.
> 4 G RAM не являются "безумно мощными" аппаратными средствами. Принятие Вас имеет 25 пользователей, и Вы используете Подозрительный взгляд (который Вы упоминаете), Вы тратите 4 400$ на просто программное обеспечение. $4 тысячи в Dell могли купить Вас сервер с 48G RAM.
Кроме того, Вы используете 64-разрядную JVM? Документы предполагают, что Вы будете рассматривать лучший объем потребляемой памяти (как в, меньше из него) на 32-разрядной JVM.
Хотя я на самом деле не пробовал это сам, у меня точно такие же симптомы, как и у вас.
В настоящее время я подумываю отключить сохраненную информацию о различиях для проблемных репозиториев. Я задал вопрос на сайте вопросов и ответов Atlassian и получил несколько многообещающих советов.
Моя проблема та же - проблема не в индексировании, это огромные объемы дискового пространства, работающие на плохо работающем дисковом массиве в ВМ. Поскольку в настоящее время я не могу обновить диск, мне нужно найти другой способ обойти это. Ответчик в моем сообщении выше говорит, что удаление информации о различиях уменьшит размер диска за счет потери возможности поиска добавленных / удаленных строк . Хотя он также предполагает, что это не повлияет на скорость просмотра файлов с длинной историей.