Uso dos Recursos Computacionais

De Qknow
Ir para: navegação, pesquisa

Introdução

Este artigo fornece informações úteis sobre as características de uso de memória e CPU pelos componentes principais das versões Server, que neste artigo estão concentrados no QlikView Server e Publisher. Os seguintes componentes são tipicamente encontrados em um projeto envolvendo o QlikView:

  • QlikView Developer: Trata-se da versão Desktop Edition (ou Personal Edition) utilizada para construção dos painéis (.QVW) que posteriormente serão acessados pelos usuários através de um navegador de internet como o Internet Explorer.
  • QlikView Server: É responsável pela publicação dos arquivos .QVW que representam os painéis criados. O QVS (QlikView Server) carrega as aplicações em memória e aloca os recursos computacionais necessários em tempo real.
  • QlikView Publisher: Componente que controla as re-cargas dos dados que serão utilizados nos painéis. É no Publisher que os agendamentos para cargas periódicas ocorrem, podendo gerar ou não arquivos do tipo .QVD.
  Nota: Tipicas fontes de dados para o Publisher são arquivos texto, bases de dados (OLEDB/ODBC), XML, XLS). Arquivos .QVW são considerados
        "aplicações" na terminologia do QlikView. Neste artigo, são também chamados de painéis.

O QlikView Server (QVS) e o QlikView Publisher são produtos separados que utilizam os recursos de memória e CPU de maneira bastante diferente entre eles. Por isso, é altamente recomendável que sejam configurados em equipamentos fisicamente separados. Os produtos QV Server e QV Publisher são usados como estrutura de retaguarda (Back-End) para os projetos envolvendo o QlikView. No que tange ao Front-End, o usuário interage com os painéis (também chamados de documentos de usuário) por meio do QlikView Desktop Edition ou pelo acesso via navegador Web. Os arquivos de Front-End são geralmente aqueles com extensão .QVW, .meta e/ou .shared.

Toda a comunicação entre o servidor QlikView Server e o cliente é tratado pelo próprio servidor, tanto via HTTP ou HTTPS, ao ser acessado pelo navegador WEB, quanto pelo protocolo nativo do QlikView (QV Protocol) ao ser acessado pela aplicação cliente (Desktop Edition, por exemplo). Desta maneira, é possível afirmar que o QlikView Server é o ator principal na alocação de recursos computacionais de memória e CPU para atender as requisições do usuário.

Gerenciamento de Memória

A memória RAM é o principal recurso de armazenagem de dados e interface que o serviço do QlikView Server Engine utiliza para atender as requisições dos usuários. Na memória, o QlikView armazena três tipos distintos de estruturas:

  1. Conjunto de dados não agregados (conhecidos como DataSet). Estas são as linhas que foram carregadas das diversas fontes de dados, tal como estão gravadas nos arquivos .QVW.
  2. Dados agregados, resultantes de operações dos usuários que navegam pela interface Web. Também chamados de Cached Result Sets.
  3. Estado da sessão de cada usuário. Ou seja, informações sobre o que o usuário está visualizando e suas ações sobre a interface que promovem novos cálculos.

Quando uma aplicação (QlikView Document) é acessada pelo usuário pela primeira vez, o servidor QlikView se encarrega de carregar toda a estrutura em memória (se já não tiver feito fruto de opções do QMC). Uma única cópia dos dados em memória é capaz de atender todas as requisições de diversos usuários diferentes. Quando uma ação é realizada pela Web, o QlikView se encarrega de calcular os dados necessários para apresentação dos elementos gráficos, armazenando no Cached Result Sets os dados recém calculados.

O processo de associação em memória permite que o QlikView analise e processe os dados de maneira extremamente rápida. Para isso, entradas únicas (registros únicos) são armazenados na memória do servidor. Todo o restante é apontamento para dados considerados interligados, ou parentes. Este é o motivo pelo qual o QlikView é tão compacto e rápido na camada de apresentação, diferente do que ocorre com CUBOS tradicionais.

