Capítulo 8 Fair share scheduler (visão geral)

A análise dos dados da carga de trabalho indica que uma determinada carga de trabalho ou um determinado grupo de cargas de trabalho está monopolizando recursos da CPU. Se essas cargas de trabalho não estiverem violando restrições de recursos no uso de CPU, você poderá modificar a diretiva de alocação para o tempo de CPU no sistema. A classe fair share scheduling descrita neste capítulo permite que você aloque tempo de CPU com base em compartilhamentos, em vez de no esquema de prioridade da classe de agendamento de tempo compartilhado (TS).

Este capítulo aborda os seguintes tópicos:

• Introdução ao agendador

• Definição de compartilhamento de CPU

• Compartilhamentos de CPU e estado de processo

• Compartilhamentos de CPU versus utilização

• Exemplos de compartilhamento de CPU

• Configuração de FSS

• FSS e conjuntos de processadores

• Combinação de FSS com outras classes de agendamento

• Configuração da classe de agendamento para o sistema

• Classe de agendamento em um sistema com regiões instaladas

• Comandos usados com FSS

Para começar a usar o fair share scheduler, consulte o Capítulo 9Administração do fair share scheduler (tarefas).

Introdução ao agendador

Um trabalho fundamental do sistema operacional é decidir quais processos obtêm acesso aos recursos do sistema. O agendador de processos, que é também chamado de distribuidor, é a parte do kernel que controla a alocação da CPU a processos. O agendador oferece suporte ao conceito de classes de agendamento. Cada classe define uma diretriz de agendamento que é usada para agendar processos dentro da classe. O agendador padrão no Solaris Operating System, o agendador TS, tenta dar a cada processo um acesso relativamente igual às CPUs disponíveis. No entanto, você talvez deseje especificar que determinados processos tenham mais recursos do que outros.

Você pode usar o fair share scheduler (FSS) para controlar a alocação de recursos de CPU entre cargas de trabalho, com base na importância destas. Essa importância é expressa pelo número de compartilhamentos de recursos de CPU que você atribui a cada carga de trabalho.

Você dá a cada projeto compartilhamentos de CPU para controlar o direito do projeto aos recursos de CPU. O FSS garante uma dispersão justa de recursos de CPU entre projetos que é baseada em compartilhamentos alocadas, independentemente do número de processos anexados a um projeto. O FSS obtém a imparcialidade reduzindo o direito de um projeto para uso pesado de CPU e aumentando o direito ao uso leve, de acordo com outros projetos.

O FSS consiste em um módulo de classe de agendamento do kernel e em versões específicas da classe dos comandos dispadmin(1M) e priocntl(1). Compartilhamentos de projeto usados pelo FSS são especificados através da propriedade project.cpu-shares no banco de dados de project(4).

Se você estiver usando o controle de recurso project.cpu-shares em um sistema com regiões instaladas, consulte Dados de configuração de região, Controles de recursos em regiões não globais e Uso do fair share scheduler em um sistema do Solaris com regiões instaladas.

Definição de compartilhamento de CPU

O termo “compartilhamento” é usado para definir uma parte dos recursos da CPU do sistema que é alocada para um projeto. Se você atribuir um número maior de compartilhamentos de CPU para um projeto, em relação a outros projetos, o projeto receberá mais recursos de CPU do fair share scheduler.

Compartilhamentos de CPU não são equivalentes a porcentagens de recursos da CPU. Compartilhamentos podem ser usadas para definir a importância relativa de cargas de trabalho em relação a outras cargas de trabalho. Quando você atribui compartilhamentos da CPU a um projeto, a preocupação inicial não é o número de compartilhamentos que o projeto tem. É mais importante saber quantas compartilhamentos o projeto tem em comparação com outros projetos. Você também deve levar em conta quantos dos outros projetos irão competir com ele para obter recursos da CPU.

Processos em projetos com compartilhamentos zero são sempre executados na prioridade mais baixa do sistema (0). Esses processos somente são executados quando compartilhamentos não zero não estão usando recursos da CPU.

Compartilhamentos de CPU e estado de processo

No sistema do Solaris, a carga de trabalho de um projeto geralmente consiste em mais de um processo. Da perspectiva do fair share scheduler, cada carga de trabalho de um projeto pode estar em um estado ocioso ou ativo . Um projeto é considerado ocioso se nenhum processo estiver usando quaisquer recursos da CPU. Isso em geral significa que esses processo estão dormindo (aguardando a conclusão de E/S) ou parados. Um projeto é considerado ativo se pelo menos um dos processo estiver usando recursos da CPU. A soma de compartilhamentos de todos os projetos ativos é usada no cálculo da parte dos recursos da CPU a ser atribuída a projetos.

