Essas opções irão influenciar diretamente na utilização de seu hardware e assim ter o ganho esperado. Note que algumas das configurações não estarão disponíveis devido ao modelo do hardware do servidor. Neste caso não temos o que fazer, pule para a próxima opção.
Alguns termos que utilizarei serão bem técnicos, mas para aqueles que não possuem interesse, basta realizar a configuração e reiniciar o servidor.
IMPORTANTE: Apesar dessas opções estarem esclarecidas pela própria Qlik, é sempre bom fazermos as alterações e verificar se realmente obtivemos ganho de performance, em caso contrário, volte as configurações originais de fábrica de sua BIOS.
Vamos as opções e depois irei explicar, tecnicamente, alguns conceitos:
Opção | Valor |
| Hyper-threading | Disabled ou OFF |
| Power Management (Power Plan) | Max performance/ High Performance |
| Node Interleaving | Enabled |
| NUMA Optimized | OFF |
| Turbo Boost | Enabled |
| Memory configuration / Hardware prefetch | Enabled |
Hyper-threading
O que é?
Hyper-Threading ou hiperprocessamento é uma tecnologia usada em processadores que o faz simular dois processadores tornando o sistema mais rápido quando se usa vários programas ao mesmo tempo. Essa técnica foi criada para oferecer maior eficiência na utilização dos recursos de execução do processador. Segundo a Intel, a Hyper-Threading oferece um aumento de desempenho de até 30% dependendo da configuração do sistema.
Mas porque isso seria ruim para o QlikView?
Dependendo do tamanho do cache L1, o Hyper-Threading simplesmente divide-o ao meio para fazer um único processador simular a utilização de 2. Se o L1 é muito pequeno, dividi-lo pode significar maior lentidão, pois as páginas de processamento dos processos de QlikView são muito grandes e não caberão nesse processo dentro do cache que o Hyper-Threading dividiu. Faltando espaço no cache L1, o processador começa a escrever esses processos na memória RAM e essa é a grande perda de performance que o QlikView sofrerá.
O efeito é semelhante a esgotar-se a memória RAM física disponível e o processador começar a fazer SWAP, ou seja, utilizar o disco físico para armazenar as informações que estão “sobrando”.
NUMA
O que é?
NUMA (Non-Uniform Memory Access)
A arquitetura tradicional para suportar servidores multiprocessados se chama SMP (Symmetric Multiprocessor). Neste modelo, apenas um processador tem acesso a memória num determinado momento. Quanto mais processadores são adicionados, mais sobrecarregado fica o barramento de acesso à memória, o que pode acabar sendo um fator limitante para a performance do servidor.
No sistema NUMA, as CPU’s estão organizadas em pequenos sistemas chamados de nodes. Cada node possui seu próprio conjunto de processadores e pool de memória e são conectados a um sistema maior através de um barramento de alta velocidade.
Mas porque isso seria ruim para o QlikView?
Em primeiro lugar o QlikView não é um software NUMA-aware, ou seja, não esta homologado para funcionar nesse sistema.
O QlikView é um software que se utiliza de MUITA memória, sabemos que se disponibilizarmos 128gb de ram ele vai consumir esses 128gb, pois foi assim que ele foi construído. No momento em que existe um mapeamento de cada núcleo para cada barramento de memória, corremos o risco desse barramento de memória não caber mais informação e é nesse momento que o QlikView perde sua performance, pois geram-se gargalos de mapeamento desse novo pedaço de memória, ou seja, precisa-se passar a informação para o atual dono desse espaço de que um outro “cara” precisa se utilizar dele – imagine você tendo que dar o seu terreno, pois o vizinho já ocupou toda a sua área rsrs.
O que a desativação NUMA faz é deixar toda a memória disponível, independentemente do número de núcleos e da quantidade de RAM instalado no sistema, de modo com que o QlikView possa se beneficiar de toda a memória sem saltar de um núcleo para o outro e evitar os gargalos.
Para as demais configurações a ativação não gerará nenhum tipo de queda de performance em seu ambiente QlikView Server.
