Muita memória consumida durante a construção automatizada do TFS

Question

Estamos executando o TFS 2010 Standard Edition e configuramos uma versão automatizada para ser executada sempre que alguém fizer check-in no código. Nós executamos todos os testes automatizados (criados com o MSTest) como parte da compilação. Nós configuramos a compilação para executar os testes como um processo de 64 bits, mas o QTAgent.exe que executa os testes aumenta na memória enquanto os testes estão sendo executados. Atualmente, está atingindo 8 GB para os testes de ~ 650 que temos, e o processo diminuiu significativamente quando passamos de 450 testes para 650 testes.

Quando executamos todos os testes no ambiente de desenvolvimento local, a memória parece ser liberada pelo menos com cada TestClass e nunca excede um determinado nível. O processo de execução de todos os testes não aumentou significativamente no ambiente de desenvolvimento local.

Existe uma maneira de configurar o serviço de criação para liberar memória com cada teste ou cada TestClass? Com a maneira como as coisas estão sendo executadas, o processo de construção fica muito lento quando começamos a ficar sem memória na máquina.

Edit: Encontrei a chamada do MSTest no log de build e o executei manualmente e vi o mesmo comportamento da memória de fuga. Eu removi os parâmetros / publish, / publishbuild, / teamproject, / platform e / flavor da invocação do MSTest, caso o executor do teste estivesse mantendo os resultados até o final, mas o comportamento não mudou. Eu corri a mesma linha de comando em uma caixa de desenvolvimento, separada do servidor de compilação e a memória liberada com freqüência. Parece que deve haver algo errado / diferente sobre o servidor de compilação que está fazendo com que ele se comporte diferente, mas estou perplexo onde procurar.

Eu olhei para qtagent.exe.config, mstest.exe.config, versões de ambos os executáveis. O que mais pode afetar isso?

    

Answer 1

Eu finalmente encontrei a razão pela qual a memória estava sendo consumida tão rapidamente durante a construção automatizada. Criando um despejo de QTAgent.exe, pudemos examinar seu conteúdo para encontrar o que está no heap .NET. Acontece que estávamos colocando um grande número de objetos em um objeto de cache e, como o objeto de cache vive para todo o processo, todos esses objetos estavam sobrevivendo à coleta de lixo.

A lógica do programa em nossos testes gera alguns dados aleatórios e, em seguida, verifica se esses dados são exclusivos. Na maior parte, deveria ser, mas ocasionalmente há uma colisão. Se houver uma colisão, acabamos armazenando em cache os dados anteriores. Isso não deve ser um problema porque nossos testes limpam seus dados depois que eles são feitos e, portanto, o risco de colisão deve ser relativamente baixo.

Examinando o que temos no cache, descobrimos que deveríamos estar colidindo com muitas colisões, e descobrimos que nossa lógica de limpeza estava falhando apenas no ambiente de criação / teste automatizado, devido a algumas configurações incorretas dependências. Isso significa que toda vez que executamos nossos testes, geramos mais dados que não estavam sendo limpos, e as execuções subseqüentes correriam o risco de carregar esses dados no cache durante a execução do teste.

Eu reconheço que ter testes que não são completamente isolados fazia parte do nosso problema, mas eu gostaria de chamar algumas outras lições aprendidas:

• Não é verdade que o Agente de teste manterá os resultados dos testes de forma que a memória fique fora de controle quando a mesma coisa não estiver acontecendo ao chamar o MSTest do Visual Studio.
• É útil poder usar ferramentas como o WinDbg e a análise de dump para ver o que está na memória em seu processo.

Answer 2

Na verdade, o problema é causado pelo agente de teste mantendo os resultados de todos os testes para que ele possa atualizar o log no final. Minha recomendação seria passar dos testes do Visual Studio para outro agente de teste (como o NUnit).

Isso fará com que algumas dores de cabeça sejam transferidas, mas você deve acabar com uma solução mais limpa.