Capítulo 12 Grupos de recursos (visão geral)

Este capítulo trata das seguintes funções:

• Grupos de recursos, que são úteis para a partição de recursos de máquinas

• Grupos de recursos dinâmicos (DRPs), que ajustam dinamicamente cada alocação de recurso do grupo de recursos para atender os objetivos de sistema estabelecidos

A partir da versão Solaris 10 11/06, grupos de recursos e grupos de recursos dinâmicos agora são serviços na facilidade de gerenciamento de serviços (SMF) do Solaris. Cada um desses serviços é ativado separadamente.

Os tópicos a seguir são tratados neste capítulo:

• Introdução a grupos de recursos

• Introdução a grupos de recursos dinâmicos

• Sobre ativação e desativação de grupos de recursos e grupos de recursos dinâmicos

• Grupos de recursos usados em regiões

• Quando usar grupos

• Estrutura de grupos de recursos

• Implementação de grupos em um sistema

• Atributo project.pool

• SPARC: Operações de reconfiguração dinâmica e grupos de recursos

• Criação de configurações de grupos

• Manipulação direta da configuração dinâmica

• Visão geral de poold

• Gerenciamento de grupos de recursos dinâmicos

• Configuração de restrições e objetivos

• As funções de poold que podem ser configuradas

• Como funciona a alocação de recursos dinâmicos

• Uso de poolstat para monitorar a facilidade de grupos e a utilização de recursos

• Comandos usados com a facilidade de grupos de recursos

Para procedimentos para o uso desta funcionalidade, consulte o Capítulo 13Criação e administração de grupos de recursos (tarefas).

O que há de novo em grupos de recursos e grupos de recursos dinâmicos?

Solaris 10: Grupos de recursos agora fornecem um mecanismo para ajustar cada alocação de recurso do grupo de recursos em resposta a eventos do sistema e alterações de carga do aplicativo. Grupos de recursos dinâmicos simplificam e reduzem o número de decisões que se requer de um administrador. Ajustes são feitos automaticamente para preservar os objetivos de desempenho do sistema especificados por um administrador.

Você agora pode usar o comando projmod para definir o atributo no arquivo /etc/project.

Para obter uma lista completa dos novos recursos do Solaris 10 e uma descrição das versões do Solaris, consulte Novidades no Oracle Solaris 10 9/10.

Solaris 10 11/06: Grupos de recursos e grupos de recursos dinâmicos agora são serviços do SMF.

Introdução a grupos de recursos

Grupos de recursos permitem que você separe cargas de trabalho para que o consumo de carga de trabalho de determinados recursos não se sobreponha. Essa reserva de recursos ajuda a alcançar desempenho previsível em sistemas com cargas de trabalho misturadas.

Grupos de recursos oferecem um mecanismo de configuração persistente para conjunto de processadores (pset) e, opcionalmente, atribuição de classe de agendamento.

Figura 12–1 Estrutura de grupos de recursos

Pode-se considerar um grupo uma vinculação específica dos vários conjuntos de recursos que estão disponíveis no sistema. Você pode criar grupos que representam diferentes tipos de combinações possíveis de recursos:

Ao agruparem várias partições, os grupos fornecem um manipulador para a ser associado a cargas de trabalho com rótulo. Cada entrada de projeto no arquivo /etc/project pode ter um único grupo associado a essa entrada, que é especifico usando-se o atributoproject.pool.

Quando grupos estão ativados, um grupo padrão e um conjunto de processadores padrão formam a configuração base. Grupos e conjuntos de processadores adicionais definidos pelo usuário podem ser criados e adicionados à configuração. Uma CPU pode somente pertencer a um conjunto de processadores. Grupos e conjuntos de processadores definidos pelo usuário podem ser destruídos. O grupo padrão e o conjunto de processadores padrão não podem ser destruídos.

O grupo padrão tem a propriedade pool.default definida como true. O conjunto de processadores padrão tem a propriedade pset.default definida como true. Assim, o grupo padrão e o conjunto de processadores padrão podem ser identificados mesmo quando seus nomes tenham sido alterados.

O mecanismo de grupos definidos pelo usuário é primariamente para uso com máquinas grandes de mais de quatro CPUs. No entanto, máquinas pequenas ainda podem se beneficiar desta funcionalidade. Em máquinas pequenas, você pode criar grupos que compartilhem partições de recursos não críticos. Os grupos são separados somente na base de recursos críticos.

Introdução a grupos de recursos dinâmicos

Grupos de recursos dinâmicos fornecem um mecanismo para ajustar dinamicamente a alocação de recursos de cada grupo em resposta aos eventos do sistema e às alterações de carga de aplicativos. DRPs simplificam e reduzem o número de decisões que se requer de um administrador. Ajustes são feitos automaticamente para preservar os objetivos de desempenho do sistema especificados por um administrador. As alterações feitas na configuração são registradas. Estas funções são efetuadas primariamente através do controlador de recursos poold, um daemon do sistema que deve sempre estar ativo quando a alocação de recursos dinâmicos é necessária. Periodicamente, poold examina a carga no sistema e determina se a intervenção é necessária para ativar o sistema para manter ótimo desempenho com relação ao consumo de recursos. A configuração de poold é contida na configuração de libpool. Para obter mais informações sobre poold, consulte a página do manual poold(1M).