Diferente de um modelo tradicional de BI onde dados pré-agregados são carregados de maneira não normalizada com vias a ganho de desempenho, o QlikView pode manter os dados no maior nível de detalhes calculando todas as informações de maneira instantânea (ad-hoc) durante as interações dos usuários. É o QVS (QlikView Server Process) responsável pela alocação da maior parte da memória destinada as operações do QlikView.

Três componentes principais consomem a memória do servidor em momentos ligeiramente diferentes. São eles:

  • Cached Result Sets: Como mencionado, o cache de resultados é preenchido com os dados calculados das interações dos usuários com os painéis. O consumo de memória destinado a este cache será limitado pelo parâmetro Working Set-Min (visto a seguir neste artigo).
  • Session State: Os dados de cada conexão de usuário são mantidos separadamente, aumentando o consumo de memória em até 10% do total utilizado por determinada aplicação para cada novo usuário. Esta memória é liberada assim que o usuário desconecta, o que não ocorre com o Cached Result Sets.
  • Application Memory: Memória utilizada pela aplicação QlikView e deve manter-se constante enquanto a aplicação permanece disponível. Quando a aplicação não for mais necessária, o resultado é a liberação da memória correspondente.

Memory Use 0.PNG


A figura acima demonstra o uso de memória de um servidor QlikView ao longo do tempo. No primeiro instante não há nada carregado pois nenhum usuário fez qualquer conexão ao servidor. Porém, em um determinado momento do tempo, o primeiro usuário faz uma requisição, o que instrui o servidor a carregar a aplicação em memória. Neste instante o consumo sobe mas permanece estável até que o usuário inicia suas interações filtrando e agregando valores. Neste momento, o consumo de memória sobe devido ao Cached Result Set que armazena os cálculos recentemente realizados para uso posterior. O processo do QlikView no sistema operacional Windows não fará nenhum esforço para reduzir a memória até que o parâmetro Working Set-Min seja alcançado.

Ainda na figura anterior, é possível notar que alguma memória foi necessária para controle do estado da conexão do usuário (em verde), mas o valor é irrisório se comparado com os demais processos em execução. Ao alcançar o limite mínimo o servidor interrompe a alocação de memória para o Cached Result Set e inicia um procedimento de despejo a partir de cálculos de frequência de uso e horário do último acesso ao dado previamente calculado. Com base em algorítimos internos, o QlikView libera a memória para substituir por dados recém calculados.

  Nota: Este é o motivo da memória do Desktop (e também do servidor) não reduzir o consumo quando uma aplicação é fechada. Somente encerrando o QlikView Desktop
        a memória alocada para o Cached Result Set será liberada.

Em um outro cenário (figura a seguir) é possível notar um maior número de aplicações sendo carregada para a memória (bloco cinza do gráfico). Devido aos limites estabelecidos pelo parâmetro Working Set-Min, o total de memória disponível para o Cached Result Set começa a ser despejado, renovando mais rapidamente os dados entre os valores não agregados e agregados. Esta intensa batalha pode ser prejudicial ao desempenho do servidor.

Memory Use.PNG


Neste cenário, quanto mais aplicações são carregadas (ao menos três), menos memória estará disponível para os resultados previamente agregados. Com isso, mais intenso será o nível de processamento do servidor. Na medida em que as aplicações são descarregadas, a memória é liberada e o QlikView permanece apenas com os valores agregados para futuras requisições. Neste cenário, é possível considerar que há falta de recursos (memória) para o servidor manter em cache os dados previamente calculados.

Num cenário adequado, é possível constatar que a variação de alocação de memória do servidor pelo processo do QlikView (QVS.EXE) é regular, não oscilando em picos. Ou seja, uma vez atingido o total disponível, poucas são as trocas de informações entre os valores não agregados e o Cached Result Set. No entanto, caso seja observado que a variação entre os valores superiores e inferiores é demasiadamente grande (picos e vales), há um forte sinal de que o sistema de memória é insuficiente para acomodar os dados agregados, tanto pela ausência em si de memória RAM quanto pela possibilidade do parâmetro Working Set-Min estar inadequadamente configurado.

