Não é possível aumentar a quantidade de memória para o SOLR.

[jamilatta]

Descrição do problema

Em diversar tentativas para atualizar o espaço de memória para a máquina virtual do java a versão 5.5.5 do Solr não respeita os parâmetros de configuração.

Passos para reproduzir o problema

Adicionar os parametros de variável de ambiente no arquivo docker-compose-dev.yml

        environment:
            - SOLR_HEAP=1024m
            - SOLR_JAVA_MEM="-Xms1024m -Xmx1024m"

Repare que ao acessar o admin do solr via http://localhost:8983 no dashboard não é possível ver essa alteração.

Comportamento esperado

Esperamos que a quantidade de memória fosse alterada para o valor configurado.

Screenshots ou vídeos

Em convesa com a equipe decidimos que iremos atualizar a versão do Solr para a versão 8.5.1.

[jamilatta]

@scieloorg/scielo-ps-developers

Ambiente de homologação atualizado para a versão 8.5.1 do Solr.

Pendente a atualização na versão no ambiente de produção.

[jamilatta]

Após a atualização do indexador com as citações.... mais de 20 milhões de registros, observamos uma lentidão nas requisições, vai alguns números de tempo:

Tempo de query time para *:* no ambiente de homologação: 8193 milisegundos Tempo de query time para *:* no ambiente de produção: 213 milisegundos (Sem as citações e ~800k de registros)

Em análise verifiquei que a maior parte do tempo acontece por conta das "facet" em modo debug no admin do Solr realizei os seguintes observações:

Nessa imagem é possível verificar que o tempo para processamento das "facet" é ~90% do tempo gasto para requisição.

Realizando a remoção das "facet" verifiamos que o tempo de QTime(Query Time) do solr tende a 0.

Pesquisando sobre os parâmetros disponíveis @rafaelpezzuto e eu encontramos uma opção de colocar as "facet" com threads.

Nesse link é possível verificar esse parâmetro: https://lucene.apache.org/solr/guide/6_6/faceting.html#Faceting-Thefacet.threadsParameter

Independente dos ajustes realizados é necessário mais recurso de processadores para que o tempo de QTime diminua.

Rodando em um host com 2 processadores e 4GB de memória obtivemos o seguinte tempo:

Tempo de query time para *:* = 2393 milisegundos

Com as seguintes parâmetro padrão nas requisições enviadas para o indexador:

    <lst name="defaults">
       <str name="echoParams">explicit</str>
       <int name="rows">10</int>
       <str name="df">tw</str>
       <str name="q.op">AND</str>
       <str name="defType">edismax</str>
       <str name="facet.threads">12</str>
    </lst>

Rodando em um host com 12 processadores e 2GB de memória obtivemos o seguinte tempo:

Tempo de query time para *:* = 600 milisegundos e 700 milisegundos

Outra configurações que deve ser realizada no Java seria a especificação do Gargabe Collector e configuração de tamanho de pages dos processos em Java, vejam as alterações necessárias:

-XX:+AggressiveOpts
-XX:+AlwaysPreTouch
-XX:+ParallelRefProcEnabled
-XX:+PerfDisableSharedMem
-XX:+UseG1GC
-XX:+UseLargePages
-XX:G1HeapRegionSize=64m
-XX:InitiatingHeapOccupancyPercent=75
-XX:MaxGCPauseMillis=250

Para melhorar ainda mais o tempo das pesquisas, foi realizado ajustes nos parâmetro de filter cache cache de filtros por pesquisa:

Vejam:

    <filterCache class="solr.FastLRUCache"
                 size="1024"
                 initialSize="1024"
                 autowarmCount="0"/>

    <queryResultCache class="solr.LRUCache"
                      size="1024"
                      initialSize="1024"
                      autowarmCount="0"/>

    <documentCache class="solr.LRUCache"
                   size="1024"
                   initialSize="1024"
                   autowarmCount="0"
                   maxRamMB="2000"/>

    <cache name="perSegFilter"
           class="solr.search.LRUCache"
           size="10"
           initialSize="0"
           autowarmCount="10"
           regenerator="solr.NoOpRegenerator" />