Sobre ativação e desativação de grupos de recursos e grupos de recursos dinâmicos

Para ativar e desativar grupos de recursos e grupos de recursos dinâmicos, consulte Ativação e desativação da facilidade de grupos.

Grupos de recursos usados em regiões

Solaris 10 8/07: Como uma alternativa para associar uma região a um grupo de recursos configurado no sistema, você pode usar o comando zonecfg para criar um grupo temporário que esteja em vigor enquanto a região é executada. Para obter mais informações, consulte Solaris 10 8/07: recurso dedicated-cpu.

Em um sistema com regiões ativadas, uma região não global pode ser associada a um grupo de recursos, embora não seja necessário que o grupo seja atribuído exclusivamente a uma determinada região. Além disso, não é possível vincular processos individuais em regiões não globais a um grupo diferente usando o comando poolbind da região global. Para associar uma região não global a um grupo, consulte Configuração, verificação e comprometimento de uma região.

Observe que, se você definir uma classe de agendamento para um grupo e associar uma região não global a esse grupo, a região usará essa classe de agendamento por padrão.

Se você estiver usando grupos de recursos dinâmicos, o escopo de uma instância em execução de poold é limitada à região global.

O utilitário poolstat executado em uma região não global exibe somente informações sobre o grupo associado à região. O comando pooladm executado sem argumentos em uma região não global exibe somente informações o grupo associado à região.

Para obter informações sobre comandos de grupos de recursos, consulte Comandos usados com a facilidade de grupos de recursos.

Quando usar grupos

Grupos de recursos oferecem um mecanismo versátil que pode ser aplicado a vários cenários administrativos.

Servidor de computação em lotes

Use a funcionalidade de grupos para dividir um servidor em dois grupos. Um grupo é usado para sessões de login e trabalho interativo por usuários de compartilhamento de tempo. O outro grupo é usado para trabalhos que são enviados através do sistema de lotes.

Servidor de aplicativo ou banco de dados

Faça a partição de recursos para aplicativos interativos de acordo com os requisitos do aplicativo.

Ativação de aplicativos em fases

Defina as expectativas do usuário.

Você pode inicialmente implantar uma máquina que executa somente uma fração dos serviços que se espera que a máquina entregue ao final. Dificuldades para o usuário podem ocorrer se os mecanismos de gerenciamento de recursos com base em reserva não forem estabelecidos quando a máquina entra on-line.

Por exemplo, o fair share scheduler otimiza a utilização da CPU. Os tempos de resposta de uma máquina que executa somente um aplicativo podem ser enganosamente rápidos. Os usuários não verão esses tempos de resposta com vários aplicativos carregados. Com o uso de grupos separados para cada aplicativo, você pode colocar um teto no número de CPUs disponíveis para cada aplicativo antes de implantar todos os aplicativos.

Servidor de compartilhamento de tempo complexo

Faça a partição de um servidor que ofereça suporte a populações grandes de usuários. A partição do servidor fornece um mecanismo de isolamento que leva a uma resposta por usuário mais previsível.

Com a divisão dos usuários em grupos que vinculem grupos separados, e com o uso da facilidade fair share scheduling (FSS), você pode ajustar alocações de CPU para favorecer conjuntos de usuários que tenham prioridade. Esta atribuição pode ser baseada em função de usuário, em chargeback de contabilidade, e assim por diante.

Cargas de trabalho que mudam periodicamente

Use grupos de recursos para um ajuste de acordo com a demanda de alteração.

Seu site pode experimentar mudanças previsíveis na demanda de cargas de trabalho durante longos períodos de tempo, como ciclos mensais, trimestrais ou anuais. Se seu site experimentar essas mudanças, você poderá alternar entre várias configurações de grupos ao chamar pooladm de um trabalho cron. (Consulte Estrutura de grupos de recursos.)

Aplicativos em tempo real

Crie um grupo de tempo real usando o agendador RT e recursos de processador designado.

Utilização do sistema

Aplique objetivos de sistema que você estabelece.

Use o recurso de daemon de grupos automatizados para identificar recursos disponíveis e, em seguida, monitorar cargas de trabalho para detectar quando os objetivos especificados não são mais satisfeitos. O daemon pode adotar uma ação corretiva, se possível, ou a condição pode ser registrada.

Estrutura de grupos de recursos

O arquivo de configuração /etc/pooladm.conf descreve a configuração de grupos estáticos. Uma configuração estática representa como um administrador gostaria que um sistema fosse configurado em relação à funcionalidade de grupos de recursos. Um nome de arquivo alternativo pode ser especificado.

Quando a facilidade de gerenciamento de serviço (SMF) ou o comando pooladm - e é usado para ativar a estrutura dos grupos de recursos, a configuração contida no arquivo é aplicada ao sistema se existir um arquivo /etc/pooladm.conf.

