Performance e Escalabilidade – Processos e prioridades

Introdução

Desde os tempos neolíticos da Informática, as técnicas de optimização, os “mandamentos” e boas práticas continuam as mesmas, com pequenas variações. Levando em conta que qualquer ambiente computacional, não importa seu tamanho, possui capacidade finita de recursos, e em cada post sobre este assunto descemos (ou subimos) um degrau, podemos nos aprofundar um pouco mais nos processos do sistema.

Conceito

Antes de mais nada, vamos conceituar um processo: Cada programa em execução pode ser chamado de “processo”, e basicamente nós temos 2 tipos de processos: Interativos (processos com interface, síncrona ou assíncrona), e processos batch (sem interface visual), como WebServices, Jobs e Schedulers.

Priorizando

Nem sempre você terá recursos computacionais para rodar todos os processos ao mesmo tempo, isto pode fatalmente acontecer em um momento de pico. E, neste caso, você têm que “se virar” com os recursos disponíveis. Se todos os processos possuem a mesma prioridade para o sistema operacional, quando a soma de processos em execução bater 100% do consumo de CPU, todos os processos em execução entram na mesma fila de prioridade para usar uma fatia de tempo do processador. Logo, todos os processos vão ficar lentos, dividindo recursos computacionais.

Quando definimos prioridades diferentes para os processos em um servidor, quando houver mais processos brigando por processamento do que CPUs disponiveis, os processos de menor prioridade serão mais interrompidos e terão fatias de tempo menores do que os processos de maior prioridade, e sendo assim, apenas os processos de menor prioridade serão penalizados, e consequentemente os processos de prioridade maior vão continuar rodando com o mesmo desempenho. Você apenas vai sentir que o sistema está se “arrastando” quando não houver CPU o bastante para os processos de prioridade mais elevada, e neste caso não têm como fugir, eles vão ficar mais lentos.

Quem deve ser priorizado

Normalmente são deixados com menor prioridade os processos em batch e scheduler, que costumam têm alto consumo de CPU, mas que podem ser sacrificados com um maior número de interrupções que os demais, ficando obviamente mais lentos. Um resultado de uma consulta de pendência financeira on-line ou verificação de status para liberação de crédito é mais importante, ainda mais se este procedimento está sendo executado por um operador de caixa, com o cliente e um carrinho de compras cheio de itens na frente dele. Caso este processo fique mais lento, o operador de caixa têm que dar um “veja bem” no cliente, perguntar o resultado do último jogo de algum campeonato de futebol, se ele sabe a previsão do tempo para amanhã, se ele encontrou na loja tudo o que ele precisava, … , e depois de alguns segundos de um silêncio constrangedor, se mesmo assim o sistema ainda não tiver terminado, ele vai ter que pedir desculpas ao cliente e dizer que “o sistema está lento”.

Mexendo na prioridade de processos

Normalmente, os sistemas operacionais de mercado oferecem mecanismos para alterarmos a prioridade de um processo de uma aplicação em execução. Em uma aplicação multi-thread, ao mexer na prioridade do processo principal, consequentemente todas as threads deste processo serão afetadas.

Ao mexer na prioridade de processos, não recomendo nunca subir a prioridade para algo acima de “normal”, mas sempre diminuir a prioridade dos processos que podem ser penalizados em caso de sobrecarga. Ao elevar a prioridade de um ou mais processos, caso estes se tornem ávidos consumidores de CPU, os processos de prioridade menor serão severamente penalizados, e isto pode inclusive levar o equipamento a um estado de indisponibilidade (igh, o servidor travou).

Fugindo da afinidade

Um dos princípios de escalabilidade e performance mencionava algo sobre o estabelecimento de afinidade. A partir do momento que você elege um servidor apartado para rodar um tipo de tarefa, se este servidor der problema, você terá dois problemas. Normalmente acaba sendo utilizado algum tipo de segregação de processos em equipamentos específicos para processos pesados, que ao serem executados, “sugam” o que podem do servidor onde estão sendo executados, tornando a execução de outros processos no mesmo impraticável, e isto acontece apenas em alguns períodos do dia.

Usando a priorização de processos, podemos colocar estes processos pesados em mais de um equipamento, e diminuindo a prioridade destes processos, eles podem conviver na mesma máquina sem prejudicar os processos de maior prioridade. Para receber processos de menor prioridade, um determinado servidor precisa ter uma “folga” de CPU, a máquina não pode estar trabalhando “no talo”, caso contrário os processos de menor prioridade não vão ser executados.

Aplicando este conceito

Os experimentos com esta funcionalidade ainda estão em andamento, inicialmente em ambientes Windows. Na prática, um equipamento bem utilizado é aquele onde realmente usamos tudo o que a máquina têm a oferecer de recursos, porém dentro de um limite de enfileiramento em que os tempos de processamento e retorno fiquem dentro de um patamar aceitável, e tomando cuidado para não deixar os recursos se esgotarem.

Pensando neste cenário, podemos colocar serviços de prioridade “normal” com afinidade por core da maquina, e serviços de menor prioridade com afinidade para um ou múltiplos cores da maquina, e deixamos um core fora das regras de afinidades dos serviços, para uso livre do sistema operacional.

Deste modo, mesmo que todos os processos de todos os serviços entrem em um pico de consumo de CPU, os processos de menor prioridade vão praticamente parar para os de prioridade normal continuarem operando, e mesmo que os processos de prioridade normal coloquem cada um a sua CPU “na tampa”, o equipamento servidor não deve tornar-se indisponível, pois um core está “fora” da regra de consumo.

Conclusão

O esboço deste artigo estava a algum tempo da lista de publicações, porém os testes ainda não foram concluídos. De qualquer modo, é um tema interessante a ser pesquisado, e pode render bons frutos ao ponto que compreendemos um pouco mais como os recursos de um equipamento são provisionados. Este artigo terá continuação, assim que os testes pertinentes sejam concluídos.

Até a próxima, pessoal 😉

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s