Esses ajustes estão no commit: https://github.com/scieloorg/search-journals/pull/510/commits/3a58cfdfa05840511b886fa80b77a313b8662094

Links úteis para que possamos otimizar o tempo de resposta do Solr: https://cwiki.apache.org/confluence/display/SOLR/SolrPerformanceFactors

As recomendações de hardware para o Solr: https://cwiki.apache.org/confluence/display/lucene/ImproveSearchingSpeed

Apresentação do Senior Software Engineer at Netflix na Unicode Conference sobre os desafios de multi-idiomas: https://www.unicodeconference.org/presentations/S11T3-Provalov.pdf LinkedIn: https://www.linkedin.com/in/provalov/

[gustavofonseca]

Excelente @jamilatta 👍

[jamilatta]

Realizado as configurações em ambiente de homologação, a equipe de infraestrutura aumentou para 12 vcpus.

É possível ver o resultado em http://homolog.solr.scielo.org

Image:

Mesmo com essas alterações nosso tempo de pesquisa para o indexador vária entre 1.2 à 1.5 segundos.

Conversando com o @rondinelisaad esparamos nos limites da escala vertical, 12 vcpus, 8GB(max) e HDs não SSD com ponto de montagem.

Conversando com ele me passou a possibilidade de criarmos um cluster de pelo menos 2 máquinas, para que possamos crescer horizontalmente!

@gustavofonseca e @rafaelpezzuto o que acham?

[gustavofonseca]

Conversando com ele me passou a possibilidade de criarmos um cluster de pelo menos 2 máquinas, para que possamos crescer horizontalmente!

Para mim não está claro como esta medida resolveria o problema. De qual maneira um cluster resolveria o problema do tempo gasto para a agregação das facets?

[jamilatta]

@gustavofonseca essa foi uma sugestão da infraestrutura.

A idéia é investirmos para termos essa resposta.

Estou estudando sobre isso, mas sem a exatidão de que irá resolver.

[gustavofonseca]

Se não há qualquer justificativa técnica razoável, então eu não sou favorável a ir por este caminho, haja vista que estaríamos aumentando radicalmente a complexidade operacional desta aplicação apenas porque sim, algo muito semelhante com o que já foi feito em instalações do MongoDB ao decidir pelo uso de sharding.

[jamilatta]

@gustavofonseca

Concordo estou verificando com a infraestrutura se há mais alguma ação que podemos realizar para evitar utilizar algo com maior complexidade.

[rafaelpezzuto]

@jamilatta o tempo de acesso melhorou bastante, mas como você disse, ainda é insuficiente para ser aceitável.

Um dos caminhos pode ser procurar por métodos mais eficazes de faceting. Algo adicional é melhorar alguns campos do schema Solr, por exemplo:

Um dos agrupamentos (cited_journal_title) contém muitos valores distintos e por isso é o que mais demora para ser obtido. Esse agrupamento ainda será alterado para algo como "official_cited_journal_title + ISSN-L" de modo a reduzir o número de valores distintos.

[jamilatta]

@rafaelpezzuto

Supeito que ajude sim! Estou com a infraestrutura realizando alguns ajustes de aumentado de IO no volume para melhorar as leituras!

[rafaelpezzuto]

_@jamilatta

Estou consultando este documento. Vi que de fato este problema de lentidão para retornar facets é conhecido. Uma solução parece ser o uso de docValues. Veja o que é descrito:

Mas vi que o nosso schema já está usando docValues=true para string. Uma alternativa é forçar um segundo tipo que obrigue a carga de campos específicos na memória:

Vou fazer alguns testes aqui tbm - não custa nada deixar rodando aqui.

[jamilatta]

@rafaelpezzuto estou lendo sobre!