O funcionamento da política de propósito geral implementada por Voorsluys (Voorsluys, 2006) baseia-se em dar notas aos processadores através de resultados de benchmarks que são executados previamente em cada máquina a ser utilizada. Em uma segunda fase, adota-se um escalonamento baseando-se nas notas obtidas com os benchmarks. As simulações são executadas diversas vezes até obter-se um resultado com a margem de erro desejada. No trabalho de Voorsluys as simulações foram repetidas 15 (quinze) vezes.
Considerando o procedimento para obtenção de resultados confiáveis, descrito no parágrafo anterior, e o objetivo de implementar uma política específica para SD (Simulação Distribuída) que apresentasse um melhor desempenho que as tradicionais, optou-se por captar os dados da primeira execução da simulação e, baseando-se nas características observadas na primeira execução, substituir o escalonamento original. Dessa forma, os algoritmos de escalonamento a serem considerados nesta dissertação baseiam-se nas seguintes etapas:
I. Executar uma vez a simulação de um determinado modelo utilizando um algoritmo de escalonamento de propósito geral. Essa simulação será referenciada como simulação base.
III. Determinar novo escalonamento para os processos lógicos, baseando-se nos resultados coletados.
IV. Executar as repetições necessárias da simulação.
O maior desafio é encontrar quais características da simulação seriam coletadas no passo II e como cada uma seria utilizada para determinar o novo escalonamento no passo III. Os valores obtidos serão utilizados para definir a carga que deverá ser imposta a cada processador (isso é, número de processos lógicos) e assim fazer uma melhor distribuição da carga no sistema. Pretende-se no decorrer deste capítulo, apresentar algumas formas de como os dados obtidos de uma simulação base podem ser utilizados e avaliar a adequabilidade da forma de utilização proposta.
Para avaliar as propostas levantadas durante o estudo realizado foi utilizada a metodologia e as ferramentas apresentadas na seção 5.2.1. A seção 5.2.2 apresenta os estudos realizados e as justificativas para as métricas propostas. A apresentação da proposta final das duas políticas a serem avaliadas encontra-se na seção 5.3.
5.2.1
Metodologia para Avaliação das Políticas Propostas
O modelo sintético PHOLD, inserido no núcleo do simulador Warped por Voorsluys, serviu de base para a implementação das duas políticas utilizadas nos testes para esta dissertação. Depois de um estudo minucioso do núcleo do simulador Warped e do modelo PHOLD, optou-se por não fazer modificações no núcleo do simulador com o intuito de mantê-lo o mais próximo do utilizado por Voorsluys (Voorsluys, 2006), viabilizando a comparação das conclusões deste trabalho com as do trabalho anterior.
O Warped oferece 14 informações sobre a execução das simulações em arquivo, tais como:
- Tempo Total da Simulação;
- Quantidade de Eventos Processados;
- Quantidade de eventos desfeitos por rollback; - Quantidade de eventos consolidados (não desfeitos);
- Quantidade total de rollbacks;
- Quantidade de rollbacks primários e secundários;
- Tempo útil que foi gasto com processamento de eventos consolidados - Tempo gasto com rollbacks;
- Eventos processados por segundo;
- Eventos consolidados por segundo do tempo útil e total; - Tempo de espera por mensagens;
- Rollbacks causados por máquina.
Estes dados são suficientes para captar as informações necessárias, e calcular as novas notas de benchmark e depois através de um código em shell script fazer as 15 execuções do mesmo modelo com as novas cargas. Um modo conhecido de captar informações, fazer cálculos e manipular arquivos sem a necessidade de alterações no código do simulador, que é escrito em C++ e necessita de compilação, é a utilização de scripts. Assim optou-se pela utilização da linguagem de programação Python para implementação das políticas utilizadas neste trabalho.
Para otimizar a coleta das informações das 15 repetições foi criado outro script para coleta dos resultados e criar um arquivo já com as médias e desvios padrões referente a execução de um determinado modelo da simulação. Esse script identifica automaticamente a quantidade de repetições e faz os cálculos de forma automatizada. Desta forma todo ciclo de execução da simulação como: captação dos dados, cálculos das métricas, execução das políticas de escalonamento, balanceamento das cargas, captação de informação, tratamento das informações e armazenamento de todos os dados é feito automaticamente sem nenhum tipo de alteração no núcleo do simulador, garantindo que os dados são gerados pelo mesmo núcleo utilizado no trabalho de Voorsluys (Voorsluys, 2006).
5.2.2
Determinação da nova métrica
Nesta seção são apresentados o desenvolvimento e as justificativas para as métricas propostas nesta dissertação. Os resultados apresentados na figura 5.1 e que representam os dados obtidos da execução de uma simulação base serão utilizados em toda seção visando facilitar o entendimento. No desenvolvimento da métrica inicialmente, verificou-se quais dados podem ser captados do arquivo de respostas do simulador Warped (fig. 5.1).
Figura 5.1 Arquivo de respostas do simulador Warped.
Primeiramente, tem-se a necessidade de encontrar entre todos os processadores, o que obteve maior número de rollbacks. No arquivo de respostas, os dados referentes a cada processador são apresentados na frente do número correspondente ao nó do cluster. Como exemplo pode-se citar o resultado obtido em uma simulação base apresentado na figura 5.1. Nota-se que o processador 1 (P1) possui um total de rollbacks (TR) maior que os demais (173), podendo-se assim afirmar que P1 está executando mais rápido do que os demais processadores. Nos dados de P1 (fig. 5.1) depois do total de rollbacks tem-se na seqüência rollbacks primários e secundários que foram causados durante a simulação, na penúltima linha são apresentados dados sobre os tempos de simulação e na última linha os rollbacks causados em P1 por outros processadores. Para os cálculos da métrica, inicialmente interessa apenas o total de rollbacks e os rollbacks causados por outros processadores (RC).
Depois de determinado o processador que sofre o maior número de rollbacks (P1), deve-se procurar o processador que mais causou rollbacks em P1. No caso da figura 5.1, o processador 2 (P2) com 36 rollbacks causados (RC) em P1. Em seguida divide-se
TR RC e obtêm-se um valor que, considerando os valores apresentados, ou seja, 36 (RC) dividido por 173 (TR) tem-se 0,21. A proposta inicial é que esse valor seja adicionado a nota de P1 (do arquivo de notas de benchmark), tornando assim a carga dele maior e desacelerando a sua execução.Conseqüentemente, o TR de P1 deverá ser menor nas próximas execuções.
Executando-se alguns testes percebe-se que existiam modelos em que essa política inicial funciona bem e outros que os resultados ficavam muito ruins. Os piores resultados nesse caso são os modelos de rede, que após uma análise dos resultados e da métrica utilizada constata-se uma falha esclarecida a seguir.
Considerando-se que um modelo como o de rede possua um número pequeno no total de rollbacks, por exemplo: P1 produziu um TR igual a 3, e P2 produziu um RC igual a 2 em P1, utilizando a regra
TR
RC , tem-se um valor de 0,67 e esse valor é muito alto para ajustar pesos que vão até 1 (arquivo de notas de Benchmark). Ou seja, aumenta-se a carga de P1 em mais de 60%. Percebe-se assim uma grande desproporcionalidade no ajuste. Uma saída para sanar este problema é inverter os resultados, ou seja, subtrair 1 pelo valor alcançado. Desta forma, reduzem-se significativamente a influência. Entretanto, o ajuste continua alto para uma distribuição de cargas mais justa. Analisando esses resultados percebe-se a necessidade de fazer um controle dos valores de TR. Após diversos testes realizados, obtém-se um bom ajuste para TR inferiores a 100. Os ajustes são apresentados a seguir:
TR > 0 e TR <25 aplicam-se o valor 0,1 (1%) TR > 24 e TR <50 aplicam-se o valor 0,2 (2%) TR > 49 e TR <75 aplicam-se o valor 0,3 (3%)
TR > 74 aplica-se a regra de inversão do valor da métrica apresentada anteriormente
Encontrada a solução para o problema de valores pequenos de TR, o próximo ajuste na métrica surge com o intuito de melhorar o balanceamento, a idéia baseia-se em considerar, no cálculo, a quantidade de nós do cluster, podendo-se ajustar os pesos em todos os nós e não
somente no mais rápido. Dessa forma, considerando-se os dados apresentados na figura 5.1 o resultado do cálculo
TR
RC = 0,21, demonstrado anteriormente, deve ser dividido pelo número total de nós do cluster, neste caso são 3, assim calcula-se 0,21 dividido por 3 obtendo-se 0,07. Tendo-se este resultado, a redistribuição das cargas se apresenta da forma a seguir: soma-se a P1 (processador com maior número de TR) 0,07 em sua nota de benchmark e subtrai-se o mesmo valor dos demais processadores. Obtendo-se um melhor equilíbrio no balanceamento.
Após vários testes e ajustes, tem-se uma métrica que aplicada às duas novas políticas, apresentadas na seção 5.3, apresenta um escalonamento mais justo, obtendo-se assim, como resultados apresentados no capitulo 6, um melhor balanceamento das cargas e redução dos tempos de simulação.