Memory Consumption.PNG


Configurando o Uso da Memória

Dois parâmetros são utilizados para gerenciar o consumo de memória na plataforma QlikView e podem ser ajustados tanto para a versão Desktop quanto para o servidor. Working Set-Min e Working Set-Max determinam o consumo de memória de acordo com as informações da seção anterior. Enquanto Working Set-Min estabelece o limite de uso da memória para o Cached Result Set, Dados Não Agregados (DataSet) e Session User, o parâmetro Working Set-Max determina o limite máximo em que o consumo de memória RAM será dedicado ao processo do QVS.

É importante notar que no ambiente Windows o sistema de gerenciamento de memória virtualiza o endereçamento para as aplicações e, com isso, o limite físico de memória RAM pode ser ultrapassado pelo sistema de alocação de memória virtualizado. Ou seja, assumindo um equipamento com 64GB de memória RAM, é possível afirmar que o Windows ultrapassará esse limite para atender as requisições de memória dos softwares instalados no sistema operacional, uma vez que a memória é o somatório dos recursos de RAM e arquivo de troca (swap). Por isso, o parâmetro Working Set-Max é especialmente importante, pois informa ao sistema operacional que dê preferência de atendimento ao processo do QVS.EXE a partir da memória RAM e não do arquivo de swap que compõe a memória virtual.

Desta maneira, quando houver um esgotamento de memória do sistema operacional, outros processos serão transferidos da memória para o sistema de disco em forma de arquivo de troca (swap), enquanto o QVS.EXE será priorizado com atendimento via memória RAM. Ainda assim, não há qualquer garantia de que a memória RAM seja efetivamente a utilizada pelo processo, pois um intenso consumo de recursos pode forçar o ambiente Windows a encaminhar parte dos dados de memória RAM para o sistema de virtualização de memória (swap), o que inclui o próprio processo do QlikView.

Ajuste de Memória no QlikView Desktop


O ajuste de consumo de memória no Desktop (Personal Edition ou Desktop Licenciado) ocorre como uma preferência de usuário através do menu Ferramentas, acessando o item Preferências do Usuário. Ao ser exibida a janela de configuração das preferências do usuário, a guia Geral deve ser selecionada, apresentando as opções de Limite de Working Set (%) conforme figura a seguir.

Working Set Desktop.png


  Nota: Alterar os parâmetros de Working Set Min/Max instrui o sistema operacional no atendimento as requisições de memória RAM sem utilização do arquivo
        de swap (troca). Porém, isso não significa que o QlikView não será atendido pelo sistema de swap se o recurso de memória se tornar escasso. 

O parâmetro Cache indica o percentual de memória que será destinado ao Cached Result Set para armazenar os resultados das operações (expressões) durante a navegação do usuário nos painéis. Este valor representa o limite que o Cache poderá usar de memória RAM antes de ser conduzido ao sistema de memória virtual do Windows.

Ajuste de Memória no QlikView Server


O ajuste a que se refere esta configuração aplica-se aos servidores do tipo Enterprise, Small Business, Extranet e IAS, configurável a partir do QMC. Os valores disponíveis para ajuste do Working Set são Low (baixo) e Hight (alto), onde Low representa o Working Set-Min e Hight responde pelo Working Set-Max. O valor do parâmetro Hight deve sempre ser maior do que o valor de Low. Adicionalmente, a diferença entre o valor percentual de High e o total equivalente a 100% será a reserva destinada ao sistema operacional Windows. Por exemplo, em um equipamento com 128GB de memória, a configuração de Working Set-Max (High) em 90 indica que 12,8GB de memória serão destinados ao sistema operacional (diferença entre 90% e 100%).

1. No servidor onde o QlikView Server está instalado, abra o QlikView Management Console.

2. Na guia SYSTEM, escolha SETUP.

3. Escolha o servidor para o qual deseja realizar a mudança dentro de QlikView Servers.

4. No painel a direita, escolha a guia PERFORMANCE.

5. Sob o item WORKING SET, defina o parâmetro LOW para a quantidade de memória RAM que deverá estar disponível ao QVS.