O kernel armazena informações sobre a disposição de recursos dentro da estrutura de grupos de recursos. Isto é conhecido como a configuração dinâmica, e representa a funcionalidade de grupos de recursos para um sistema específico em determinado tempo. A configuração dinâmica pode ser visualizada usando-se o comando pooladm. Observe que a ordem que as propriedades são exibidas para grupos e conjuntos de recursos pode variar. Modificações na configuração dinâmica são feitas das seguintes maneiras:

• Indiretamente, aplicando-se um arquivo de configuração estática

• Diretamente, usando-se o comando poolcfg com a opção -d

Mais de um arquivo de configuração de grupos estáticos pode existir, para ativação em momentos diferentes. Você pode alternar entre configurações de vários grupos chamando pooladm de um trabalho cron. Consulte a página do manual cron(1M) para obter mais informações sobre o utilitário cron.

Por padrão, a estrutura de grupos de recursos não está ativa. Os grupos de recursos devem estar ativados para a criação ou modificação da configuração dinâmica. Os arquivos de configuração estática podem ser manipulados com os comandos poolcfg ou libpool, mesmo que a estrutura de grupos de recursos esteja desativada. Não é possível criar arquivos de configuração estática se a facilidade de grupos não estiver ativa. Para obter mais informações sobre o arquivo de configuração, consulte Criação de configurações de grupos.

Os comandos usados com grupos de recursos e o daemon de sistema poold são descritos nas seguintes páginas do manual:

• pooladm(1M)

• poolbind(1M)

• poolcfg(1M)

• poold(1M)

• poolstat(1M)

• libpool(3LIB)

Conteúdo de /etc/pooladm.conf

Todas as configurações de grupo de recursos, inclusive a configuração dinâmica, podem conter os seguintes elementos.

system

Propriedades que afetam o comportamento total do sistema

pool

Uma definição de grupo de recursos

pset

Uma definição de conjunto de processadores

cpu

Uma definição de processador

Todos esses elementos têm propriedades que podem ser manipuladas para alterar o estado e o comportamento da estrutura de grupos de recursos. Por exemplo, a propriedade de grupo pool.importance indica a importância relativa de um determinado grupo. Esta propriedade é usada para uma possível resolução de uma disputa por recursos. Para obter mais informações, consulte libpool(3LIB).

Propriedades de grupos

A facilidade de grupos oferece suporte a propriedades nomeadas e digitadas que podem ser colocadas em um grupo, recurso ou componente. Administradores podem armazenar propriedades adicionais nos vários elementos de grupo. É usado um espaço de nome de propriedade semelhante ao atributo de projeto.

Por exemplo, o comentário a seguir indica que um determinado pset está associado a um banco de dados Datatree específico.

Datatree,pset.dbname=warehouse

Para obter informações adicionais sobre tipos de propriedades, consulte Propriedades do poold.

Diversas propriedades especiais são reservadas para uso interno e não podem ser definidas ou removidas. Para obter mais informações, consulte a página do manual libpool(3LIB).

Implementação de grupos em um sistema

Grupos definidos pelo usuário podem ser implementados em um sistema usando-se um dos métodos abaixo.

• Quando o software Solaris é inicializado, um script init verifica se o arquivo /etc/pooladm.conf existe. Se este arquivo for encontrado e os grupos estiverem ativos, pooladm será chamado para tornar esta configuração a configuração de grupos ativos. O sistema cria uma configuração dinâmica para refletir a organização que é solicitada em /etc/pooladm.conf, e a partição dos recursos da máquina é feita de acordo.

• Quando o sistema do Solaris está em execução, uma configuração de grupos pode ser ativada, se não estiver presente, ou modificada, usando-se o comando pooladm. Por padrão, o comando pooladm opera em /etc/pooladm.conf. No entanto, você pode, opcionalmente, especificar um local e um nome de arquivo alternativos, e usar esse arquivo para atualizar a configuração de grupos.

Para obter informações sobre ativação e desativação de grupos de recursos, consulte Ativação e desativação da facilidade de grupos. Não é possível desativar a facilidade de grupos quando há grupos definidos pelo usuário ou recursos em uso.

Para configurar grupos de recursos, você deve ter privilégios de superusuário ou ter o perfil Gerenciamento de processo na lista de perfis. A função Administrador de sistema inclui o perfil Gerenciamento de processo.

O controlador de recurso poold é iniciado com a facilidade de grupos de recursos dinâmicos.

Atributo project.pool

O atributo project.pool pode ser adicionado a uma entrada de projeto no arquivo /etc/project para associar um único grupo a essa entrada. Um novo trabalho iniciado em um projeto é limitado a um grupo apropriado. Para obter mais informações, consulte o Capítulo 2Projetos e tarefas (visão geral).

Por exemplo, você pode usar o comando projmod para definir o atributo project.pool para o projeto sales no arquivo /etc/project:

# projmod -a -K project.pool=mypool sales

SPARC: Operações de reconfiguração dinâmica e grupos de recursos

