O Solr 4.5 usa muita memória em consultas consequentes, o GC executa o tempo limite

Question

Existe um índice no Solr 4.5 que contém ~ 50K documentos levando ~ 4Gb no disco. A RAM física disponível para a JVM é de 6 Gb (de um total de 10 Gb no servidor), o SO é de 64 bits do CentOS 5.

Uma das consultas de aplicativos que indexam várias vezes em um loop, uma solicitação enviada assim que a anterior é concluída, praticamente sem atraso entre, mas ainda não simultaneamente.

As consultas são todas iguais e se ajustam ao seguinte padrão simples:

• q = description: "keyword" OR pedidos: "keyword" OR catalog: "keyword"
• fl = id, pontuação, nome, país
• sort = pontuação desc
• wt = json
• indent = true
• start = 0
• linhas = 100

(todos os campos em q são textos com tokens indexados)

Após um número relativamente pequeno de tais consultas (às vezes após o terceiro, às vezes após o quinto etc.), o coletor de lixo recebido no lado do Solr entra em ação porque toda a memória está ocupada. Isso resulta em vários segundos de atraso antes que o Solr responda, o que faz com que o aplicativo envie a solicitação para abortar no tempo limite.

Se o aplicativo aguardar entre as consultas subsequentes em envios por aproximadamente 1 segundo, todos eles serão concluídos rapidamente e a RAM não será excedida; mas quanto mais rápido as consultas são enviadas uma após a outra, quanto maiores são as alterações, a próxima resultaria em um GC acionado e um tempo limite indesejado.

O mesmo índice (construído a partir dos mesmos dados pelo mesmo aplicativo) é absolutamente bom com o mesmo padrão de uso na versão mais antiga do Solr (1.4).

Aumentar os tamanhos de cache em solrconfig.xml não parece ter muito efeito, mas reduzir o parâmetro rows para 10 de 100 torna o tempo limite menos provável, embora não inteiramente impossível. queryResultWindowSize na configuração está definido como padrão 20.

Eu acho que pode haver mais de um motivo para o comportamento observado e eu não dei detalhes suficientes. Se sim, o que preciso alterar ou criar um perfil para reduzi-lo daqui?

    

Answer 1

Esta é a natureza do Java: Coleta de lixo significa que o mundo inteiro para.

As soluções aceitas que conheço são geralmente ruins:

1. Adicione mais RAM (para que você possa fazer mais consultas antes que a pressão da memória force um GC automático);
2. Adicione mais servidores (para distribuir a carga); ou
3. Incentive manualmente o GC a ser executado com mais frequência (por isso, ele tem menos a fazer e é concluído mais rapidamente )

Como você só começou a ter problemas após atualizar para uma nova versão do Solr, talvez queira verificar suas listas de e-mail e no rastreador de problemas para ver se esse é um problema conhecido resolvido em uma versão posterior.
Se você quiser criar um perfil e depurar o aplicativo em si que realmente seria mais uma pergunta sobre estouro de pilha - é possível que você esteja solróide em algo subóptimo (em sua consulta ou no aplicativo) que está causando mais RAM do que precisa.

    

Answer 2

Yuriy, eu trabalho na Azul Systems. Colocamos nossa máquina virtual Zing no ritmo do Lucene em um teste de benchmark no ano passado. O resumo da solução que criamos mostra as estatísticas de latência representativas no gráfico na página dois: link .

O coletor de lixo Zing "C4" é diferente dos que estão no Hotspot. Coleta de lixo sob Zing significa que o mundo inteiro não para. Em vez disso, os threads do mutador Java continuam, com as operações do GC em execução simultaneamente em paralelo, normalmente em núcleos separados. Não há como parar o modo mundo no Zing, seja nas táticas primárias do GC ou como um fallback, tanto nos novos quanto nos antigos colecionadores da geração.

Não posso dizer que vimos o Solr 4.5 como um culpado em particular. Se tiver certeza de que o Solr ou o seu aplicativo não tem um bug e você ainda tem pausas no GC após a triagem, considere consultar o Zing: link

Os comentários de Voretaq7 sobre alternativas sendo péssimas não devem ter incluído C4 ou Zing. Pelo menos eu espero que sim.

Boa sorte.

Matt