Working Set Server.png

Carregar grandes volumes de dados em um equipamento que não disponha dos recursos de memória RAM suficientes pode forçar o sistema operacional a realizar o processo de swap movendo parte da memória RAM do QlikView (QVS.EXE) da memória física para o arquivo de troca. Como resultado, o QlikView responderá de maneira essencialmente lenta, causando uma impressão aos usuários finais de que algum erro ocorreu. Por isso, dimensionar o tamanho da memória para as necessidades da companhia é uma atividade primordial em qualquer deploy de projetos em QlikView.

  Nota: Lembre-se! Configurar os parâmetros de Working Set-Min e Max não significa que em caso de escassez total de memória o processo do QVS.EXE
        não será movido para o arquivo de swap. Esta é uma condição oriunda do sistema de gerenciamento de memória do Windows Server.

Considerações Finais do Uso de Memória

Quando um equipamento opera com baixos níveis de memória RAM disponíveis, o sistema operacional atende os processos e serviços por meio da memória virtual. Ou seja, parte dos aplicativos em memória são despejados para o arquivo de SWAP, enquanto a RAM é liberada para outros serviços que a estão exigindo no momento. Essa operação compromete negativamente o desempenho do processo QVS.EXE. Algumas considerações finais:

  • O QlikView Server utilizará toda a memória disponível para uso do Cached Result Set. Um alto consumo de memória do QlikView sem que haja uso do arquivo de troca (swap) é um bom sinal, já que indica um grande volume de dados disponíveis no Cached Result Set.
  • O QlikView armazena somente valores distintos em memória, o que faz com que a compressão seja possível. Para as demais instâncias, é gravado junto aos dados as referências posicionais de cada registro. Desta forma, a taxa de compressão é maior para registros duplicados e menor para registros únicos.
  • A liberação da memória só ocorrerá quando o QlikView Document for descarregado. Neste momento, a memória utilizada pelas seções dos usuários e o pelo próprio painel será liberada. No entanto, a memória alocada para o Cached Result Set permanecerá alocada, uma vez que não existe nenhum motivo para liberá-la já que no futuro os cálculos já realizados podem ser novamente necessários.
  • Quando o valor de Working Set-Min é alcançado, valores antigos e pouco acessados das interações dos usuários são removidos da memória. Logo, ocorre um processo de troca entre os valores não agregados (Result Set) e agregados (Cached Result Set).

Gerenciamento de CPU

No QlikView Server, o uso de CPU é maximizado para atender as operações de dril-down, agregações e filtros realizados pelo usuário. Deste modo, toda a capacidade computacional disponível para o QVS é alocada para atender a tais requisições. Dentro de parâmetros normais, os processadores (físicos ou cores) devem apresentar comportamento de picos e baixas repetidamente, como no gráfico a seguir:

QVS - CPU Usage - v1 0.png

Para manter baixos níveis de uso de CPU, o QlikView utiliza-se de um cache de funções. Logo, cálculos em objetos só necessitam ser realizados uma única vez, sendo hospedado no cache para consultas posteriores. Esse mecanismo reduz o consumo de CPU e eleva a velocidade com que o usuário é capaz de visualizar as informações.

Todo o dado armazenado pelo QlikView é essencialmente hospedado em memória RAM. As operações de agregação são realizadas sobre os dados não agrupados. Ou seja, os dados em memória são armazenados de maneira não agregada. Quando o usuário faz uma seleção, um dril-down ou outra operação que requer a consolidação de dados, esse trabalho é realizado dinamicamente em tempo real. E isso requer o consumo de CPU para atender os diferentes pedidos de agrupamento, filtros e afins.