A reconfiguração dinâmica (DR) permite que você reconfigure hardware enquanto o sistema está em execução. Uma operação DR pode aumentar ou reduzir um determinado tipo de recurso, ou não ter qualquer efeito sobre ele. Uma vez que DR pode afetar quantidades de recursos disponíveis, a facilidade de grupos deve estar incluída nestas operações. Quando uma operação DR é iniciada, a estrutura de grupos atua para validar a configuração.

Se a operação DR puder continuar sem fazer com que a configuração de grupos atual se torne inválida, o arquivo de configuração privada será atualizado. Uma configuração inválida não recebe suporte dos recursos disponíveis.

Se a operação DR fazer com que a configuração de grupos seja invalidada, a operação irá falhar e você será notificado por uma mensagem para o log de mensagens. Se desejar forçar a configuração até a conclusão, você terá de usar a opção de forçar de DR. A configuração de grupos será então modificada para atender à nova configuração de recursos. Para obter informações sobre o processo de DR e a opção de forçar, consulte o guia do usuário de reconfiguração dinâmica para o hardware da Sun.

Se estiver usando grupos de recursos dinâmicos, observe que é possível uma partição sair do controle poold enquanto o daemon estiver ativo. Para obter mais informações, consulte Identificação de uma falta de recurso.

Criação de configurações de grupos

O arquivo de configuração contém uma descrição dos grupos a serem criados no sistema. O arquivo descreve os elementos que podem ser manipulados.

• sistema

• grupo

• pset

• cpu

Para obter informações sobre elementos que podem ser manipulados, consulte poolcfg(1M).

Quando grupos são ativados, você pode criar um arquivo /etc/pooladm.conf estruturado de duas maneiras.

• Pode usar o comando pooladm com a opção - s para descobrir os recursos no sistema atual e colocar os resultados em um arquivo de configuração.

  Este método é preferido. Todos os recursos e componentes ativos no sistema que são capazes de ser manipulados pela facilidade de grupos são registrados. Os recursos incluem configurações de conjuntos de processadores existentes. Você pode então modificar a configuração para renomear os conjuntos de processadores ou para criar grupos adicionais, se necessário.

• Você pode usar o comando poolcfg com a opção - c e os subcomandos discover ou create system name para criar uma nova configuração de grupos.

  Estas opções são mantidas para compatibilidade com a versão anterior.

Use poolcfg ou libpool para modificar o arquivo /etc/pooladm.conf. Não edite diretamente este arquivo.

Manipulação direta da configuração dinâmica

É possível manipular diretamente tipos de recursos de CPU na configuração dinâmica usando o comando poolcfg com a opção -d. Dois métodos são usados para transferir recursos.

• Você pode fazer uma solicitação geral para transferir qualquer recurso identificado disponível entre conjuntos.

• Você pode transferir recursos com IDs específicos para um conjunto de destino. Observe que os IDs de sistema associados a recursos podem mudar quando a configuração de recursos é alterada ou após uma reinicialização do sistema.

Para um exemplo, consulte Transferência de recursos.

Observe que a transferência de recursos pode acionar uma ação de poold. Para obter mais informações, consulte Visão geral de poold.

Visão geral de poold

O controlador de recursos de grupos, poold, usa destinos de sistema e estatísticas observáveis para preservar os objetivos de desempenho do sistema que você especifica. O daemon do sistema deve estar sempre ativo quando a alocação de recursos dinâmicos é necessária.

O controlador de recursos poold identifica recursos disponíveis e, em seguida, monitora cargas de trabalho para determinar quando os objetivos de uso do sistema não são mais atendidos. O poold em seguida considera configurações alternativas em termos de objetivos, e uma ação corretiva é tomada. Se possível, os recursos são reconfigurados para que os objetivos possam ser satisfeitos. Se esta ação não for possível, o daemon registrará que os objetivos especificados pelo usuário não podem mais ser alcançados. Após uma reconfiguração, o daemon retoma a monitoração dos objetivos de cargas de trabalho.

O poold mantém um histórico da decisão que ele pode examinar. O histórico da decisão é usado para eliminar reconfigurações que historicamente não mostraram aprimoramentos.

Observe que uma reconfiguração também pode ser acionada assincronicamente, se os objetivos de cargas de trabalho forem alterados ou se os recursos disponíveis para o sistema forem modificados.

Gerenciamento de grupos de recursos dinâmicos

O serviço de DRP é gerenciado pela facilidade de gerenciamento de serviço (SMF) no identificador de serviço svc:/system/pools/dynamic.

Ações administrativas neste serviço, como ativar, desativar ou solicitar reinicialização, podem ser executadas usando-se o comando svcadm. O status do serviço pode ser consultado usando-se o comando svcs. Para obter mais informações, consulte as páginas do manual svcs(1) e svcadm(1M).

A interface SMF é o método preferido para controlar DRP, mas para a compatibilidade com a versão anterior, os métodos abaixo também podem ser usados.

• Se a alocação de recursos dinâmicos não for solicitada poold pode ser interrompido com o sinal SIGQUIT ou o sinal SIGTERM. Qualquer um desses sinais faz o poold ser encerrado perfeitamente.

• Embora poold detecte alterações automaticamente na configuração de recursos ou de grupos, você também pode forçar a ocorrência de uma reconfiguração usando o sinal SIGHUP.