Quando mais projetos se tornam ativos, cada alocação da CPU a um projeto é reduzida, mas a proporção entre as alocações de diferentes projetos não muda.

Compartilhamentos de CPU versus utilização

A alocação de compartilhamentos não é o mesmo que utilização. Um projeto ao qual se aloca 50 por cento dos recursos da CPU pode ter uma média de apenas 20 por cento de uso da CPU. Além disso, compartilhamentos servem para limitar o uso da CPU somente quando há concorrência de outros projetos. Independentemente de quão baixa é a alocação de um projeto, ele sempre recebe 100 por cento da potência do processamento, se estiver sendo executado sozinho no sistema. Ciclos da CPU disponíveis nunca são desperdiçados. Eles são distribuídos entre projetos.

A alocação de um compartilhamento pequeno para uma carga de trabalho ocupada pode diminuir o desempenho. No entanto, não há impedimento para a carga de trabalho concluir o trabalho, se o sistema não estiver sobrecarregado.

Exemplos de compartilhamento de CPU

Suponha que você tem um sistema com duas CPUs que executam duas cargas de trabalho paralelas vinculadas à CPU chamadas A e B, respectivamente. Cada carga de trabalho é executada como um projeto separado. Os projetos foram configurados de modo que o projeto A receba compartilhamentos S_A, e o projeto B receba compartilhamentos S _B.

Na média, no agendador TS tradicional, cada carga de trabalho executada no sistema receberia a mesma quantidade de recursos da CPU. Cada carga de trabalho receberia 50 por cento da capacidade do sistema.

Quando executados sob o controle do agendador FSS com S _A=S_B , estes projetos também recebem aproximadamente as mesmas quantidades de recursos da CPU. No entanto, se os projetos receberem diferentes números de compartilhamentos, as alocações de recursos da CPU serão diferentes.

Os três exemplos abaixo ilustram como compartilhamentos funcionam em configurações diferentes. Estes exemplos mostram que compartilhamentos são matematicamente exatas somente para representar o uso, se a demanda atender ou exceder recursos disponíveis.

Exemplo 1: Dois processos vinculados à CPU em cada projeto

Se e tiverem dois processos vinculados à CPU, e S _A = 1 e S _B = 3, segue-se que o número total de compartilhamentos é 1 + 3 = 4. Nesta configuração, dada a demanda suficiente da CPU, os projetos A e B recebem 25 por cento e 75 por cento dos recursos da CPU, respectivamente.

Exemplo 2: Nenhuma concorrência entre projetos

Se A e B tiverem cada um somente um processo vinculado à CPU, e S A _{= 1} e S B _{= 100}, então o número total de compartilhamentos é 101. Cada projeto não pode usar mais do que uma CPU, porque cada projeto tem somente um processo em execução. Uma vez que nesta configuração não existe concorrência entre projetos pelos recursos da CPU, os projetos A e B recebem cada um 50 por cento de todos os recursos da CPU. Nesta configuração, os valores de compartilhamento da CPU são irrelevantes. As alocações seriam as mesmas (50/50), mesmo se os dois projetos tivessem recebido compartilhamentos zero.

Exemplo 3: Um projeto não pode ser executado

Se A e B tiverem dois processos vinculados à CPU cada um, e o projeto A recebe 1 compartilhamento e o projeto B recebe compartilhamento 0, o projeto B não receberá recurso da CPU e o projeto A receberá todos os recursos da CPU. Os processos em B sempre são executados na prioridade 0 do sistema, de modo que nunca poderão ser executados, porque os processos no projeto A sempre têm prioridades mais altas.

Configuração de FSS

Projetos e usuários

Projetos são recipientes de cargas de trabalho no agendador FSS. Grupos de usuários atribuídos a um projeto são tratados como blocos únicos controláveis. Observe que você pode criar um projeto com um número próprio de compartilhamentos para um usuário individual.

Usuários podem ser membros de múltiplos projetos aos quais se atribuem diferentes números de compartilhamentos. Movendo-se processos de um projeto para outro, é possível atribuir recursos da CPU a processos em quantidades variáveis.

Para obter mais informações sobre o banco de dados de project(4) e serviços de nomes, consulte Banco de dados de project.

Configuração de compartilhamentos de CPU

A configuração de compartilhamentos de CPU é gerenciada pelo serviço de nomes como uma propriedade do banco de dados de project.

