Atlassian Crucible muito lento em grandes repositórios

Question

Minha empresa tem feito um teste do Atlassian Crucible por 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. Navegar nesse repositório no Crucible é extremamente lento.

O cadinho está sendo executado em uma VM do CentOS. A VM tem 4 GB de RAM e eu defini o máximo do Crucible em 3 GB, dos quais ele está usando atualmente 2 GB. Eu trouxe isso em um ticket de suporte com Atlassian, e eles sugeriram o seguinte:

In particular because you have a rather large SVN repository you will likely find that Fisheye will be creating a large index file on disk. To help improve performance a few things you can try are:

• Increasing the available memory available to Fisheye.
• Migrating to an external database.
• Excluding files and directories from your index that aren't needed.

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

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

Obrigado!

Editar: Para esclarecer, uma vez que não mencionei explicitamente acima, eu sou usando o FishEye.

Editar 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. Assim, não acredito que seja uma questão de hardware, mas sim uma questão com ineficiência inerente ao Crucible. A Atlassian está ciente do problema e incluirá melhorias adicionais de desempenho em versões futuras, portanto, esperamos que essas mudanças solucionem nossos problemas.

Editar 3: Eu tinha esquecido há quanto tempo eu fiz essa pergunta, então na minha edição anterior eu deixei de mencionar que nossa situação de hardware também mudou desde que foi originalmente perguntada. 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 em RAID 1 com backup externo), mas vimos um pequeno aumento de desempenho quando nos afastamos da VM.

    

Answer 1

Como a migração para o MySQL fez uma diferença notável para alguns repositórios, considere ajustar o banco de dados para melhorias adicionais. Alterar alguns valores my.cnf dos padrões pode fazer uma enorme diferença. Veja InnoDB Performance Optimization Basics para mais informações. Além disso, verifique se há consultas lentas ativando o log de consultas lentas e adicione índices quando apropriado.

Meu próximo palpite seria a velocidade da rede: a sua instância do Crucible está na mesma rede local com fio que os seus repositórios SVN? Você também pode tentar dar à Crucible uma versão de teste na mesma máquina que seu repositório principal, se possível, para eliminar a latência da rede como responsável.

E sei que pode ser difícil dependendo do seu ambiente de trabalho, mas a execução do Crucible em uma VM provavelmente não está ajudando as coisas; A Atlassian toma nota disso na sua muito breve página Best Practices for Crucible Configuration . Tenho certeza de que você já se deparou com isso, mas também mencionarei a página Tuning FishEye para outros leitores.

Eu também tenho problemas de desempenho para grandes projetos, mas atribuo muito da lentidão à interface pesada da web do Crucible. Isso é especialmente verdadeiro depois de clicar um pouco (as páginas visualizadas anteriormente em uma revisão permanecem na janela do navegador, mesmo quando ocultas). Nossos desenvolvedores notaram um ligeiro aumento de velocidade mudando 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 por conta própria na última vez que usei (há muitos meses), mas poderia pelo menos manipular grandes conjuntos de arquivos sem desligar.

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

Como é 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 Crisol durante uma varredura de repositório grande. Além disso, não tenho certeza do que mais você poderia ver (talvez a velocidade do disco? Freqüência de varredura do repositório?), Mas espero que as dicas acima ajudem um pouco.

    

Answer 2

> 4 G de RAM não é um hardware "insanamente poderoso". Supondo que você tenha 25 usuários e esteja usando o Fisheye (que você mencionou), você está gastando $ 4400 apenas com o software. $ 4k 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ê verá uma melhor pegada de memória (como em menos) em uma JVM de 32 bits.

    

Answer 3

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

No momento, estou pensando em desativar as informações armazenadas do diff para os repositórios problemáticos. Eu fiz a pergunta sobre O site de perguntas e respostas da Atlassian e recebemos alguns conselhos promissores.

Meu problema é o mesmo - a indexação não é o problema, é uma grande quantidade de disco em execução em um array de disco com desempenho insatisfatório em uma VM. Desde que eu não posso atualizar o disco no momento, eu preciso encontrar outra maneira de contornar isso. O respondente na minha postagem acima diz que a remoção das informações do diff irá reduzir o tamanho do disco à custa de perder a capacidade de pesquisar linhas adicionadas / removidas . Embora ele também sugira que isso não afetará a velocidade de navegar por arquivos com históricos longos.

Se outra pessoa vir isto & pode reportar sucesso / falha com este switch, por favor comente aqui.

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