Configuração de restrições e objetivos

Ao se fazer alterações em uma configuração, poold atua nas direções que você fornece. Você especifica essas direções como uma série de restrições e objetivos. O poold usa suas especificações para determinar o valor relativo de diferentes possibilidades de configuração em relação à configuração existente. O poold em seguida altera as atribuições de recursos da configuração atual para gerar novas configurações candidatas.

Restrições de configuração

Restrições afetam a gama de configurações possíveis eliminando algumas das alterações potenciais que poderiam ser feitas em uma configuração. As restrições a seguir, que são especificadas na configuração libpool, estão disponíveis.

• As alocações mínimas e máximas de CPU

• Componentes fixos que não estão disponíveis para serem movidos de um conjunto

Para obter mais informações sobre propriedades de grupos, consulte a página do manual libpool(3LIB) e Propriedades de grupos.

Restrições da propriedade pset.min e da propriedade pset.max

Estas duas propriedades colocam limites ao número de processadores que podem ser alocados para um conjunto de processadores, o mínimo e o máximo. Para obter informações sobre estas propriedades, consulte a Tabela 12–1.

Dentro destas restrições, recursos de uma partição de recurso estão disponíveis para serem alocados para outras partições de recurso na mesma instância do Solaris. O acesse ao recurso é obtido pela vinculação a um grupo que esteja associado ao conjunto de recursos. A vinculação é realizada no login ou manualmente pelo administrador que tenha o privilégio PRIV_SYS_RES_CONFIG.

Restrição da propriedade cpu.pinned

A propriedade cpu-pinned indica que uma determinada CPU não deve ser movida por DRP do conjunto de processadores no qual está localizada. Você pode definir esta propriedade libpool como utilização máxima de cache para um aplicativo específico que esteja sendo executado dentro de um conjunto de processadores.

Para obter informações sobre estas propriedades, consulte a Tabela 12–1.

Restrição da propriedade pool.importance

A propriedade pool.importance descreve a importância relativa de um grupo como definida pelo administrador.

Objetivos da configuração

Objetivos são especificados da mesma forma para restrições. O conjunto completo de objetivos está documentado na Tabela 12–1.

Há duas categorias de objetivos.

Dependente de carga de trabalho

Um objetivo dependente da carga de trabalho é um objetivo que variará de acordo com a natureza da carga de trabalho em execução no sistema. Um exemplo é o objetivo utilization. Os dados da utilização de um conjunto de recursos variarão de acordo com a natureza da carga de trabalho que esteja ativa no conjunto.

Independente de carga de trabalho

Um objetivo independente de carga de trabalho é um objetivo que não varia de acordo com a natureza da carga de trabalho em execução no sistema. Um exemplo é o objetivo locality de CPU. A medida avaliada de localidade para um conjunto de recursos não varia com a natureza da carga de trabalho que esteja ativa no conjunto.

Você pode definir três tipos de objetivos.

Objetivos são armazenados em seqüências de propriedades na configuração libpool. Os nomes das propriedades são os seguintes:

• system.poold.objectives

• pset.poold.objectives

Objetivos têm a seguinte sintaxe:

• objectives = objective [; objective]*

• objective = [n:] keyword [op] [value]

Todos os objetivos levam um prefixo de importância opcional. A importância atua como um multiplicador para o objetivo, aumentando assim a significância de sua contribuição para a avaliação da função do objetivo. O intervalo é de 0 a INT64_MAX (9223372036854775807). Se não especificado, o valor padrão da importância é 1.

Alguns tipos de elemento fornecem suporte a mais de um tipo de objetivo. Um exemplo é pset. Você pode especificar vários tipos de objetivo para esses elementos. Pode também especificar vários objetivos de utilização em um único elemento pset.

Para exemplos de uso, consulte Como definir objetivos de configuração.

Objetivo wt-load

O objetivo wt-load favorece configurações que coincidem alocações de recursos com utilizações de recurso. Um conjunto de recursos que use mais recursos receberão mais recursos quando este objetivo estiver ativo. wt-load significa carga ponderada.

Use este objetivo quando você estiver satisfeito com as restrições estabelecidas usando as propriedades mínimas e máximas, e desejar que o daemon manipule recursos livremente dentro dessas restrições.

O objetivo locality

O objetivo locality influencia o impacto que a localidade, como medida por dados de grupo de localidade (lgroup), tem sobre a configuração selecionada. Uma definição alternativa para localidade é latência. Um lgroup descreve recursos de CPU e de memória. O lgroup é usado pelo sistema do Solaris para determinar a distância entre recursos, usando o tempo como a medida. Para obter mais informações sobre a abstração do grupo de localidades, consulte Locality Groups Overview no Programming Interfaces Guide.

Este objetivo pode tomar um dos três valores seguintes:

tight

Se definido, as configurações que maximizam a localidade de recursos são favorecidas.

loose

Se definido, as configurações que minimizam a localidade de recursos são favorecidas.

none

Se definido, o favorecimento de uma configuração não é influenciado pela localidade do recurso. Este é o valor padrão para o objetivo locality.

