Crisol Atlassian muito lento em repositório grande

Minha empresa está executando um teste do Crisol Atlassian há alguns meses. Para repositórios em que está funcionando corretamente, os usuários deram um feedback muito positivo sobre a ferramenta. O problema que estou tendo é que temos vários projetos diferentes, cada um com seu próprio repositório, e alguns desses repositórios são muito grandes. Um repositório em particular possui um grande número de ramificações e provavelmente cerca de 9.000 arquivos por ramificação. A navegação nesse repositório no Crucible é extremamente lenta.

O Crisol está sendo executado em uma VM CentOS. A VM tem 4 GB de RAM, e eu configurei o máximo do Crisol em 3 GB, dos quais atualmente está usando 2 GB. Trouxe isso em um tíquete de suporte com a Atlassian e eles sugeriram o seguinte:

Em particular porque você tem um repositório SVN bastante grande, provavelmente encontrará que o Fisheye criará um grande arquivo de índice em disco. Para ajudar a melhorar o desempenho, algumas coisas que você pode tentar são:

• Aumentando a memória disponível disponível para o Fisheye.
• Migrando para um banco de dados externo .
• Excluindo arquivos e diretórios do seu índice que não são necessários .

Eu tentei todas essas coisas até certo ponto, mas até agora nenhuma ajudou muito. Originalmente, eu estava executando o Crucible em uma caixa do Windows com 2 GB de RAM usando o banco de dados HSQL integrado. A mudança para o MySQL no CentOS teve um aumento de desempenho em alguns repositórios e tornou o Crucible muito mais estável, mas não pareceu ajudar muito com o nosso maior repositório. Existem apenas tantos arquivos / ramificações que posso excluir da indexação, mantendo a utilidade da ferramenta.

Sendo esse o caso, alguém tem alguma dica sobre como acelerar o Crisol em grandes repositórios, sem investir em hardware incrivelmente poderoso?

Obrigado!

Edit: Para esclarecer, desde que eu não mencionei explicitamente acima, eu estou usando o FishEye.

Edit 2: Desde que eu postei isso originalmente, o desempenho melhorou um pouco com os novos lançamentos do Crucible, mas ainda não é ótimo de forma alguma. Parece que esse problema afeta muitos usuários , incluindo alguns com hardware muito mais poderoso do que estamos usando. Portanto, não acredito que seja um problema de hardware, mas um problema com ineficiência inerente no Crisol. A Atlassian está ciente do problema e incluirá outras melhorias de desempenho em versões futuras, por isso espero que essas mudanças resolvam nossos problemas.

Edição 3: eu tinha esquecido há quanto tempo eu fiz essa pergunta, então na minha edição anterior eu esqueci de mencionar que a nossa situação de hardware também mudou desde que foi originalmente solicitada. Agora estamos executando o Crucible em um servidor físico dedicado, ainda usando o CentOS. O hardware ainda é modesto (4 GB de RAM, CPU quad core e discos duplos de 500 GB no RAID 1 com backup externo), mas vimos um ligeiro aumento de desempenho quando nos afastamos da VM.

Como a migração para o MySQL fez uma diferença notável em alguns repositórios, considere ajustar o banco de dados para obter mais melhorias. Alterar alguns my.cnfvalores dos padrões pode fazer uma enorme diferença. Consulte Noções básicas de otimização de desempenho do InnoDB para obter mais informações. Verifique também consultas lentas, ativando o log de consultas lentas e adicione índices, quando apropriado.

Meu próximo palpite seria a velocidade da rede: sua instância do Crucible está na mesma rede local com fio dos seus repositórios SVN? Você também pode tentar executar o Crucible na mesma máquina que seu repositório primário, se possível, para eliminar a latência da rede como a culpada.

E sei que pode ser difícil, dependendo do seu ambiente de trabalho, mas executar o Crisol em uma VM provavelmente não está ajudando; Atlassian faz uma anotação disso em sua breve página de Boas Práticas para Configuração do Crisol . Tenho certeza que você já se deparou com isso, mas também mencionarei a página Tuning FishEye para outros leitores.

Também tenho problemas de desempenho para grandes projetos, mas atribuo muita lentidão à pesada interface da web do Crucible. Isso é especialmente verdadeiro depois de clicar um pouco (as páginas exibidas anteriormente em uma revisão permanecem na janela do navegador, mesmo quando ocultas). Nossos desenvolvedores notaram um ligeiro aumento de velocidade ao mudar para o Google Chrome. Verifique também o Atlassian IDE Connector se houver um plug-in compatível para o seu ambiente de desenvolvimento. O Eclipse IDE Connector teve problemas próprios na última vez em que o usei (há muitos meses), mas podia pelo menos lidar com grandes conjuntos de arquivos sem desligar.

Dependendo das práticas de desenvolvimento da sua empresa, você pode interromper a varredura de um grande número de ramificações de código (supondo que muitas delas não estejam mais ativas) e desativar os repositórios para projetos concluídos / inativos até que sejam necessários. Minha empresa utiliza equipes muito pequenas em um grande número de projetos; portanto, na maioria das vezes trabalhamos principalmente trunk, tornando as filiais a exceção; portanto, adicionamos explicitamente ramificações para varredura em vez de incluir todas as ramificações por padrão. Verifique também se você não está digitalizando acidentalmente tags.

Como está o uso da CPU na caixa do Crisol? Se você estiver usando o SVN por trás do Apache HTTPD, examine quantas conexões são consumidas pelo Crucible durante uma grande varredura de repositório. Além disso, não sei ao certo o que mais você poderia ver (talvez a velocidade do disco? Frequência de verificação do repositório?), Mas espero que as dicas acima ajudem um pouco.

> 4 G de RAM não são hardware "incrivelmente poderoso". Supondo que você tenha 25 usuários e use o Fisheye (que você mencionou), estará gastando US $ 4400 apenas no software. US $ 4 mil na Dell poderiam comprar um servidor com 48G de RAM.

Além disso, você está usando uma JVM de 64 bits? Os documentos sugerem que você terá uma melhor pegada de memória (por exemplo, menos) em uma JVM de 32 bits.

Embora eu ainda não tenha tentado isso, estou tendo exatamente os mesmos sintomas que você.

Atualmente, estou pensando em desativar as informações de diff armazenadas para os repositórios incorretos. Fiz a pergunta no site de perguntas e respostas da Atlassian e recebi alguns conselhos promissores.

Meu problema é o mesmo - a indexação não é o problema, é uma enorme pegada de disco em execução em uma matriz de disco com desempenho insatisfatório em uma VM. Como não posso atualizar o disco no momento, preciso encontrar outra maneira de contorná-lo. O respondente no meu post acima diz que a remoção de informações diferenciais reduzirá a pegada de disco à custa de perder a capacidade de pesquisar linhas adicionadas / removidas . Embora ele também sugira que isso não afetará a velocidade de navegação em arquivos com históricos longos.

Se alguém vê isso e pode relatar sucesso / falha com essa opção, comente aqui.

Ah, e estou executando o 2.7.13 com os mesmos problemas de desempenho.