Quando a capacidade de processamento não é suficiente, o efeito colateral é rapidamente observado na apresentação dos dados em forma de gráficos. Tipicamente, o QVS é capaz de apresentar as informações necessárias aos gráficos em frações de um segundo. Quando o usuário aguarda por mais de um segundo para visualizar os dados selecionados, é um indicativo forte de falta de capacidade de processamento.

  Nota: A resolução de problemas de desempenho por falta de capacidade computacional (CPU) é resolvida, em linhas
        gerais, pela adição linear de capacidade de processamento. Isso não significa que outros pontos da aplicação
        não necessitem de atenção. Pelo contrário, para grandes volumes de dados, é essencial que todos os componentes
        estejam adequadamente otimizados, o que inclui a Memória, CPU, Sistema Operacional e, principalmente, a
        arquitetura do projeto em termos de associações e componentes visuais.

O consumo de CPU no QlikView é considerado linear porque, em média, ao adicionar um novo processador (ou core) o tempo para determinada operação é distribuído igualitariamente para o novo recurso. Por exemplo, se em uma arquitetura onde há um único processador o tempo de dril-down for de 2 segundos, ao adicionar um novo processador (considerando mesma velocidade), o tempo cairá linearmente pela metade.

  Obs.: Embora o consumo de CPU seja linear (igualitário em todos os processadores), a adição do dobro da capacidade atual
        de processamento de um determinado equipamento deverá, em linhas gerais, reduzir o tempo das operações pela metade.
        No entanto, existem pequenas variações para mais ou para menos como resultado desta adição, não se configurando um
        número absolutamente imutável.

Ao carregar um novo painel para a memória, o QlikView não executa os cálculos de todos os valores possíveis para cada gráfico sem que haja uma interação mínima do usuário (a não ser para os valores inicialmente apresentados). Os cálculos executados em cada filtro, seleção, pesquisa, etc. são automaticamente realizados de maneira instantânea (ad-hoc) e armazenados no Cached Result Set. Uma aplicação tipicamente bem desenhada será aquela que fará com que o QlikView execute um processo de consumo alto, mas pontual. Ao contrário de aplicações com problemas de arquitetura que utilizarão o processador de maneira constante acima de 70% da capacidade.

Configurando o Uso de CPU

Em equipamentos com múltiplos processadores ou núcleos de processamento, o QlikView utilizará de várias unidades de trabalho individuais conhecidas como Threads para responder de maneira mais rápida as interações dos usuários com os painéis. Desta forma, múltiplas threads são abertas nos diversos processadores (ou núcleos) simultaneamente, de maneira a responder por uma única interação o mais rápido possível.

Servidores dedicados ao QlikView podem e devem fazer uso de toda a capacidade operacional das CPUs disponíveis, visando atender ao usuário o mais rapidamente. Porém, em ambientes mistos, onde múltiplos sistemas ou produtos são executados juntamente com o QlikView, é possível que um alto consumo de CPU pelo QVS.EXE possa implicar em redução de desempenho em outros sistemas/softwares, como banco de dados e sistemas Web (IIS, por exemplo).

Para determinar o consumo máximo que o processo do servidor QlikView pode alcançar, é possível alterar as propriedades da guia PERFORMANCE dentro das opções de SYSTEMSETUP no QMC (QlikView Management Console). Dois grupos de configurações estão disponíveis, sendo um para determinar em quais processadores o QlikView pode atuar (ou núcleos) e o nível máximo de consumo das CPUs destinadas ao QVS.EXE.

1. No servidor onde o QlikView Server está instalado, abra o QlikView Management Console.

2. Na guia SYSTEM, escolha SETUP.

3. Escolha o servidor para o qual deseja realizar a mudança dentro de QlikView Servers.

4. No painel a direita, escolha a guia PERFORMANCE.

5. Sob o item CPU, defina em quais processadores o QVS.EXE será executado e o limite máximo que poderá utilizar.

CPU Throuttle.png

  Nota: A critério do sistema operacional Windows Server, o limite de CPU pode ser ultrapassado se recursos estiverem disponíveis. Ou seja, mesmo
        restringindo o limite máximo de CPU, se houver capacidade ociosa (disponível) o sistema operacional poderá alocar este recurso extra para atender
        as requisições do QlikView.


Assuntos Relacionados


Envelope01.jpg
Procurando Algo? Fale Conosco!

Voltar | Página Principal | Topo