Em geral, o objetivo locality deve ser definido para tight. No entanto, para maximizar a largura de banda da memória ou para minimizar o impacto das operações DR em um conjunto de recursos, você pode definir este objetivo como loose ou mantê-lo na definição padrão de none.

Objetivo utilization

O objetivo utilization favorece configurações que alocam recursos a partições que não atendem ao objetivo de utilização especificado.

Este objetivo é especificado usando-se operadores e valores. Os operadores são os seguintes:

<

O operador “less than” indica que o valor especificado representa um valor de destino máximo.

>

O operador “greater than” indica que o valor especificado represente um valor de destino mínimo.

~

O operador “about” indica que o valor especificado é um valor de destino em relação ao qual determinada flutuação é aceitável.

Um pset pode ter somente um objetivo de utilização definido para cada tipo de operador.

• Se o operador ~ estiver definido, os operadores < e > não podem ser definidos.

• Se os operadores < e > estiverem definidos, o operador ~ não pode ser definido. Observe que as configurações do operador < e do operador > não podem se contradizer.

Você pode definir um operador < e um operador > juntos para criar um intervalo. Os valores serão validados para garantir que não se sobreponham.

Exemplo de objetivos de configuração

No exemplo abaixo, poold avalia esses objetivos para o pset:

• O utilization deve ser mantido entre 30 por cento e 80 por cento.

• O locality deve ser maximizado para o conjunto de processadores.

• Os objetivos devem tomar a importância padrão de 1.

Exemplo 12–1 Exemplo de objetivos do poold

pset.poold.objectives "utilization > 30; utilization < 80; locality tight"

Para exemplos adicionais de uso, consulte Como definir objetivos de configuração.

Propriedades do poold

Há quatro categorias de propriedades:

• Configuração

• Restrição

• Objetivo

• Parâmetro de objetivo

As funções de poold que podem ser configuradas

Você pode configurar estes aspectos do comportamento do daemon.

• Monitoração de intervalo

• Nível de registro

• Local de registro

Estas opções estão disponíveis na configuração de grupos. Você também pode controlar o nível de registro a partir da linha de comando chamando poold.

Monitoração de intervalo do poold

Use o nome de propriedade system.poold.monitor-interval para especificar um valor em milissegundos.

Informações de registro do poold

Três categorias de informações são fornecidas através do registro. Essas categorias são identificadas nos logs:

• Configuração

• Monitoração

• Otimização

Use o nome de propriedade system.poold.log-level para especificar o parâmetro de registro. Se esta propriedade não for especificada, o nível de registro padrão será NOTICE. Os níveis de parâmetro são hierárquicos. A definição de um nível de logo de DEBUG fará com que poold registre todas as mensagens definidas. O nível INFO fornece um equilíbrio útil de informações para a maioria dos administradores.

Na linha de comando, você pode usar o comando poold com a opção -l e um parâmetro para especificar o nível de informações de registro gerado.

Os seguintes parâmetros estão disponíveis:

• ALERT

• CRIT

• ERR

• WARNING

• NOTICE

• INFO

• DEBUG

Os níveis de parâmetro mapeiam diretamente sobre os equivalentes de syslog. Para obter mais informações sobre o uso de syslog, consulte Local de registro.

Para obter mais informações sobre como configurar o registro de poold, consulte Como definir o nível de registro de poold.

Registro de informações de configuração

Os seguintes tipos de mensagem podem ser gerados:

ALERT

Problemas ao acessar a configuração libpool, ou alguma outra falha fundamental e imprevista da facilidade libpool. Faz com que o daemon saia e requer atenção imediata do administrador.

CRIT

Problemas devidos a falhas imprevistas. Faz com que o daemon saia e requer atenção imediata do administrador.

ERR

Problemas com os parâmetros especificados pelo usuário que controlam a operação, como objetivos de utilização conflitantes e sem resolução para um conjunto de recursos. Requer intervenção administrativa para conectar os objetivos. poold tenta tomar uma ação corretiva ignorando objetivos conflitantes, mas alguns erros farão com que o daemon saia.

WARNING

Avisos relacionados à definição de parâmetros de configuração, embora tecnicamente corretos, não serão apropriados para o ambiente de execução dado. Um exemplo é tornar todos os recursos de CPU fixos, o que significa que poold não pode mover recursos de CPU entre conjuntos de processadores.

DEBUG

Mensagens que contêm as informações detalhadas necessárias ao se depurar processamento de configuração. Essas informações não são geralmente usadas por administradores.

Monitoração de registro de informações

Os seguintes tipos de mensagem podem ser gerados:

CRIT

Problemas devidos a falhas de monitoração imprevistas. Faz com que o daemon saia e requer atenção imediata do administrador.

ERR

Problemas devidos a erro de monitoração imprevisto. Pode requerer intervenção administrativa para corrigir.

NOTICE

Mensagens sobre transições de região de controle de recurso.

INFO

Mensagens sobre estatística de utilização de recursos.

DEBUG

