Моя компания уже несколько месяцев проводит испытания Atlassian Crucible. Что касается репозиториев, где он работает правильно, пользователи оставили очень положительные отзывы об инструменте. Проблема, с которой я столкнулся, заключается в том, что у нас есть несколько разных проектов, каждый со своим собственным репозиторием, и некоторые из этих репозиториев очень большие. В частности, один репозиторий имеет большое количество веток и, вероятно, около 9000 файлов на ветку. Просмотр этого репозитория в Crucible происходит очень медленно.
Crucible работает на виртуальной машине CentOS. У виртуальной машины 4 ГБ ОЗУ, и я установил максимум Crucible на 3 ГБ, из которых в настоящее время используется 2 ГБ. Я упомянул об этом в обращении в службу поддержки Atlassian, и они предложили следующее:
В частности, поскольку у вас довольно большой репозиторий SVN, вы, вероятно, обнаружите, что Fisheye будет создавать большой файл индекса на диске. Чтобы повысить производительность, вы можете попробовать следующее:
- Увеличение доступной памяти для Fisheye.
- Переход на внешнюю базу данных.
- Исключение ненужных файлов и каталогов из индекса.
Я пробовал все это до некоторой степени, но пока ни один из них не помог. Изначально я запускал Crucible на компьютере с Windows с 2 ГБ ОЗУ, используя встроенную базу данных HSQL. Переход на MySQL на CentOS привел к увеличению производительности некоторых репозиториев и сделал Crucible намного более стабильным, но, похоже, не очень помог с нашим самым большим репозиторием. Есть только определенное количество файлов / веток, которые я могу исключить из индексации, сохраняя при этом полезность инструмента.
В таком случае, есть ли у кого-нибудь советы о том, как ускорить Crucible в больших репозиториях, не вкладывая деньги в безумно мощное оборудование?
Спасибо!
Редактировать: Чтобы уточнить, поскольку я не упомянул об этом явно выше, я я используя FishEye.
Изменить 2: С тех пор, как я изначально опубликовал это, производительность несколько улучшилась с новыми выпусками Crucible, но это все еще не очень хорошо. Похоже, что эта проблема влияет на многих пользователей, в том числе с гораздо более мощным оборудованием, чем мы используем. Таким образом, я не считаю, что это проблема с оборудованием, а скорее проблема с присущей Crucible неэффективностью. Atlassian знает об этой проблеме и будет включать дальнейшие улучшения производительности в будущие выпуски, поэтому мы надеемся, что эти изменения решат наши проблемы.
Изменить 3: Я забыл, как давно я задавал этот вопрос, поэтому в своем предыдущем редактировании я не упомянул, что наша ситуация с оборудованием также изменилась с тех пор, как он был задан изначально. Сейчас мы запускаем Crucible на выделенном физическом сервере, все еще используя CentOS. Аппаратное обеспечение по-прежнему скромное (4 ГБ ОЗУ, четырехъядерный ЦП и два диска по 500 ГБ в RAID 1 с внешним резервным копированием), но мы действительно увидели небольшое увеличение производительности, когда мы отошли от виртуальной машины.
Поскольку переход на MySQL привел к заметным изменениям для некоторых репозиториев, подумайте о настройке базы данных для дальнейших улучшений. Меняя некоторые my.cnf значения по умолчанию могут иметь огромное значение. Видеть Основы оптимизации производительности InnoDB Чтобы получить больше информации. Также проверьте медленные запросы, включив журнал медленных запросов и при необходимости добавьте индексы.
Следующим моим предположением будет скорость сети: находится ли ваш экземпляр Crucible в той же проводной локальной сети, что и ваши репозитории SVN? Вы также можете попробовать провести пробный запуск Crucible на том же компьютере, что и ваш основной репозиторий, если это возможно, чтобы устранить сетевую задержку как виновника.
И я знаю, что это может быть сложно в зависимости от вашей рабочей среды, но запуск Crucible на виртуальной машине, вероятно, не помогает; Atlassian отмечает это в своем очень кратком Рекомендации по настройке тигля страница. Я уверен, что вы уже сталкивались с этим, но я также упомяну Настройка FishEye страница для других читателей.
У меня также есть проблемы с производительностью для больших проектов, но я приписываю большую медлительность тяжелому веб-интерфейсу Crucible. Это особенно актуально после небольшого щелчка мышью (ранее просмотренные страницы в обзоре остаются в окне браузера, даже если они скрыты от глаз). Наши разработчики заметили небольшое увеличение скорости при переходе на Google Chrome. Также ознакомьтесь с Коннектор Atlassian IDE если для вашей среды разработки существует совместимый плагин. Коннектор Eclipse IDE Connector имел собственные проблемы в последний раз, когда я использовал его (много месяцев назад), но он мог, по крайней мере, обрабатывать большие наборы файлов без зависания.
В зависимости от практики разработки вашей компании вы можете прекратить сканирование большого количества ветвей кода (при условии, что многие из них больше не активны) и отключить репозитории для завершенных / мертвых проектов, пока они не понадобятся. В моей компании очень маленькие команды работают над большим количеством проектов, поэтому большую часть времени мы работаем в основном над trunk, делая ветви исключением; поэтому мы явно добавляем ветки для сканирования вместо того, чтобы включать все ветки по умолчанию. Также убедитесь, что вы случайно не сканируете теги.
Как ваша загрузка ЦП на коробке Crucible? Если вы используете SVN за Apache HTTPD, проверьте, сколько подключений использует Crucible во время сканирования большого репозитория. Помимо этого, я не уверен, что еще вы могли посмотреть (может быть, скорость диска? Частота сканирования репозитория?), Но, надеюсь, приведенные выше советы немного помогут.
> 4 ГБ ОЗУ - это не «безумно мощное» оборудование. Предполагая, что у вас 25 пользователей и вы используете Fisheye (о котором вы упомянули), вы тратите 4400 долларов только на программное обеспечение. За 4 тысячи долларов в Dell можно купить сервер с 48 ГБ оперативной памяти.
Кроме того, вы используете 64-битную JVM? Документы предполагают, что вы увидите лучший объем памяти (например, меньше) на 32-битной JVM.
Хотя я сам этого не пробовал, у меня точно такие же симптомы, как и у вас.
В настоящее время я рассматриваю возможность отключения сохраненной информации о различиях в репозиториях с нарушением правил. Я задал вопрос о Сайт вопросов и ответов Atlassian и получил многообещающий совет.
У меня та же проблема - проблема не в индексировании, это огромная дисковая память, работающая на плохо работающем дисковом массиве виртуальной машины. Поскольку в настоящее время я не могу обновить диск, мне нужно найти другой способ обойти это. Ответчик в моем сообщении выше говорит, что удаление информации о различиях будет уменьшить занимаемый диск за счет потеря возможности поиска добавленных / удаленных строк. Хотя он также предполагает, что это не повлияет на скорость просмотра файлов с длинной историей.
Если кто-то еще видит это и может сообщить об успешном / неудачном использовании этого переключателя, прокомментируйте здесь.
О, и я запускаю 2.7.13 с теми же проблемами производительности.