Quando a primeira tarefa (ou processo) associada a um projeto é criada através da função de biblioteca setproject(3PROJECT), o número de compartilhamentos de CPU definido como controle de recurso project.cpu-shares no banco de dados de project é passado para o kernel. A um projeto que não tem o controle de recurso project.cpu-shares atribui-se um compartilhamento.

No exemplo abaixo, esta entrada no arquivo /etc/project define o número de compartilhamentos para x-files do projeto como 5:

x-files:100::::project.cpu-shares=(privileged,5,none)

Se você alterar o número de compartilhamentos da CPU alocados para um projeto no banco de dados quando os processos já estão em execução, o número de compartilhamentos para esse projeto não será modificado neste estágio. O projeto deve ser reiniciado para a alteração ter efeito.

Se você desejar alterar temporariamente o número de compartilhamentos atribuídos a um projeto sem alterar os atributos do projeto no banco de dados de project, use o comando prctl. Por exemplo, para alterar o valor do controle de recurso project.cpu-shares de x-filesdo projeto para 3 enquanto os processos associados ao projeto estão em execução, digite o seguinte:

# prctl -r -n project.cpu-shares -v 3 -i project x-files

Para obter mais informações, consulte a página do manual prctl(1).

-r

Substitui o valor atual para o controle de recurso nomeado.

-n name

Especifica o nome do controle de recurso.

-v val

Especifique o valor para o controle de recurso.

-i idtype

Especifica o tipo de ID do próximo argumento.

x-files

Especifica o objeto da alteração. Neste exemplo, o projeto x-files é o objeto.

O projeto system com ID de projeto 0 inclui todos os daemons do sistema que são iniciados pelos scripts de inicialização no momento de inicialização. system pode ser visualizado como um projeto com um número de compartilhamentos ilimitado. Isso significa que system é sempre agendado primeiro, independentemente de quantos compartilhamentos foram dados para outros projetos. Se você não desejar que o projeto system tenha compartilhamentos ilimitados, pode especificar um número de compartilhamentos para este projeto no banco de dados de project.

Como dito anteriormente, processos que pertencem a projetos com compartilhamentos zero sempre recebem prioridade zero do sistema. Projetos com um ou mais compartilhamentos são executados com prioridades um e superior. Assim, projetos com compartilhamentos zero são somente agendados quando estão disponíveis recursos da CPU que não são solicitados por um projeto com compartilhamento não zero.

O número máximo de compartilhamentos que podem ser atribuídas a um projeto é 65535.

FSS e conjuntos de processadores

O FSS pode ser usado junto com um conjunto de processadores para fornecer controles mais precisos sobre alocações de recursos da CPU entre projetos que são executados em cada conjunto de processadores do que estaria disponível apenas com conjuntos de processadores. O agendador FSS trata os conjuntos de processadores como partições totalmente independentes, com cada conjunto de processadores controlado independentemente com relação a alocações de CPU.

As alocações de CPU de projetos em execução em um conjunto de processadores são afetadas pelos compartilhamentos da CPU ou pela atividade de projetos em execução em outro conjunto de processadores porque os projetos não concorrem pelos mesmos recursos. Projetos somente concorrem entre si se forem executados dentro do mesmo conjunto de processadores.

O número de compartilhamentos alocados a um projeto é do sistema geral. Independentemente de qual conjunto de processadores estão em execução, cada parte de um projeto recebe a mesma quantidade de compartilhamentos.

Quando conjuntos de processadores são usados, as alocações de CPU para projetos são calculadas para projetos ativos que são executados dentro de cada conjunto de processadores.

Partições de projeto executadas em diferentes conjuntos de processadores podem ter alocações de CPU diferentes. A alocação de CPU para cada partição de projeto em um conjunto de processadores depende somente das alocações de outros projetos executados no mesmo conjunto de processadores.

O desempenho e a disponibilidade de aplicativos executados dentro dos limites de seus conjuntos de processadores não são afetados pela introdução de novos conjuntos de processadores. Os aplicativos também não são afetados por alterações feitas nas alocações de compartilhamentos de projetos executados em outros conjuntos de processadores.

Conjuntos vazios de processadores (conjuntos que não contêm processadores) ou conjuntos de processadores vinculados a eles não têm qualquer impacto sobre o comportamento do agendador FSS.

FSS e exemplos de conjuntos de processadores

Suponha que um servidor com oito CPUs esteja executando diversos aplicativos vinculados à CPU nos projetos A, B e C. Para o projeto A um compartilhamento é alocado, para o projeto B, dois compartilhamentos, e para o projeto C, três compartilhamentos.