Mensagens que contêm as informações detalhadas necessárias ao se depurar processamento de monitoração. Essas informações não são geralmente usadas por administradores.

Registro de informações de otimização

Os seguintes tipos de mensagem podem ser gerados:

WARNING

Podem ser exibidas mensagens relativas a problemas de fazer decisões ótimas. Exemplos incluem conjuntos de recursos que são demasiadamente restritos por seus valores mínimo e máximo ou pelo número de componentes fixos.

Podem ser exibidas mensagens sobre problemas ao se executar uma realocação ótima devido a limitações imprevistas. Exemplos incluem a remoção do último processados de um conjunto de processadores que contém um consumidor de recursos vinculado.

NOTICE

Podem ser exibidas mensagens sobre configurações utilizáveis ou configurações que não serão implementadas devido a históricos de decisão de sobreposição.

INFO

Podem ser exibidas mensagens sobre configurações alternativas consideradas.

DEBUG

Mensagens que contêm as informações detalhadas necessárias ao se depurar processamento de otimização. Essas informações não são geralmente usadas por administradores.

Local de registro

A propriedade system.poold.log-location é usada para especificar o local para a saída registrada de poold. Você pode especificar um local de SYSLOG para a saída de poold (consulte syslog(3C)).

Se esta propriedade não for especificada, o local padrão para a saída registrada de poold será /var/log/pool/poold.

Quando poold é chamado a partir da linha de comando, esta propriedade não é usada. Entradas de log são gravadas em stderr no terminal de chamada.

Gerenciamento de log com logadm

Se poold estiver ativo, o arquivo logadm.conf incluirá uma entrada para gerenciar o arquivo padrão /var/log/pool/poold. A entrada é:

/var/log/pool/poold -N -s 512k

Consulte as páginas do manual logadm(1M) e logadm.conf(4).

Como funciona a alocação de recursos dinâmicos

Esta seção explica o processo e os fatores que poold usa para alocar recursos dinamicamente.

Sobre recursos disponíveis

Recursos disponíveis são considerados ser todos os recursos disponíveis para uso dentro do escopo do processo poold. O escopo de controle é no máximo uma única instância do Solaris.

Em um sistema com regiões ativadas, o escopo de uma instância de poold em execução se limita à região global.

Determinação de recursos disponíveis

Grupos de recursos abarcam todos os recursos do sistema disponíveis para consumo pelos aplicativos.

Para uma única instância do Solaris em execução, um recurso de um único tipo, como uma CPU, deve estar alocado a uma única partição. Pode haver uma ou mais partições para cada tipo de recursos. Cada partição contém um conjunto de recursos exclusivo.

Por exemplo, uma máquina com quatro CPUs e dois conjuntos de processadores pode ter a seguinte configuração:

PT 0: 0 1

pset 1: 2 3

onde 0, 1, 2 e 3 após os dois-pontos representam IDs de CPU. Observe que os dois conjuntos de processadores prestam contas às quatro CPUs.

A mesma máquina não pode ter a seguinte configuração:

PT 0: 0 1

pset 1: 1 2 3

Não pode ter esta configuração porque a CPU 1 aparece somente em um pset por vez.

Os recursos são podem ser acessados a partir de qualquer partição que não seja a partição à qual pertencem.

Para descobrir os recursos disponíveis, poold interroga a configuração de grupos ativa para localizar partições. Todos os recursos dentro de todas as partições são somados para determinar a quantidade total de recursos disponíveis para cada tipo de recurso que é controlado.

Esta quantidade de recursos é o número básico que poold usa em suas operações. No entanto, há restrições sobre esse número que limitam a flexibilidade de poold para fazer alocações. Para obter informações sobre restrições disponíveis, consulte Restrições de configuração.

Identificação de uma falta de recurso

O escopo de controle para poold é definido como conjunto de recursos disponíveis pelo qual poold tem responsabilidade primária para a partição e o gerenciamento eficazes. No entanto, outros mecanismos que têm permissão para manipular recursos dentro do escopo de controle ainda podem afetar uma configuração. Se uma partição tiver de ficar fora de controle enquanto poold está ativo, poold tenta restaurar o controle através de uma manipulação judiciosa de recursos disponíveis. Se poold não localizar recursos adicionais dentro de seu escopo, o daemon irá registrar informações sobre a falta de recursos.

Determinação de utilização de recurso

poold normalmente passa a maior parte do tempo observando o uso dos recursos dentro de seu escopo de controle. Esta monitoração se destina a verificar se os objetivos dependentes de carga de trabalho estão sendo alcançados.

Por exemplo, para conjuntos de processadores, todas as medidas são feitas em todos os processadores em um conjunto. A utilização de recursos mostra a proporção de tempo que o recurso está em uso durante o intervalo de amostragem. A utilização de recursos é exibida como uma porcentagem de 0 a 100.

Identificação de violações de controle

As diretivas descritas em Configuração de restrições e objetivos são usadas para detectar a falha próxima de um sistema para atender seus objetivos. Esses objetivos estão relacionados diretamente à carga de trabalho.

Uma partição que não esteja atendendo os objetivos configurados pelo usuário é uma violação de controle. Os dois tipos de violações de controle são síncronos e assíncronos.

• Uma violação síncrona de um objetivo é detectada pelo daemon durante a monitoração da carga de trabalho.

• Uma violação assíncrona de um objetivo ocorre independentemente da ação de monitoração pelo daemon.

Os seguintes eventos causam violações de objetivo assíncronas:

• Recursos são adicionados a um escopo de controle ou dele removidos.

• O escopo de controle é reconfigurado.

• O controlador de recursos poold é reiniciado.

As contribuições de objetivos que não estão relacionadas à carga de trabalho permanecem constantes entre as avaliações da função do objetivo. Os objetivos que não estão relacionados à carga de trabalho são somente reavaliados quando uma reavaliação é acionada através de uma das violações assíncronas.

Determinação de uma ação corretiva apropriada

Quando o controlador de recursos determina que um consumidor de recurso não tem recursos suficientes, a resposta inicial é que o aumento de recursos irá melhorar o desempenho.

Configurações alternativas que atendem os objetivos especificados na configuração para o escopo do controle são examinadas e avaliadas.

Este processo refinado ao longo do tempo enquanto os resultados de movimentação de recursos são monitorizados e a resposta de cada partição de recurso é avaliada. O histórico de decisão é consultado para eliminar reconfigurações que não mostraram melhoras no atendimento da função do objetivo no passado. Outras informações, como nomes de processo e quantidades, são usadas para nova avaliação da relevância dos dados do histórico.

Se o daemon não puder tomar uma ação corretiva, a condição será registrada. Para obter mais informações, consulte Informações de registro do poold.

Uso de poolstat para monitorar a facilidade de grupos e a utilização de recursos

O utilitário poolstat é usado para monitorar a utilização de recursos quando grupos são ativados no sistema. Este utilitário examina interativamente todos os grupos ativos em um sistema e relata estatísticas baseadas no modo de saída selecionado. As estatísticas poolstat permitem que você determine quais partições de recursos são intensamente usadas. Você pode analisar essas estatísticas para tomar decisões sobre realocação de recursos quando o sistema estiver sob pressão para recursos.

O utilitário poolstat inclui opções que podem ser usadas para examinar grupos específicos e relatar estatísticas específicas de conjuntos de recursos.

Se regiões estiverem implementadas no sistema e você usar poolstat em uma região não global, serão exibidas informações sobre os recursos associados ao grupo da região.

Para obter mais informações sobre o utilitário poolstat, consulte a página do manual poolstat(1M) Para obter informações sobre tarefas e usos de poolstat, consulte Uso de poolstat para relatar estatísticas para recursos relacionados a grupos.

Saída de poolstat

No formato de saída padrão, poolstat envia uma linha de cabeçalho e, em seguida, exibe uma linha para cada grupo. Uma linha de grupo começa com um ID de grupo e o nome do grupo, seguida de uma coluna de dados estatísticos para o conjunto de processadores anexado ao grupo. Conjuntos de recursos anexados a mais de um grupo são listados várias vezes, uma para cada grupo.

Os cabeçalhos de coluna são os seguintes:

id

ID do grupo.

pool

Nome do grupo.

rid

ID do conjunto de recursos.

rset

Nome do conjunto de recursos.

type

Tipo do conjunto de recursos.

min

Tamanho mínimo do conjunto de recursos.

max

Tamanho máximo do conjunto de recursos.

size

Tamanho atual do conjunto de recursos.

used

Medida da quantidade do conjunto de recursos usada atualmente.

Este uso é calculado como a porcentagem de utilização do conjunto de recursos multiplicada pelo tamanho do conjunto de recursos. Se um conjunto de recursos foi reconfigurado durante o último intervalo de amostragem, este valor poderá não ser relatado. Um valor não relatado aparece como um hífen (-).

load

Representação absoluta da carga que é colocada no conjunto de recursos.

Para obter mais informações sobre esta propriedade, consulte a página do manual libpool(3LIB).

Você pode especificar o seguinte na saída de poolstat:

• A ordem das colunas

• Os cabeçalhos que aparecem

Ajuste de intervalos de operação de poolstat

Você pode personalizar as operações executadas por poolstat. Você pode definir o intervalo de amostragem para o relatório e especificar o número de vezes que a estatística será repetida:

interval

Ajuste os intervalos para as operações periódicas executadas por poolstat. Todos os intervalos são especificados em segundos.

count

Especifique o número de vezes que a estatística será repetida. Por padrão, poolstat relata estatísticas somente uma vez.

Se interval e count não forem especificados, a estatística será relatada uma vez. Se interval estiver especificado mas count não estiver especificado, a estatística será relatada indefinidamente.

Comandos usados com a facilidade de grupos de recursos

Os comandos descritos na tabela abaixo fornecem a interface administrativa primária à facilidade de grupos. Para obter informações sobre o uso desses comandos em um sistema com regiões ativadas, consulte Grupos de recursos usados em regiões.

Uma biblioteca API é fornecida por libpool (consulte a página do manual libpool(3LIB) A biblioteca pode ser usada por programas para manipular configurações de grupos.