O projeto A está sendo executado somente em no conjunto de processadores 1. O projeto B está sendo executado somente no conjunto de processadores 1 e 2. O projeto C está sendo executado somente no conjunto de processadores 1, 2 e 3. Suponha que cada projeto apresente processos suficientes para utilizar toda a energia disponível da CPU. Assim, sempre há concorrência pelos recursos de CPU em cada conjunto de processadores.

O total de alocações de CPU para projetos no sistema geral em tal sistema é mostrado na tabela abaixo.

Estas porcentagens não coincidem com as quantidades correspondentes de compartilhamentos de CPU dados a projetos. No entanto, com cada conjunto de processadores, as taxas de alocação de CPU por projeto são proporcionais a seus respectivos compartilhamentos.

No mesmo sistema sem conjuntos de processadores, a distribuição de recursos de CPU seriam diferentes, como mostrado na tabela abaixo.

Combinação de FSS com outras classes de agendamento

Por padrão, a classe de agendamento de FSS usa o mesmo intervalo de prioridades (0 to 59) que as classes de agendamento de compartilhamento de tempo (TS), interativas (IA) e prioridade fixa (FX). Assim, deve-se evitar que processos destas classes de agendamento compartilhem o mesmo conjunto de processadores. Uma mistura de processos nas classes FSS, TS, IA e FX pode resultar em comportamento de agendamento inesperado.

Com o uso de conjuntos de processadores, você pode misturar TS, IA e FX com FSS em um sistema. No entanto, todos os processos executados em cada conjunto de processadores deve estar em uma classe de agendamento, para que não concorram pelas mesmas CPUs. O agendador FX em especial não deve ser usado juntamente com a classe de agendamento FSS, a menos que conjuntos de processadores sejam usados. Esta ação impede que aplicativos na classe FX usem prioridades altas o bastante para não abastecer aplicativos na classe FSS.

Você pode misturar processos nas classes TS e IA no mesmo conjunto de processadores, ou no mesmo sistema sem conjuntos de processadores.

O sistema do Solaris também oferece um agendador em tempo real (RT) a usuários com privilégios de superusuários. Por padrão, a classe de agendamento RT usa prioridades de sistema em um intervalo diferente (em geral de 100 a 159) do FSS. Uma vez que RT e FSS usa intervalos de prioridade de disjunção, ou não sobreposição, FSS pode coexistir com a classe de agendamento RT dentro do mesmo conjunto de processadores. No entanto, a classe de agendamento FSS não tem qualquer controle sobre processos executados na classe RT.

Por exemplo, em um sistema de quatro processadores, um processo RT de monossegmentado pode consumir um processador inteiro, se o processo estiver vinculado à CPU. Se o sistema também executar FSS, processos de usuário regulares concorrem pelas três CPUs restantes que não estão sendo usadas pelo processo RT. Observe que o processo RT pode não usar a CPU continuamente. Quando o processo RT está ocioso, FSS utiliza todos os quatro processadores.

Você pode digitar o comando abaixo para identificar em quais classes de agendamento os conjuntos de processadores estão sendo executados e assegurar que cada conjunto de processadores seja configurado para executar processos TS, IA, FX ou FSS.

$ ps -ef -o pset,class | grep -v CLS | sort | uniq
1 FSS
1 SYS
2 TS
2 RT
3 FX

Configuração da classe de agendamento para o sistema

Para definir a classe de agendamento padrão para o sistema, consulte Como tornar o FSS a classe padrão do agendador, Classe de agendamento em uma região e dispadmin(1M). Para mover processos em execução para uma classe de agendamento diferente, consulte Configuração do FSS e priocntl(1).

Classe de agendamento em um sistema com regiões instaladas

Regiões não globais usam a classe de agendamento padrão para o sistema. Se o sistema estiver atualizado com uma nova configuração de classe de agendamento, as regiões não globais obtêm a nova configuração quando inicializadas ou reinicializadas.

A forma preferida de usar o FSS neste caso é definir o FSS para ser a classe de agendamento padrão do sistema com o comando dispadmin. Todas as regiões se beneficiam de um compartilhamento justo dos recursos de CPU do sistema. Para obter mais informações sobre classe de agendamento quando regiões estão em uso, consulte Classe de agendamento em uma região.

Para obter informações sobre mover processos em execução para uma classe de agendamento diferente sem alterar a classe de agendamento padrão e reinicializar, consulte a Tabela 27–5 e a página do manual priocntl(1).

Comandos usados com FSS

Os comandos mostrados na tabela abaixo oferecem a interface administrativa principal para fair share scheduler.