Parte I Gerenciamento de recursos

Esta parte introduz o gerenciador de recurso do Solaris 10, que permite que você controle como os aplicativos utilizam os recursos de sistema disponíveis.

Capítulo 1 Introdução ao gerenciador de recursos do Solaris 10

A funcionalidade de gerenciamento de recursos é um componente do ambiente do recipiente do Solaris. O gerenciamento de recursos permite que você controle como os aplicativos usam recursos de sistema disponíveis. Você pode:

• Alocar recursos de computação, como tempo de processador

• Monitorar como as alocações são usadas e, em seguida, ajustar as alocações, conforme necessário

• Gerar informações de contabilidade estendida para análise, fatura e planejamento de capacidade

Este capítulo aborda os seguintes tópicos:

• Visão geral do gerenciamento de recursos

• Quando usar o gerenciamento de recursos

• Configuração do gerenciamento de recursos (mapa de tarefas)

Visão geral do gerenciamento de recursos

Os ambientes de computação modernos devem fornecer uma resposta flexível às variadas cargas de trabalho geradas por diferentes aplicativos em um sistema. Uma carga de trabalho é uma agregação de todos os processos de um aplicativo ou grupo de aplicativos. Se as facilidades de gerenciamento de recursos não forem usadas, o Solaris Operating System responderá às demandas das cargas de trabalho adaptando-se dinamicamente a novas solicitações de aplicativos. Esta resposta padrão em geral significa que todas as atividades no sistema recebem acesso igual a recursos. As facilidades de gerenciamento de recursos do Solaris permitem que você lide com cargas de trabalho individualmente. Você pode:

• Restringir acesso a um recurso específico

• Oferecer recursos a cargas de trabalho em uma base preferencial

• Isolar cargas de trabalho de cada uma

A capacidade de minimizar comprometimentos de desempenho entre cargas de trabalho, juntamente com os recursos que monitorem uso e utilização, é chamada de gerenciamento de recursos. O gerenciamento de recursos é implementado através de uma coleção de algoritmos. Os algoritmos manipulam a série de solicitações de capacidade que um aplicativo apresenta ao longo de sua execução.

As facilidades de gerenciamento de recursos permitem que você modifique o comportamento padrão do sistema operacional com relação a diferentes cargas de trabalho. O comportamento se refere primeiramente ao conjunto de decisões tomadas por algoritmos do sistema operacional quando um aplicativo apresenta uma ou mais solicitações ao sistema. Você pode usar as facilidades do gerenciamento de recursos para fazer o seguinte:

• Negar recursos ou preferir um aplicativo a outro para um maior conjunto de alocações do que de outro modo seria permitido

• Lidar com determinadas alocações coletivamente, em vez de através de mecanismos isolados

A implementação de uma configuração de sistema que usa as facilidades de gerenciamento de recursos pode servir a diversos propósitos. Você pode:

• Impedir que um aplicativo consuma recursos indiscriminadamente

• Alterar a prioridade de um aplicativo com base em eventos externos

• Equilibrar garantias de recursos a um conjunto de aplicativos com o objetivo de maximizar a utilização do sistema

Ao se planejar uma configuração gerenciada por recursos, há os seguintes requisitos-chave:

• Identificação de cargas de trabalho concorrentes no sistema

• Distinção de cargas de trabalho que não estão em conflito das cargas de trabalho com requisitos de desempenho que comprometem as cargas de trabalho principais

Após identificar cargas de trabalho cooperativas e conflitantes, você pode criar uma configuração de recurso que apresenta o menor comprometimento dos objetivos do serviço da atividade, dentro dos limites das capacidades do sistema.

Um gerenciamento de recursos eficaz é possibilitado no sistema do Solaris ao oferecer mecanismos de controle, mecanismos de notificação e mecanismos de monitoração. Várias dessas capacidades são fornecidas através de aprimoramentos dos mecanismos existente, como o sistema de arquivos proc(4), conjuntos de processadores e classes de agendamento. Outras capacidades são específicas do gerenciamento de recursos. Essas capacidades são descritas nos próximos capítulos.

Classificações de recursos

Um recurso é qualquer aspecto do sistema de computação que pode ser manipulado com o propósito de alterar o comportamento do aplicativo. Assim, um recurso é uma capacidade que um aplicativo solicita implícita ou explicitamente. Se a capacidade for negada ou restringida, a execução de um aplicativo escrito robustamente se dá mais lentamente.

A classificação de recursos, em oposição à identificação de recursos, pode ser feita ao longo de diversos eixos. Os eixos podem ser solicitados implicitamente, em vez de explicitamente, com base no tempo, como o tempo da CPU, comparado com a independência do tempo, como compartilhamentos de CPU atribuídos, e assim por diante.

Em geral, o gerenciamento de recursos com base no agendador é aplicado a recursos que o aplicativo pode solicitar implicitamente. Por exemplo, para continuar a execução, um aplicativo solicita implicitamente tempo de CPU adicional. Para gravar dados em um soquete de rede, um aplicativo solicita implicitamente largura de banda. Restrições podem ser impostas ao uso total agregado de um recurso solicitado implicitamente.

Interfaces adicionais podem ser apresentadas, de modo que a largura de banda ou os níveis de serviço da CPU possam ser negociados explicitamente. Recursos solicitados explicitamente, como a solicitação de um segmento adicional, podem ser gerenciados por restrição.

Mecanismos de controle do gerenciamento de recursos

Os três tipos de mecanismos de controle que estão disponíveis no Solaris Operating System são restrições, agendamento e partição.

Mecanismos de restrição

Restrições permitem que o administrador ou o desenvolvedor de aplicativos definam limites no consumo de recursos específicos para uma carga de trabalho. Com limites conhecidos, a modelagem de cenários de consumo de recursos se torna um processo mais simples. Limites também podem ser usados para controlar aplicativos que se comportam mal e que de outro modo comprometeriam o desempenho do sistema ou a disponibilidade através de solicitações de recursos não reguladas.

As restrições apresentam complicações para o aplicativo. O relacionamento entre o aplicativo e o sistema pode ser modificado ao ponto de o aplicativo não poder mais funcionar. Uma abordagem que pode mitigar este risco é reduzir gradualmente as restrições a aplicativos com comportamento de recursos desconhecido. Os controles de recursos tratados no Capítulo 6Controles de recursos (visão geral) oferecem um mecanismo de restrição. Aplicativos mais novos podem ser escritos para reconheçam as restrições de recursos, mas nem todos os autores de aplicativos escolhem fazê-lo.

Mecanismos de agendamento

O agendamento se refere a fazer uma seqüência de decisões de alocações a intervalos específicos. A decisão feita é baseada em um algoritmo previsível. Um aplicativo que não necessita da alocação atual deixa os recursos disponíveis para uso por outros aplicativos. O gerenciamento de recursos com base em agendamento permite a utilização total de uma configuração pouco comprometida, ao mesmo tempo que fornece alocações controladas em um cenário criticamente comprometido ou comprometido em excesso. O algoritmo subjacente define como o termo “controlado” é interpretado. Em algumas instâncias, o algoritmo de agendamento pode garantir que todos os aplicativos tenham algum acesso ao recurso. O fair share scheduler (FSS), descrito no Capítulo 8Fair share scheduler (visão geral), gerencia o acesso de um aplicativo aos recursos de CPU de uma forma controlada.

Mecanismos de partição

A partição é usada para vincular uma carga de trabalho a um subconjunto dos recursos disponíveis do sistema. Essa vinculação garante que uma quantidade conhecida de recursos esteja sempre disponível para a carga de trabalho. A funcionalidade de grupos de recursos, descrita no Capítulo 12Grupos de recursos (visão geral), permite que você limite cargas de trabalho para subconjuntos específicos da máquina.

Configurações que usam partição podem evitar o comprometimento excessivo no sistema geral. No entanto, ao evitar esse comprometimento excessivo, a capacidade de se alcançar altas utilizações pode ser reduzida. Um grupo de recursos reservado, como processadores, não está disponível para uso por outra carga de trabalho quando a carga de trabalho vinculada a eles está ociosa.

Configuração de gerenciamento de recurso

Partes da configuração do gerenciamento de recursos podem ser colocadas em um serviço de nomes de rede. Esta função permite que o administrador aplique restrições de gerenciamento de recursos a uma coleção de máquinas, e não na base de uma máquina exclusivamente. Um trabalho relacionado pode compartilhar um identificador comum, e o uso agregado desse trabalho pode ser tabulado a partir de dados de contabilidade.

A configuração do gerenciamento de recursos e os identificadores orientados para cargas de trabalho são descritos com mais detalhes no Capítulo 2Projetos e tarefas (visão geral). A facilidade da contabilidade estendida que vincula esses identificadores com o uso de recursos de aplicativos é descrita no Capítulo 4Contabilidade estendida (visão geral).

Interação com o Solaris Zones

As facilidades de gerenciamento de recursos podem ser usadas com o Solaris Zones para aprimorar ainda mais o ambiente do aplicativo. As interações entre essas facilidades e regiões são descritas nas seções aplicáveis neste guia.

Quando usar o gerenciamento de recursos

Use o gerenciamento de recursos para assegurar que os aplicativos têm os tempos de resposta necessários.

O gerenciamento de recursos também pode aumentar a utilização de recursos. Ao categorizar e priorizar o uso, você pode usar com eficácia capacidade de reserva durante períodos fora de pico, com freqüência eliminando a necessidade de potência de processamento adicional. Você também pode assegurar que os recursos não sejam desperdiçados devido à variabilidade das cargas.

Consolidação do servidor

O gerenciamento de recursos é ideal para ambientes que consolidam diversos aplicativos em um único servidor.

O custo e a complexidade do gerenciamento de diversas máquinas incentiva a consolidação de vários aplicativos em servidores maiores e mais escaláveis. Em vez de executar cada carga de trabalho em um sistema separado, com total acesso aos recursos desse sistema, você pode usar o software de gerenciamento de recursos para segregar cargas de trabalho dentro do sistema. O gerenciamento de recursos permite que você baixe o custo total de propriedade ao executar e controlar diversos aplicativos diferentes em um único sistema do Solaris.

Se estiver fornecendo serviços de Internet e aplicativos, você pode usar o gerenciamento de recursos para fazer o seguinte:

• Hospedar vários serviços Web em uma única máquina. Você pode controlar o consumo de recursos para cada site da Web e pode proteger cada site contra os excessos potenciais de outros sites.

• Impedir que um script incorreto da interface de gateway comum (CGI) exaure os recursos da CPU.

• Fazer com que um aplicativo que se comporte incorretamente pare de vazar toda a memória virtual disponível.

• Assegurar que um aplicativo cliente não seja afetado por outro aplicativo cliente executado no mesmo site.

• Fornecer níveis ou classes de serviço diferenciados na mesma máquina.

• Obter informações de contabilidade para propósitos de fatura.

Suporte a uma população grande ou variada de usuários

Use as facilidades de gerenciamento de recursos em qualquer sistema que tenha uma base de usuário grande e diversificada, como em uma instituição educacional. Se você tiver uma mistura de cargas de trabalho, o software pode ser configurado para dar prioridade a projetos específicos.

Por exemplo, em firmas de corretagem grandes, os corretores precisam constantemente de acesso rápido para executar uma consulta ou para fazer um cálculo. Outros usuários de sistema, no entanto, têm cargas de trabalho mais consistentes. Se você alocar uma quantidade proporcionalmente grande de potência de processamento aos projetos de agentes, os agentes terão a resposta de que necessitam.

O gerenciamento de recursos é também ideal para oferecer suporte a sistemas thin-client. Essas plataformas oferecem consoles sem informações de estado com buffers de quadro e dispositivos de entrada, como placas inteligentes. A computação atual é feita em um servidor compartilhado, resultando em um tipo de compartilhamento de tempo de ambiente. Use as facilidades de gerenciamento de recursos para isolar os usuários no servidor. Com isso, um usuário que gere carga excessiva não monopolizará recursos de hardware nem exercerá um impacto significativo sobre outros que usem o sistema.

Configuração do gerenciamento de recursos (mapa de tarefas)

O mapa de tarefas a seguir fornece uma visão geral de nível superior das etapas envolvidas na configuração do gerenciamento de recursos no sistema.

Capítulo 2 Projetos e tarefas (visão geral)

Este capítulo trata das facilidades de projeto e tarefa do gerenciamento de recurso do Solaris. Projetos e tarefas são usados para rotular cargas de trabalho e separá-las umas das outras.

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

• Facilidades de projeto e tarefa

• Identificadores de projeto

• Identificadores de tarefa

• Comandos usados com projetos e tarefas

Para usar as facilidades de projeto e tarefas, consulte o Capítulo 3Administração de projetos e tarefas.

O que há de novo no banco de dados de projeto e comandos do controle de recursos do Solaris 10?

As melhorias do Solaris 10 incluem o seguinte:

• Suporte a valor de escala e modificador de unidade para valores e comandos do controle de recursos

• Validação aperfeiçoada e manipulação mais fácil do campo de atributos de projeto

• Formato de saída revisada e novas opções para os comandos prctl e projects

• Capacidade de definir projeto padrão de usuário através do comando useradd e de modificar informações usando os comandos usermod e passmgmt

Além das informações contidas neste capítulo e no Capítulo 6Controles de recursos (visão geral), consulte as seguintes páginas do manual:

• passmgmt(1M)

• projadd(1M)

• projmod(1M)

• useradd(1M)

• usermod(1M)

• resource_controls(5)

As melhorias do Solaris 10 5/08 incluem a adição de uma opção -A ao comando projmod. Consulte Comandos usados com projetos e tarefas.

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.

Facilidades de projeto e tarefa

Para otimizar a resposta da carga de trabalho, é necessário primeiro poder identificar as cargas de trabalho que estão em execução no sistema que você está analisando. Pode ser difícil de obter esta informação usando um isoladamente um método puramente orientado a processo ou orientado a usuário. No sistema do Solaris, há duas facilidades adicionais que podem ser usadas para separar e identificar cargas de trabalho: o projeto e a tarefa. O projeto fornece um identificador administrativo da rede geral para trabalhos relacionados. A tarefa coleta um grupo de processos em uma entidade gerenciável que representa um componente de carga de trabalho.

Os controles especificados no banco de dados do serviço de nome do project são definidos no processo, na tarefa e no projeto. Uma vez que controles de processo e tarefa são herdados nas chamadas do sistema fork e settaskid, todos os processos e tarefas criados dentro do projeto herdam esses controles. Para obter informações sobre essas chamadas do sistema, consulte as páginas do manual fork(2) e settaskid(2).

Com base na associação ao projeto ou à tarefa, os processos em execução podem ser manipulados com comandos padrão do Solaris. A facilidade da contabilidade estendida pode relatar uso de processo e uso de tarefa, e etiquetar cada registro com o identificador de projeto em vigor. Esse processo permite que a análise de carga de trabalho off-line seja correlacionada com a monitoração on-line. O identificador de projeto pode ser compartilhado em várias máquinas através do banco de dados do serviço de nome do project. Assim, o consumo de recursos de cargas de trabalho relacionadas que são executados (ou abarcados) em várias máquinas pode, basicamente, ser analisado em todas as máquinas.

Identificadores de projeto

O identificador de projeto é um identificador administrativo usado para identificar trabalho relacionado. Pode-se dizer que o identificador de projeto é uma etiqueta de carga de trabalho equivalente aos identificadores de usuário e grupo. Um usuário ou grupo pertence a um ou mais projetos. Esses projetos podem ser usados para representar as cargas de trabalho nas quais o usuário (ou grupo de usuários) tem permissão para participar. Essa associação pode então ser a base do chargeback que é baseado, por exemplo, em uso ou alocações iniciais de recursos. Embora um usuário tenha de ser atribuído a um projeto padrão, os processos que o usuário inicia podem ser associados a qualquer projeto de qual o usuário seja um membro.

Determinação do projeto padrão de um usuário

Para efetuar login no sistema, um usuário tem de ser atribuído a um projeto padrão. Um usuário é automaticamente um membro desse projeto padrão, mesmo que o usuário não esteja na lista de usuários ou de grupo especificada nesse projeto.

Uma vez que cada processo no sistema possui associação ao projeto, é necessário um algoritmo para atribuir um projeto padrão ao login ou outro processo inicial. O algoritmo é documentado na página do manual getprojent(3C). O sistema segue as etapas ordenadas para determinar o projeto padrão. Se nenhum projeto for localizado, o login de usuário, ou a solicitação para iniciar um processo, será negado.

O sistema segue seqüencialmente estas etapas para determinar o projeto padrão de um usuário:

1. Se o usuário tiver uma entrada com um atributo project definido no banco de dados de atributos de usuário estendido /etc/user_attr, o valor do atributo project será o projeto padrão. Consulte a página do manual user_attr(4).

2. Se um projeto com o nome user.user-id estiver presente no banco de dados de project, esse projeto será o projeto padrão. Consulte a página do manual project(4) para obter mais informações.

3. Se um projeto com o nome group. group-name estiver presente no banco de dados de project, onde group-name é o nome do grupo padrão para o usuário, como especificado no arquivo passwd, esse projeto será o projeto padrão. Para obter informações sobre o arquivo passwd, consulte a página do manual passwd(4).

4. Se o projeto especial default estiver presente no banco de dados de project, esse projeto será o projeto padrão.

Esta lógica é fornecida pela função de biblioteca getdefaultproj. () Para obter mais informações, consulte a página do manual getprojent(3PROJECT).

Definição de atributos de usuário com os comandos useradd , usermod e passmgmt

Você pode usar os seguintes comandos com a opção -K e um par key=value para definir atributos de usuário em arquivos locais:

passmgmt

Modificar informações de usuário

useradd

Definir projeto padrão para usuário

usermod

Modificar informações de usuário

Arquivos locais incluem o seguinte:

• /etc/group

• /etc/passwd

• /etc/project

• /etc/shadow

• /etc/user_attr

Se um serviço de nomes de rede, como NIS, estiver sendo usado para suplementar o arquivo local com entradas adicionais, estes comandos não podem alterar informações fornecidas pelo serviço de nomes de rede. No entanto, os comandos verificam o seguinte em relação ao bando de dados de serviço de nomes externo:

• Exclusividade do nome de usuário (ou função)

• Exclusividade do ID de usuário

• Existência de quaisquer nomes de grupo especificados

Para obter mais informações, consulte as páginas do manual passmgmt(1M), useradd(1M), usermod(1M) e user_attr(4).

Banco de dados de project

Você pode armazenar dados de projeto em um arquivo local, em um mapa de projeto do Serviço de informação de rede (NIS), ou em um serviço de diretório de Protocolo de acesso a pastas leves (LDAP). O arquivo /etc/project ou o serviço de identificação é usado no login e por todas as solicitações para gerenciamento de conta pelo Módulo de autenticação plugável (PAM) para vincular um usuário a um projeto padrão.

Atualizações de entradas no banco de dados de projeto, seja para o arquivo /etc/project ou para a representação do banco de dados em um serviço de identificação de rede, não são aplicadas aos projetos atualmente ativos. As atualizações são aplicadas a novas tarefas que se unem ao projeto quando o comando login ou newtask é usado. Para obter mais informações, consulte as páginas do manual login(1) e newtask(1).

Subsistema de PAM

Operações que alteram ou definem identidade incluem login em um sistema, chamar um comando rcp ou rsh, usando ftp, ou usandosu. Quando uma operação envolve alterar ou definir uma identidade, um conjunto de módulos configuráveis é usado para fornecer autenticação, gerenciamento de conta, gerenciamento de credenciais e gerenciamento de sessão.

O módulo PAM de gerenciamento de conta para projetos é documentado na página do manual pam_projects(5) Para uma visão geral de PAM, consulte o Capítulo 17, Using PAM, no System Administration Guide: Security Services.

Configuração de serviços de identificação

O gerenciamento de recursos oferece suporte a bancos de dados de project de serviço de identificação. O local em que o banco de dados de project é armazenado é definido no arquivo /etc/nsswitch.conf. Por padrão, files é listado primeiro, mas as fontes podem ser listadas em qualquer ordem.

project: files [nis] [ldap]

Se mais de uma fonte para informações de projeto estiver listada, o arquivo nsswitch.conf direcionará a rotina para iniciar a procura de informações na primeira fonte listada e em seguida pesquisará fontes subseqüentes.

Para obter mais informações sobre o arquivo /etc/nsswitch.conf, consulte o Capítulo 2, The Name Service Switch (Overview), no System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) e em nsswitch.conf(4).

Formato de arquivo /etc/project local

Se você selecionar files como fonte do banco de dados de project no arquivo nsswitch.conf, o processo de login procurará informações do projeto no arquivo /etc/project. Para obter mais informações, consulte as páginas do manual projects(1) e project(4).

O arquivo project contém uma entrada de uma linha da seguinte forma para cada projeto reconhecido pelo sistema:

projname:projid:comment:user-list:group-list:attributes

Os campos são definidos como a seguir:

projname

O nome do projeto. O nome deve ser uma seqüência formada por caracteres alfanuméricos, caractere sublinhado (_), hifens (-) e pontos (.). O ponto, que é reservado para projetos com significado especial para o sistema operacional, podem somente ser usados nos nomes de projetos padrão para usuários. projname não pode conter dois-pontos (: ) ou caracteres de mudança de linha.

projid

O ID numérico exclusivo do projeto (PROJID) dentro do sistema. O valor máximo do campo projid é UID_MAX ( 2147483647).

comment

Uma descrição do projeto.

user-list

Uma lista separada por vírgulas de usuários que têm permissão para o projeto.

Curingas podem ser usados neste campo. Um asterisco (*) permite que todos os usuários se unam ao projeto. Um ponto de exclamação seguido por um asterisco (!*) exclui todos os usuários do projeto. Um ponto de exclamação (!) seguido por um nome de usuário exclui do projeto o usuário especificado.

group-list

Uma lista separada por vírgulas de grupos de usuários que tem permissão para o projeto.

Curingas podem ser usados neste campo. Um asterisco (*) permite que todos os grupos se unam ao projeto. Um ponto de exclamação seguido por um asterisco (!*) exclui todos os grupos do projeto. Um ponto de exclamação (!) seguido por um nome de grupo exclui do projeto o grupo especificado.

attributes

Uma lista de pares de nome-valor separada por ponto-e-vírgula, como controles de recursos (consulte o Capítulo 6Controles de recursos (visão geral)). name é uma seqüência arbitrária que especifica o atributo relacionado a objeto, e value é o valor opcional para esse atributo.

name[=value]

No par nome-valor, nomes são limitados a letras, dígitos, sublinhados e pontos. Um ponto é convencionalmente usado como um separador entre as categorias e subcategorias do controle de recursos (rctl). O primeiro caractere de um nome de atributo deve ser uma letra. O nome diferencia maiúsculas de minúsculas.

Valores podem ser estruturados pelo uso de vírgulas e parênteses para estabelecer precedência.

Um ponto-e-vírgula é usado para separar pares nome-valor. Um ponto-e vírgula não pode ser usado em uma definição de valor. Dois-pontos é usado para separar campos de projeto. Dois-pontos não pode ser usado em uma definição de valor.

Rotinas que lêem este arquivo são interrompidas quando encontram uma entrada incorreta. Não há atribuição para quaisquer projetos que sejam especificados após a entrada incorreta.

Este exemplo mostra o arquivo padrão /etc/project:

system:0:System:::
user.root:1:Super-User:::
noproject:2:No Project:::
default:3::::
group.staff:10::::

Este exemplo mostra o arquivo padrão /etc/project com entradas de projeto adicionadas no fim:

system:0:System:::
user.root:1:Super-User:::
noproject:2:No Project:::
default:3::::
group.staff:10::::
user.ml:2424:Lyle Personal:::
booksite:4113:Book Auction Project:ml,mp,jtd,kjh::

Você também pode adicionar controles de recursos e atributos ao arquivo /etc/project :

• Para adicionar controles de recursos para um projeto, consulte Configuração de controles de recursos.

• Para definir um limite de recursos da memória física para um projeto usando o resource capping daemon descrito em rcapd(1M), consulte Atributo para limitar o uso da memória física em projetos.

• Para adicionar um atributo project.pool à entrada de um projeto, consulte Criação da configuração.

Configuração de projeto para NIS

Se estiver usando NIS, você pode especificar no arquivo /etc/nsswitch.conf a procura de projetos nos mapas de projeto NIS:

project: nis files 

Os mapas NIS, project.byname ou project.bynumber , têm a mesma forma que o arquivo /etc/project:

projname:projid:comment:user-list:group-list:attributes

Para obter mais informações, consulte o Capítulo 4, Network Information Service (NIS) (Overview), no System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .

Configuração de projeto para LDAP

Se estiver usando LDAP, você pode especificar no arquivo /etc/nsswitch.conf que procure projetos no banco de dados de project de LDAP:

project: ldap files

Para obter mais informações sobre LDAP, consulte o Capítulo 8, Introduction to LDAP Naming Services (Overview/Reference), no System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) . Para obter mais informações sobre o esquema para entradas de projeto em um banco de dados de LDAP, consulte Solaris Schemas no System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) .

Identificadores de tarefa

Cada login bem-sucedido em um projeto cria uma nova tarefa que contém o processo de login. A tarefa é um processo coletivo que representa um conjunto de trabalhos ao longo do tempo. Uma tarefa também pode ser vista como um componente de carga de trabalho. A cada tarefa é automaticamente atribuído um ID de tarefa.

Cada processo é um membro de uma tarefa, e cada tarefa é associada a um projeto.

Figura 2–1 Árvore de projeto e tarefa

Todas as operações em grupos de processos, como entrega de sinal, também têm suporte em tarefas. Você também pode vincular uma tarefa a um conjunto de processadores e definir uma prioridade e uma classe de agendamento para uma tarefa, o que modifica todos os processos atuais e subseqüentes na tarefa.

Uma tarefa é criada sempre que um projeto é unido. As ações, os comandos e as funções seguintes criam tarefas:

• login

• cron

• newtask

• setproject

• su

Você pode criar uma tarefa finalizada usando um dos métodos abaixo. Todas as outras tentativas de criar novas tarefas irão falhar.

• Você pode usar o comando newtask com a opção - F.

• Você pode definir o atributo task.final em um projeto no banco de dados do serviço de identificação de project. Todas as tarefas criadas nesse projeto por setproject têm o sinalizador TASK_FINAL.

Para obter mais informações, consulte as páginas do manual login(1), newtask(1), cron(1M), su(1M) e setproject(3PROJECT).

A facilidade de contabilidade estendida pode fornecer dados de contabilidade para processos. Os dados são agregados no nível da tarefa.

Comandos usados com projetos e tarefas

Os comandos mostrados na tabela abaixo fornecem a interface administrativa primária para as facilidades de projeto e tarefa.

Capítulo 3 Administração de projetos e tarefas

Este capítulo descreve como usar as facilidades de projeto e tarefa do gerenciamento de recurso do Solaris.

Os tópicos a seguir são tratados.

• Exemplos de comandos e opções de comando

• Administração de projetos

Para uma visão geral das facilidades de projetos e tarefas, consulte o Capítulo 2Projetos e tarefas (visão geral).

Se você estiver usando estas facilidade em um sistema do Solaris com regiões instaladas, somente processos na mesma região serão visíveis através das interfaces de chamada do sistema que tomam IDs de processo quando estes comandos são executados em uma região não global.

Administração de projetos e tarefas (mapa de tarefas)

Exemplos de comandos e opções de comando

Esta seção fornece exemplos de comando e opções usados com projetos e tarefas.

Opções de comando usadas com projetos e tarefas

Comando ps

Use o comando ps com a opção -o para exibir IDs de tarefas e projetos. Por exemplo, para visualizar o ID do projeto, digite o seguinte:

# ps -o user,pid,uid,projid
USER PID   UID  PROJID
jtd  89430 124  4113

Comando id

Use o comando id com a opção -p para imprimir o ID de projeto atual, além dos IDs de usuário e grupo. Se o operando user for fornecido, o projeto associado a esse logo normal de usuário será impresso:

#  id -p
uid=124(jtd) gid=10(staff) projid=4113(booksite)

Comandos pgrep e pkill

Para coincidir somente processos com um ID de projeto em uma lista específica, use os comandos pgrep e pkill com a opção -J:

# pgrep -J projidlist
# pkill -J projidlist

Para coincidir somente processos com um ID de tarefa em uma lista específica, use os comandos pgrep e pkill com a opção -T:

# pgrep -T taskidlist
# pkill -T taskidlist

Comando prstat

Para exibir várias estatísticas para processos e projetos atualmente em execução no sistema, use o comando prstat com a opção - J:

% prstat -J
	  PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
 21634 jtd      5512K 4848K cpu0    44    0   0:00.00 0.3% prstat/1
   324 root       29M   75M sleep   59    0   0:08.27 0.2% Xsun/1
 15497 jtd        48M   41M sleep   49    0   0:08.26 0.1% adeptedit/1
   328 root     2856K 2600K sleep   58    0   0:00.00 0.0% mibiisa/11
  1979 jtd      1568K 1352K sleep   49    0   0:00.00 0.0% csh/1
  1977 jtd      7256K 5512K sleep   49    0   0:00.00 0.0% dtterm/1
   192 root     3680K 2856K sleep   58    0   0:00.36 0.0% automountd/5
  1845 jtd        24M   22M sleep   49    0   0:00.29 0.0% dtmail/11
  1009 jtd      9864K 8384K sleep   49    0   0:00.59 0.0% dtwm/8
   114 root     1640K  704K sleep   58    0   0:01.16 0.0% in.routed/1
   180 daemon   2704K 1944K sleep   58    0   0:00.00 0.0% statd/4
   145 root     2120K 1520K sleep   58    0   0:00.00 0.0% ypbind/1
   181 root     1864K 1336K sleep   51    0   0:00.00 0.0% lockd/1
   173 root     2584K 2136K sleep   58    0   0:00.00 0.0% inetd/1
   135 root     2960K 1424K sleep    0    0   0:00.00 0.0% keyserv/4
PROJID    NPROC  SIZE   RSS MEMORY      TIME  CPU PROJECT
    10       52  400M  271M    68%   0:11.45 0.4% booksite
     0       35  113M  129M    32%   0:10.46 0.2% system

Total: 87 processes, 205 lwps, load averages: 0.05, 0.02, 0.02

Para exibir várias estatísticas para processos e tarefas atualmente em execução no sistema, use o comando prstat com a opção -T:

% prstat -T
   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
 23023 root       26M   20M sleep   59    0   0:03:18 0.6% Xsun/1
 23476 jtd        51M   45M sleep   49    0   0:04:31 0.5% adeptedit/1
 23432 jtd      6928K 5064K sleep   59    0   0:00:00 0.1% dtterm/1
 28959 jtd        26M   18M sleep   49    0   0:00:18 0.0% .netscape.bin/1
 23116 jtd      9232K 8104K sleep   59    0   0:00:27 0.0% dtwm/5
 29010 jtd      5144K 4664K cpu0    59    0   0:00:00 0.0% prstat/1
   200 root     3096K 1024K sleep   59    0   0:00:00 0.0% lpsched/1
   161 root     2120K 1600K sleep   59    0   0:00:00 0.0% lockd/2
   170 root     5888K 4248K sleep   59    0   0:03:10 0.0% automountd/3
   132 root     2120K 1408K sleep   59    0   0:00:00 0.0% ypbind/1
   162 daemon   2504K 1936K sleep   59    0   0:00:00 0.0% statd/2
   146 root     2560K 2008K sleep   59    0   0:00:00 0.0% inetd/1
   122 root     2336K 1264K sleep   59    0   0:00:00 0.0% keyserv/2
   119 root     2336K 1496K sleep   59    0   0:00:02 0.0% rpcbind/1
   104 root     1664K  672K sleep   59    0   0:00:03 0.0% in.rdisc/1
TASKID    NPROC  SIZE   RSS MEMORY      TIME  CPU PROJECT                     
   222       30  229M  161M    44%   0:05:54 0.6% group.staff                 
   223        1   26M   20M   5.3%   0:03:18 0.6% group.staff                 
    12        1   61M   33M   8.9%   0:00:31 0.0% group.staff                 
     1       33   85M   53M    14%   0:03:33 0.0% system                      

Total: 65 processes, 154 lwps, load averages: 0.04, 0.05, 0.06	

As opções -J e -T não podem ser usadas juntas.

Uso de cron e su com projetos e tarefas

Comando cron

O comando cron emite um settaskid para assegurar que cada trabalho cron, at e batch seja executado em uma tarefa separada, com o projeto padrão apropriado para o usuário remetente. Os comandos at e batch também capturam o ID de projeto atual, o que assegura que o ID de projeto é restaurado ao executar um trabalho at.

Comando su

O comando su une o projeto padrão do usuário de destino criando uma nova tarefa, como parte da simulação de um login.

Para ativar o projeto padrão do usuário usando o comando su, digite o seguinte:

# su user

Administração de projetos

Como definir um projeto e visualizar o projeto atual

Este exemplo mostra como usar o comando projadd para adicionar uma entrada de projeto e o comando projmod para alterar essa entrada.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Visualize o arquivo /etc/project padrão no sistema usando projects -l.

   # projects -l system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10::::system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs:

3. Adicione um projeto com o nome booksite. Atribua o projeto a um usuário nomeado mark com o número do ID de projeto 4113.

   # projadd -U mark -p 4113 booksite

4. Visualize novamente o arquivo /etc/project.

   # projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs: booksite projid : 4113 comment: "" users : mark groups : (none) attribs:

5. Adicione um comentário que descreva o projeto no campo de comentário.

   # projmod -c `Book Auction Project' booksite

6. Visualize as alterações no arquivo /etc/project .

   # projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs: booksite projid : 4113 comment: "Book Auction Project" users : mark groups : (none) attribs:

Consulte também

Para vincular projetos, tarefas e processos a um grupo, consulte Definição de atributos de grupos e vinculação a um grupo.

Como excluir um projeto do arquivo /etc/project

Este exemplo mostra como usar o comando projdel para excluir um projeto.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Remova o projeto booksite usando o comando projdel.

   # projdel booksite

3. Exiba o arquivo /etc/project.

   # projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: user.root projid : 1 comment: "" users : (none) groups : (none) attribs: noproject projid : 2 comment: "" users : (none) groups : (none) attribs: default projid : 3 comment: "" users : (none) groups : (none) attribs: group.staff projid : 10 comment: "" users : (none) groups : (none) attribs:

4. Efetue login como usuário mark e digite projects para visualizar os projetos atribuídos a esse usuário.

   # su - mark # projects default

Como validar o conteúdo do arquivo /etc/project

Se nenhuma opção de edição for fornecida, o comando projmod validará o conteúdo do arquivo project.

Para validar um mapa NIS, como superusuário, digite o seguinte:

# ypcat project | projmod -f —

O comando ypcat project | projmod -f — ainda não está implementado.

Para verificar a sintaxe do arquivo /etc/project, digite o seguinte:

# projmod -n

Como obter informações sobre o membro do projeto

Use o comando id com o sinalizador -p para exibir o membro do projeto atual do processo que faz a chamada.

$ id -p
uid=100(mark) gid=1(other) projid=3(default)

Como criar uma nova tarefa

1. Efetue login como membro do projeto de destino, booksite.

2. Crie uma nova tarefa no projeto booksite usando o comando newtask com a opção (verbosa) - v para obter o ID de tarefa do sistema.

   machine% newtask -v -p booksite 16

   A execução de newtask cria uma nova tarefa no projeto especificado e coloca o shell padrão do usuário nessa tarefa.

3. Visualize o membro do projeto atual no processo que chama.

   machine% id -p uid=100(mark) gid=1(other) projid=4113(booksite)

   O processo é agora um membro do novo projeto.

Como mover um processo em execução para uma nova tarefa

Este exemplo mostra como associar um processo em execução com uma tarefa diferente e um novo projeto. Para executar esta ação, é necessário ser superusuário ou ser proprietário do processo, ou ser um membro do novo projeto.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

   ---

   Observação –

   Se você for o proprietário do processo ou um membro do novo projeto, ignore esta etapa.

   ---

2. Obtenha o ID de processo do processo book_catalog.

   # pgrep book_catalog 8100

3. Associe o processo 8100 a um novo ID de tarefa no projeto booksite.

   # newtask -v -p booksite -c 8100 17

   A opção -c especifica que newtask opera no processo nomeado existente.

4. Confirme a tarefa para processar o mapeamento do IDE.

   # pgrep -T 17 8100

Edição e validação de atributos de projeto

Você pode usar os comandos de administração do banco de dados de projeto projadd e projmod para editar atributos de projeto.

A opção -K especifica uma lista de substituição de atributos. Atributos são delimitados por ponto-e-vírgula (;). Se a opção -K for usada com a opção -a, o atributo ou o valor do atributo será adicionado. Se a opção -K for usada com a opção -r, o atributo ou o valor do atributo será removido. Se a opção -K for usada com a opção - s, o atributo ou o valor do atributo será substituído.

Como adicionar atributos e valores de atributo a projetos

Use o comando projmod com as opções -a e - K para adicionar valores a um atributo de projeto. Se o atributo não existir, ele será criado.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Adicione um atributo de controle de recursos task.max-lwps sem valores no projeto myproject. Uma tarefa que entre no projeto tem somente o valor do sistema para o atributo.

   # projmod -a -K task.max-lwps myproject

3. Você pode em seguida adicionar um valor a task.max-lwps no projeto myproject. O valor consiste em um nível privilegiado, uma valor de limiar e uma ação associada ao alcance do limiar.

   # projmod -a -K "task.max-lwps=(priv,100,deny)" myproject

4. Uma vez que controles de recursos têm vários valores, você pode adicionar outro valor à lista de valores existente usando as mesmas opções.

   # projmod -a -K "task.max-lwps=(priv,1000,signal=KILL)" myproject

   Os vários valores são separados por vírgulas. A entrada task.max-lwps agora é como a seguir:

   task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL)

Como remover valores de atributo de projetos

Este procedimento assume os valores:

task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL)

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Para remover um valor de atributo do controle de recursos task.max-lwps no projeto myproject, use o comando projmod com as opções -r and -K.

   # projmod -r -K "task.max-lwps=(priv,100,deny)" myproject

   Se task.max-lwps tiver vários valores, como:

   task.max-lwps=(priv,100,deny),(priv,1000,signal=KILL)

   O primeiro valor coincidente será removido. O resultado seria:

   task.max-lwps=(priv,1000,signal=KILL)

Como remover um atributo de controle de atributos de um projeto

Para remover o controle de recursos task.max-lwps no projeto myproject, use o comando projmod com as opções- r e -K.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Remova o atributo task.max-lwps e todos os seus valores do projeto myproject:

   # projmod -r -K task.max-lwps myproject

Como substituir atributos e valores de atributos para projetos

Para substituir um valor diferente para o atributo task.max-lwps no projeto myproject, use o comando projmod com as opções -s e -K. Se o atributo não existir, ele será criado.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Substitua os valores atuais task.max-lwps pelos novos valores mostrados abaixo:

   # projmod -s -K "task.max-lwps=(priv,100,none),(priv,120,deny)" myproject

   O resultado seria:

   task.max-lwps=(priv,100,none),(priv,120,deny)

Como remover os valores existentes de um atributo de controle de recursos

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Para remover os valores atuais de task.max-lwps do projeto myproject, digite:

   # projmod -s -K task.max-lwps myproject

Capítulo 4 Contabilidade estendida (visão geral)

Usando as facilidades de projeto e tarefas descritos no Capítulo 2Projetos e tarefas (visão geral) para rotular e separar cargas de trabalho, você pode monitorar o consumo de recursos por carga de trabalho. Você pode usar o subsistema contabilidade estendida para capturar um conjunto detalhado de estatísticas de consumo de recursos em processos e tarefas.

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

• Introdução à contabilidade estendida

• Como funciona a contabilidade estendida

• Configuração da contabilidade estendida

• Comandos usados com a contabilidade estendida

• Interface Perl para libexacct

Para começar a usar a contabilidade estendida, salte para Como ativar a contabilidade estendida para processos, tarefas e fluxos.

O que há de novo na contabilidade estendida para o Solaris 10?

Agora, dados mstate para contabilidade de processo podem ser gerados. Consulte Como visualizar recursos de contabilidade disponíveis.

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.

Introdução à contabilidade estendida

O subsistema de contabilidade estendida rotula registros de uso com o projeto para o qual o trabalho foi feito. Você também pode usar a contabilidade estendida junto com o módulo de contabilidade de fluxo Internet Protocol Quality of Service (IPQoS) descrito no Capítulo 36, Using Flow Accounting and Statistics Gathering (Tasks), no System Administration Guide: IP Services, para capturar informações de fluxo de rede em um sistema.

Antes de poder aplicar mecanismos de gerenciamento de recursos, você primeiro deve caracterizar as exigências de consumo de recursos que várias cargas de trabalho colocam em um sistema. A facilidade de contabilidade estendida no Solaris Operating System oferece uma maneira flexível de registrar o consumo de recursos de sistema e rede com base em uma tarefa ou um processo, ou com base em seletores fornecidos pelo módulo IPQoS flowacct. Para obter mais informações consulte ipqos(7IPP).

Ao contrário das ferramentas de monitoração on-line, que permitem que você meça o uso do sistema em tempo real, a contabilidade estendida permite que você examine o uso histórico. A seguir você pode fazer avaliações de requisitos de capacidade para futuras cargas de trabalho.

Com dados da contabilidade estendida disponíveis, você pode desenvolver ou adquirir software para chargeback de recursos, monitoração de carga de trabalho ou planejamento de capacidade.

Como funciona a contabilidade estendida

A facilidade de contabilidade estendida no Solaris Operating System usa um formato de arquivo extensível, com versão, para conter dados de contabilidade. Arquivos que usam este formato de dados podem ser acessados ou criados com o uso da API fornecida na biblioteca incluída, libexacct (consulte libexacct(3LIB)). Esses arquivos podem ser então analisados em qualquer plataforma com contabilidade estendida ativada e os dados podem ser usados para planejamento de capacidade e chargeback.

Se a contabilidade estendida estiver ativa, serão obtidas estatísticas que podem ser examinadas pela API de libexacct. libexacct permite o exame dos arquivos exacct para frente ou para trás. A API oferece suporte a arquivos de terceiros que são gerados por libexacct assim como a arquivos que são criados pelo kernel. Há uma interface prática de linguagem de extração e relatório (Perl) para libexacct que permite que você desenvolva relatórios personalizados e scripts de extração. Consulte Interface Perl para libexacct

Por exemplo, com a contabilidade estendida ativada, a tarefa acompanha o uso dos recursos agregados dos processos de seu membro. Um registro de contabilidade de tarefa é escrito na conclusão da tarefa. Registros provisórios sobre processos e tarefas em execução também podem ser escritos. Para obter mais informações sobre tarefas, consulte o Capítulo 2Projetos e tarefas (visão geral).

Figura 4–1 Acompanhamento de tarefas com a contabilidade estendida ativada

Formato extensível

O formato da contabilidade estendida é substancialmente mais extensível do que o formato do software de contabilidade do sistema de legado SunOS (consulte What is System Accounting? no System Administration Guide: Advanced Administration). A contabilidade estendida permite que a métrica de contabilidade seja adicionada ao sistema e dele removida entre versões, e mesmo durante a operação do sistema.

A contabilidade estendida e o software de contabilidade do sistema de legado podem estar ativas ao mesmo tempo em seu sistema.

Registros e formato de exacct

Rotinas que permitem que registros de exacct sejam criados servem a dois propósitos.

• Para ativar arquivos exacct de terceiros a serem criados.

• Para ativar a criação de registros de identificação a serem incorporados no arquivo de contabilidade do kernel com o uso da chamada do sistema putacct (consulte getacct(2)).

  ---

  Observação –

  A chamada do sistema putacct está também disponível na interface Perl.

  ---

O formato permite que diferentes formas de registros de contabilidade sejam capturadas sem requerer que cada alteração seja uma alteração de versão explícita. Aplicativos bem escritos que consomem dados de contabilidade devem ignorar registros que eles não entendem.

A biblioteca libexacct converte e produz arquivos no formato exacct. Esta biblioteca é a única interface com suporte para arquivos no formato exacct.

As chamadas do sistema getacct, putacct e wracct não se aplicam a fluxos. O kernel cria registros de fluxos e os grava no arquivo quando a contabilidade de fluxo IPQoS é configurada.

Uso da contabilidade estendida em um sistema do Solaris com regiões instaladas

O subsistema da contabilidade estendida coleta e relata informações para todo o sistema (inclusive regiões não globais) quando executado na região global. O administrador global pode também determinar o consumo de recursos com base em cada região. Para obter mais informações, consulte Contabilidade estendida em um sistema do Solaris com regiões instaladas.

Configuração da contabilidade estendida

O arquivo /etc/acctadm.conf contém a configuração atual da contabilidade estendida. O arquivo é editado através da interface acctadm , não pelo usuário.

O diretório /var/adm/exacct é o local padrão para se colocar dados da contabilidade estendida. Você pode usar o comando acctadm para especificar um local diferente para os arquivos de dados de contabilidade de processos e tarefas. Para obter mais informações, consulte acctadm(1M).

Comandos usados com a contabilidade estendida

Para obter informações sobre comandos associados a tarefas e projetos, consulte Exemplos de comandos e opções de comando. Para obter informações sobre contabilidade de fluxo de IPQoS, consulte ipqosconf(1M).

Interface Perl para libexacct

A interface Perl permite que você crie scripts Perl que podem ler os arquivos de contabilidade produzidos pela estrutura exacct. Você também pode criar scripts Perl que gravam arquivos exacct.

A interface é funcionalmente equivalente à API C subjacente. Quando possível, os dados obtidos da API C subjacente são apresentados como tipos de dados Perl. Este recurso facilita o acesso aos dados e elimina a necessidade de pacote de buffer ou de operações de descompactação. Além disso, todo o gerenciamento da memória é executado pela biblioteca Perl.

Os vários projetos, tarefas e funções relacionados a exacct são separados em grupos. Cada grupo de funções está localizado em um módulo Perl separado. Cada módulo começa com prefixo de pacote Perl padrão da Sun Sun::Solaris::. Todas as classes fornecidas pela biblioteca Perl exacct se encontram no módulo Sun::Solaris::Exacct.

A biblioteca subjacente libexacct(3LIB) fornece operações sobre arquivos no formato exacct, etiquetas de catálogo e objetos exacct. Os objetos exacct são subdivididos em dois tipos:

• Itens, que são valores de dados únicos (escalares)

• Grupos, que são listas de itens

O quadro abaixo resume cada um dos módulos.

Para exemplos que mostram como usar os módulos descritos na tabela anterior, consulte Uso da interface Perl para libexacct.

Capítulo 5 Administração da contabilidade estendida (tarefas)

Este capítulo descreve como administrar o subsistema da contabilidade estendida.

Para uma visão geral do subsistema da contabilidade estendida, consulte o Capítulo 4Contabilidade estendida (visão geral).

Administração da facilidade de contabilidade estendida (mapa de tarefas)

Uso da funcionalidade da contabilidade estendida

Usuários podem gerenciar contagem estendida (iniciar contagem, parar contagem e alterar parâmetros de configuração de contagem) se eles tiverem o perfil correto e para o tipo de contagem estendida que será gerenciada:

• Gerenciamento de fluxo

• Gerenciamento de processo

• Gerenciamento de tarefa

Como ativar a contabilidade estendida para processos, tarefas e fluxos

Para ativar a facilidade de contabilidade estendida para tarefas, processos e fluxos, use o comando acctadm. O parâmetro final opcional para acctadm indica se o comando deve atuar no processo, na tarefa do sistema ou nos componentes de contabilidade de fluxo da facilidade de contabilidade estendida.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Ative a contabilidade estendida para processos.

   # acctadm -e extended -f /var/adm/exacct/proc process

3. Ative a contabilidade estendida para tarefas.

   # acctadm -e extended,mstate -f /var/adm/exacct/task task

4. Ative a contabilidade estendida para fluxos.

   # acctadm -e extended -f /var/adm/exacct/flow flow

Consulte também

Para obter mais informações, consulte acctadm(1M).

Como ativar a contabilidade estendida com um script de inicialização

Ative a contabilidade estendida continuamente vinculando o script /etc/init.d/acctadm a /etc/rc2.d.

# ln -s /etc/init.d/acctadm /etc/rc2.d/Snacctadm
# ln -s /etc/init.d/acctadm /etc/rc2.d/Knacctadm

A variável n é substituída por um número.

Você deve ativar manualmente a contabilidade estendida pelo menos uma vez para definir a configuração.

Para obter informações sobre configuração de contabilidade, consulte Configuração da contabilidade estendida.

Como exibir o status da contabilidade estendida

Digite acctadm sem argumentos para exibir o status atual da facilidade de contabilidade estendida.

# acctadm
                 Task accounting: active
            Task accounting file: /var/adm/exacct/task
          Tracked task resources: extended
        Untracked task resources: none
              Process accounting: active
         Process accounting file: /var/adm/exacct/proc
       Tracked process resources: extended
     Untracked process resources: host
                 Flow accounting: active
            Flow accounting file: /var/adm/exacct/flow
          Tracked flow resources: extended
        Untracked flow resources: none

No exemplo anterior, a contabilidade da tarefa do sistema está ativa no modo estendido e no modo mstate. A contabilidade do processo e do fluxo está ativa no modo estendido.

No contexto da contabilidade estendida, microstate (mstate) se refere aos dados estendidos, associados às transições do processo do microstate, que estão disponíveis no arquivo de uso do processo (consulte proc(4)). Estes dados fornecem mais detalhes sobre as atividades do processo do que os registros básicos ou estendidos.

Como visualizar recursos de contabilidade disponíveis

Recursos disponíveis variam de sistema para sistema e de plataforma para plataforma. Utilize o comando acctadm com a opção -r para visualizar os grupos de recursos de contabilidade disponíveis no sistema.

# acctadm -r
process:
extended pid,uid,gid,cpu,time,command,tty,projid,taskid,ancpid,wait-status,zone,flag,
memory,mstatedisplays as one line
basic    pid,uid,gid,cpu,time,command,tty,flag
task:
extended taskid,projid,cpu,time,host,mstate,anctaskid,zone
basic    taskid,projid,cpu,time
flow:
extended 
saddr,daddr,sport,dport,proto,dsfield,nbytes,npkts,action,ctime,lseen,projid,uid
basic    saddr,daddr,sport,dport,proto,nbytes,npkts,action

Como desativar a contabilidade de processo, tarefa e fluxo

Para desativar a contabilidade de processo, tarefa e fluxo, desative cada um deles individualmente usando o comando acctadm com a opção -x.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Desative a contabilidade do processo.

   # acctadm -x process

3. Desative a contabilidade da tarefa.

   # acctadm -x task

4. Desative a contabilidade do fluxo.

   # acctadm -x flow

5. Verifique se a contabilidade da tarefa, do processo e do fluxo foi desativada.

   # acctadm Task accounting: inactive Task accounting file: none Tracked task resources: extended Untracked task resources: none Process accounting: inactive Process accounting file: none Tracked process resources: extended Untracked process resources: host Flow accounting: inactive Flow accounting file: none Tracked flow resources: extended Untracked flow resources: none

Uso da interface Perl para libexacct

Como imprimir recursivamente o conteúdo de um objeto exacct

Use o código a seguir para imprimir recursivamente o conteúdo de um objeto exacct . Observe que esta capacidade é fornecida pela biblioteca como a função Sun::Solaris::Exacct::Object::dump(). Esta capacidade também está disponível através da função de conveniência ea_dump_object().

sub dump_object
     {
             my ($obj, $indent) = @_;
             my $istr = '  ' x $indent;

             #
             # Retrieve the catalog tag.  Because we are 
             # doing this in an array context, the
             # catalog tag will be returned as a (type, catalog, id) 
             # triplet, where each member of the triplet will behave as 
             # an integer or a string, depending on context.
             # If instead this next line provided a scalar context, e.g.
             #    my $cat  = $obj->catalog()->value();
             # then $cat would be set to the integer value of the 
             # catalog tag.
             #
             my @cat = $obj->catalog()->value();

             #
             # If the object is a plain item
             #
             if ($obj->type() == &EO_ITEM) {
                     #
                     # Note: The '%s' formats provide s string context, so
                     # the components of the catalog tag will be displayed
                     # as the symbolic values. If we changed the '%s'
                     # formats to '%d', the numeric value of the components
                     # would be displayed.
                     #
                     printf("%sITEM\n%s  Catalog = %s|%s|%s\n", 
                        $istr, $istr, @cat);
                     $indent++;

                     #
                     # Retrieve the value of the item.  If the item contains
                     # in turn a nested exacct object (i.e., an item or
                     # group),then the value method will return a reference
                     # to the appropriate sort of perl object
                     # (Exacct::Object::Item or Exacct::Object::Group).
                     # We could of course figure out that the item contained
                     # a nested item orgroup by examining the catalog tag in
                     # @cat and looking for a type of EXT_EXACCT_OBJECT or
                     # EXT_GROUP.
                     #
                     my $val = $obj->value();
                     if (ref($val)) {
                             # If it is a nested object, recurse to dump it.
                             dump_object($val, $indent);
                     } else {
                             # Otherwise it is just a 'plain' value, so
                             # display it.
                             printf("%s  Value = %s\n", $istr, $val);
                     }

             #
             # Otherwise we know we are dealing with a group.  Groups
             # represent contents as a perl list or array (depending on
             # context), so we can process the contents of the group
             # with a 'foreach' loop, which provides a list context.
             # In a list context the value method returns the content
             # of the group as a perl list, which is the quickest
             # mechanism, but doesn't allow the group to be modified.
             # If we wanted to modify the contents of the group we could
             # do so like this:
             #    my $grp = $obj->value();   # Returns an array reference
             #    $grp->[0] = $newitem;
             # but accessing the group elements this way is much slower.
             #
             } else {
                     printf("%sGROUP\n%s  Catalog = %s|%s|%s\n",
                         $istr, $istr, @cat);
                     $indent++;
                     # 'foreach' provides a list context.
                     foreach my $val ($obj->value()) {
                             dump_object($val, $indent);
                     }
                     printf("%sENDGROUP\n", $istr);
             }
     }

Como criar um novo registro de grupo e gravá-lo em um arquivo

Use este script para criar um novo registro de grupo e gravá-lo em um arquivo chamado /tmp/exacct.

#!/usr/bin/perl

use strict;
use warnings;
use Sun::Solaris::Exacct qw(:EXACCT_ALL);
# Prototype list of catalog tags and values.
     my @items = (
             [ &EXT_STRING | &EXC_DEFAULT | &EXD_CREATOR      => "me"       ],
             [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_PID     => $$         ],
             [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_UID     => $<         ],
             [ &EXT_UINT32 | &EXC_DEFAULT | &EXD_PROC_GID     => $(         ],
             [ &EXT_STRING | &EXC_DEFAULT | &EXD_PROC_COMMAND => "/bin/rec" ],
     );

     # Create a new group catalog object.
     my $cat = ea_new_catalog(&EXT_GROUP | &EXC_DEFAULT | &EXD_NONE)

     # Create a new Group object and retrieve its data array.
     my $group = ea_new_group($cat);
     my $ary = $group->value();

     # Push the new Items onto the Group array.
     foreach my $v (@items) {
             push(@$ary, ea_new_item(ea_new_catalog($v->[0]), $v->[1]));
     }

     # Open the exacct file, write the record & close.
     my $f = ea_new_file('/tmp/exacct', &O_RDWR | &O_CREAT | &O_TRUNC)
        || die("create /tmp/exacct failed: ", ea_error_str(), "\n");
     $f->write($group);
     $f = undef;

Como imprimir o conteúdo de um arquivo exacct

Use o script Perl a seguir para imprimir o conteúdo de um arquivo exacct.

#!/usr/bin/perl

     use strict;
     use warnings;
     use Sun::Solaris::Exacct qw(:EXACCT_ALL);

     die("Usage is dumpexacct <exacct file>\n") unless (@ARGV == 1);

     # Open the exact file and display the header information.
     my $ef = ea_new_file($ARGV[0], &O_RDONLY) || die(error_str());
     printf("Creator:  %s\n", $ef->creator());
     printf("Hostname: %s\n\n", $ef->hostname());

     # Dump the file contents
     while (my $obj = $ef->get()) {
             ea_dump_object($obj);
     }

     # Report any errors
     if (ea_error() != EXR_OK && ea_error() != EXR_EOF)  {
             printf("\nERROR: %s\n", ea_error_str());
             exit(1);
     }
     exit(0);

Saída de exemplo de Sun::Solaris::Exacct::Object->dump()

Esta é uma saída de exemplo produzida ao se executar Sun::Solaris::Exacct::Object->dump() no arquivo criado em Como criar um novo registro de grupo e gravá-lo em um arquivo.

Creator:  root
Hostname: localhost
GROUP
       Catalog = EXT_GROUP|EXC_DEFAULT|EXD_NONE
       ITEM
         Catalog = EXT_STRING|EXC_DEFAULT|EXD_CREATOR
         Value = me
       ITEM
         Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_PID
         Value = 845523
       ITEM
         Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_UID
         Value = 37845
       ITEM
         Catalog = EXT_UINT32|EXC_DEFAULT|EXD_PROC_GID
         Value = 10
       ITEM
         Catalog = EXT_STRING|EXC_DEFAULT|EXD_PROC_COMMAND
         Value = /bin/rec
ENDGROUP

Capítulo 6 Controles de recursos (visão geral)

Após determinar o consumo de recursos das cargas de trabalho no sistema, como descrito no Capítulo 4Contabilidade estendida (visão geral), você pode colocar limites no uso de recursos. Limites impedem que cargas de trabalho consumam recursos em excesso. O recurso controles de recurso é o mecanismo de restrição usado para este propósito.

Este capítulo aborda os seguintes tópicos:

• Conceitos de controles de recursos

• Configuração de controles de recursos e atributos

• Aplicação de controles de recursos

• Atualização temporária de valores do controle de recursos em um sistema em execução

• Comandos usados com controles de recursos

Para obter informações sobre como administrar controles de recursos, consulte o Capítulo 7Administração de controles de recursos (tarefas).

O que há de novo nos controles de recursos para Solaris 10?

O seguinte conjunto de controles de recursos substitui os ajustáveis da comunicação entre processos (IPC) de sistema V /etc/system:

• project.max-shm-ids

• project.max-msg-ids

• project.max-sem-ids

• project.max-shm-memory

• process.max-sem-nsems

• process.max-sem-ops

• process.max-msg-qbytes

Os seguintes controles de recursos de porta de evento foram adicionados:

• project.max-device-locked-memory

• project.max-port-ids

• process.max-port-events

O seguinte controle de recursos criptográfico foi adicionado:

• project.max-crypto-memory

Os seguintes controles de recursos extras foram adicionados:

• project.max-lwps

• project.max-tasks

• project.max-contracts

Para obter mais informações, consulte Controles de recursos disponíveis.

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.

Conceitos de controles de recursos

No sistema operacional Solaris, o conceito de limite de recursos por processo foi estendido para as entidades de tarefas e projetos descritos no Capítulo 2Projetos e tarefas (visão geral). Essas melhorias são fornecidas pelos controles de recursos (rctls). Além disso, alocações que eram definidas através dos ajustáveis /etc/system agora são automáticas ou configuradas também através do mecanismo de controles de recursos.

Um controle de recursos é identificado pelo prefixo zone, project, task ou process. Controles de recursos podem ser observados em uma base do sistema geral. É possível atualizar valores de controle de recursos em um sistema em execução.

Para obter uma lista dos controles de recursos padrão disponíveis nesta versão, consulte Controles de recursos disponíveis Para obter informações sobre controles de recursos para região geral, consulte Propriedades de tipo de recursos.

Para obter uma lista dos controles de recursos padrão disponíveis nesta versão, consulte Controles de recursos disponíveis.

Limites de recursos e controles de recursos

Sistemas do UNIX tradicionalmente fornecem uma função de limite de recursos (rlimit). A função rlimit permite que os administradores definam um ou mais limites numéricos da quantidade de recursos que um processo pode consumir. Esses limites incluem tempo de CPU usado por processo, tamanho de arquivo de núcleo por processo e tamanho de pilha máximo por processo. Tamanho de pilha é a quantidade de memória temporária alocada para o segmento de dados do processo.

A facilidade de controles de recursos fornece interfaces de compatibilidade para a facilidade de limites de recursos. Aplicativos existentes que usam limites de recursos continuam a ser executados inalterados. Esses aplicativos podem ser observados da mesma maneira que aplicativos que são modificados para tirarem proveito da facilidade de controles de recursos.

Comunicação entre processos e controles de recursos

Processos podem se comunicar entre si usando um dos vários tipos de comunicação entre processos (IPC). IPC permite que a transferência ou a sincronização de informações ocorra entre processos. Antes da versão Solaris 10, os parâmetros ajustáveis de IPC eram definidos pela adição de uma entrada no arquivo /etc/system. A facilidade de controles de recursos agora fornece controles de recursos que definem o comportamento das facilidades de IPC do kernel. Esses controles de recursos substituem os ajustáveis /etc/system.

Parâmetros obsoletos podem ser incluídos no arquivo /etc/system neste sistema do Solaris. Se incluídos, os parâmetros são usados para inicializar os valores de controle de recursos padrão, como nas versões anteriores do Solaris. No entanto, o uso de parâmetros obsoletos não é recomendável.

Para observar quais objetos IPC estão contribuindo para o uso de um projeto, use o comando ipcs com a opção -J. Para visualizar um exemplo, consulte Como usar ipcs Para obter mais informações sobre o comando ipcs, consulte ipcs(1).

Para obter informações sobre o desempenho do sistema Solaris, consulte Oracle Solaris Tunable Parameters Reference Manual.

Mecanismos de restrição do controle de recursos

Controles de recursos fornecem um mecanismo para a restrição dos recursos do sistema. É possível impedir que processos, tarefas, projetos e regiões consumam quantidades de recursos de sistema especificados. Esse mecanismo conduz a um sistema mais gerenciável ao impedir o consumo excessivo de recursos.

Mecanismos de restrição podem ser usados para oferecer suporte a processos de planejamento de capacidade. Uma restrição encontrada pode fornecer informações sobre as necessidades de recurso de um aplicativo sem necessariamente negar o recurso ao aplicativo.

Mecanismos de atributo de projeto

Controles de recursos também servem como um mecanismo de atributo simples para facilidades de gerenciamento de recursos. Por exemplo, o número de compartilhamentos de CPU disponibilizadas para um projeto na classe de agendamento fair share scheduler (FSS) é definido pelo controle de recursos project.cpu-shares. Uma vez que o controle atribui ao projeto um número fixo de compartilhamentos, as várias ações associadas a exceder um controle não são pertinentes. Neste contexto, o valor atual para o controle project.cpu-shares é considerado um atributo no projeto especificado.

Outro tipo de atributo de projeto é usado para regular o consumo de recursos da memória física por coleções de processos anexados a um projeto. Esses atributos têm o prefixo rcap, por exemplo, rcap.max-rss . Como um controle de recursos, este tipo de atributo é configurado no banco de dados de project. No entanto, enquanto os controles de recursos são aplicados sincronicamente pelo kernel, os limites de recurso são aplicados assincronicamente no nível de usuário pelo daemon de aplicação do limite de recursos, rcapd . Para obter informações sobre rcapd, consulte o Capítulo 10Controle da memória física usando o resource capping daemon (visão geral) e rcapd (1M).

O atributo project.pool é usado para especificar uma vinculação de grupo para um projeto. Para obter mais informações sobre grupos de recursos, consulte o Capítulo 12Grupos de recursos (visão geral).

Configuração de controles de recursos e atributos

A facilidade dos controles de recursos é configurada através do banco de dados de project . Consulte o Capítulo 2Projetos e tarefas (visão geral). Controles de recursos e outros atributos são definidos no campo final da entrada do banco de dados de project. Os valores associados a cada controle de recursos estão entre parênteses e aparecem como texto não formato separado por vírgulas. Os valores entre parênteses compreendem uma “cláusula de ação”. Cada cláusula de ação é composta de um nível de privilégio, um valor de limiar e uma ação que é associada ao limiar específico. Cada controle de recursos tem várias cláusulas de ação, que também são separadas por vírgulas. A entrada a seguir define um limite de processo leve por tarefa e um limite máximo de tempo de CPU por processo em uma entidade de projeto. O process.max-cpu-time envia para um processo um SIGTERM após 1 hora de execução do processo, e um SIGKILL, se o processo continuar a ser executado durante um total de 1 hora e 1 minuto. Consulte a Tabela 6–3.

development:101:Developers:::task.max-lwps=(privileged,10,deny);
  process.max-cpu-time=(basic,3600,signal=TERM),(priv,3660,signal=KILL)
typed as one line

Em sistemas com regiões ativadas, os controles de recursos de região geral são especificados na configuração da região com o uso de um formato ligeiramente diferente. Para obter mais informações, consulte Dados de configuração de região.

O comando rctladm permite que você faça interrogações de tempo de execução à facilidade de controles de recursos, assim como modificações, com escopo global. O comando prctl permite que você faça interrogações de tempo de execução à facilidade de controles de recursos, assim como modificações, com escopo local.

Para obter mais informações, consulte Ações globais e locais em valores de controle de recursos, rctladm(1M) e prctl(1).

Em um sistema com regiões instaladas, não é possível usar rctladm em uma região não global para modificar configurações. Você pode usar rctladm em uma região não global para visualizar o estado de registro global de cada controle de recursos.

Controles de recursos disponíveis

Uma lista de controles de recursos padrão disponíveis nesta versão é mostrada na tabela abaixo.

A tabela descreve o recurso que é restringido por cada controle. A tabela também identifica as unidades padrão usadas pelo banco de dados de project para esse recurso. Há dois tipos de unidades padrão:

• Quantidades representam uma quantidade limitada.

• Índices representam um identificador válido máximo.

Assim, project.cpu-shares especifica o número de compartilhamentos a que o projeto tem direito. process.max-file-descriptor especifica o número de arquivo mais alto que pode ser atribuído a um processo pela chamada do sistema open(2).

Você pode exibir os valores padrão para controles de recursos em um sistema que não tem quaisquer controles de recursos definidos ou alterados. Esse sistema contém entradas não padrão em /etc/system ou no banco de dados de project . Para exibir valores, use o comando prctl.

Controles de recursos gerais de região

Os controles de recursos gerais de região limitam o uso total de recursos de todas as entidades de processamento dentro de uma região. Os controles de recursos gerais de região também podem ser definidos com o uso de nomes de propriedade globais, como descrito em Definição de controles de recursos de região geral e Como configurar a região.

Para obter informações sobre configuração de controles de recursos gerais de região, consulte Propriedades de tipo de recursos e Como configurar a região. Para usar controles de recursos gerais de região em regiões com marca lx, consulte Como configurar, verificar e comprometer a região com marca lx..

Observe que é possível aplicar um controle de recursos de região geral à região global. Consulte o Capítulo 17Configuração de região não global (visão geral) e Uso do fair share scheduler em um sistema do Solaris com regiões instaladas para obter informações adicionais.

Suporte a unidades

Sinalizadores globais que identificam tipos de controle de recursos são definidos para todos os controles de recursos. Os sinalizadores são usados pelo sistema para comunicar informações básicas de tipo a aplicativos como o comando prctl. Os aplicativos usam as informações para determinar o seguinte:

• As seqüências de unidades que são apropriadas para cada controle de recursos

• A escala correta a ser usada ao interpretar valores em escala

Os seguintes sinalizadores globais estão disponíveis:

Valores em escala podem ser usados com controles de recursos. O exemplo abaixo mostra um valor de limiar em escala:

task.max-lwps=(priv,1K,deny)

Modificadores de unidades são aceitos pelos comandos prctl, projadd e projmod. Não é possível usar modificadores de unidades no próprio banco de dados de project.

Valores de controle de recursos e níveis de privilégio

Um valor de limiar em um controle de recursos constitui um ponto de aplicação em que ações locais podem ser acionadas, ou ações globais como registro podem ocorrer.

Cada valor de limiar em um controle de recursos deve estar associado a um nível de privilégio. P nível de privilégio deve ser um dos três tipos seguintes.

• Básico, que pode ser modificado pelo proprietário do processo de chamada

• Privilegiado, que pode ser modificado somente pelos chamadores (superusuários) privilegiados

• Sistema, que é fixo durante a instância do sistema operacional

Um controle de recursos com certeza tem um valor de sistema, que é definido pelo sistema ou provedor de recursos. O valor de sistema representa a quantidade de recursos que a implementação atual do sistema operacional é capaz de fornecer.

Qualquer número de valores privilegiados podem ser definidos e somente um valor básico é permitido. Às operações executadas sem a especificação de um valor de privilégio é atribuído um privilégio básico por padrão.

O nível de privilégio para um valor de controle de recursos é definido no campo de privilégio do bloco do controle de recursos como RCTL_BASIC, RCTL_PRIVILEGED, ou RCTL_SYSTEM. Para obter mais informações, consulte setrctl(2) Você pode usar o comando prctl para modificar valores associados aos níveis básico e privilegiado.

Ações globais e locais em valores de controle de recursos

Há duas categorias de ações em valores de controle de recursos: global e local.

Ações globais em valores de controle de recursos

Ações globais aplicam valores de controle de recursos para cada controle de recurso no sistema. Você pode usar o comando rctladm descrito na página do manual rctladm(1M) para executar as seguintes ações:

• Exibir o estado global dos controles de recursos de sistema ativo

• Definir ações de registro global

Você pode desativar ou ativar a ação de registro global nos controles de recursos. Você pode definir a ação syslog para um grau específico atribuindo um nível de severidade, syslog=level. As configurações possíveis para level são as seguintes:

• depuração

• info

• notice

• warning

• err

• crit

• alert

• emerg

Por padrão, não há registro global das violações do controle de registro. No Solaris 10 versão 5/08, o nível n/a foi adicionado para controles de recurso em que nenhuma ação global pode ser configurada.

Ações locais em valores de controle de recursos

Ações locais são tomadas em um processo que tenta exceder o valor de controle. Para cada valor de limiar colocado em um controle de recursos, você pode associar uma ou mais ações. Há três tipos de ações locais: none, deny e signal=. Estas três ações são usadas como a seguir:

none

Nenhuma ação é tomada sobre solicitações de recurso para uma quantidade que seja maior do que o limiar. Esta ação é útil para monitorar o uso de recursos sem afetar o progresso dos aplicativos. Você também pode ativar uma mensagem global que é exibida quando o controle de recursos é excedido, embora o processo que exceda o limiar não é afetado.

deny

Você pode negar solicitações de recursos para uma quantidade que seja maior do que o limiar. Por exemplo, um controle de recursos task.max-lwps com ação deny faz com que uma chamada de sistema fork falhe, se o novo processo exceder o valor de controle. Consulte a página do manual fork(2).

signal=

Você pode ativar uma ação de mensagem de sinal global quando o controle de recursos é excedido. Um sinal é enviado para o processo quando o valor do limiar é excedido. Sinais adicionais não são enviados se o processo consumir recursos adicionais. Os sinais disponíveis estão listados na Tabela 6–3.

Nem todas as ações podem ser aplicadas a cada controle de recursos. Por exemplo, um processo não pode exceder o número de compartilhamentos de CPU atribuídas ao projeto do qual é membro. Assim, uma ação de negação não é permitida no controle de recursos project.cpu-shares.

Devido à implementação de restrições, as propriedades globais de cada controle podem restringir o intervalo de ações disponíveis que podem ser definidas no valor de limiar. (Consulte a página do manual rctladm(1M) Uma lista de ações de sinal disponíveis é apresentada na tabela abaixo. Para obter informações adicionais sobre sinais, consulte a página do manual signal(3HEAD).

Sinalizadores e propriedades do controle de recursos

Cada controle de recursos no sistema tem um determinado conjunto de propriedades associadas. Esse conjunto de propriedades é definido como um conjunto de sinalizadores, que estão associados a todas as instâncias controladas desse recurso. Sinalizadores globais podem ser modificados, mas os sinalizadores podem ser recuperados usando-se rctladm ou a chamada do sistema getrctl.

Sinalizadores locais definem o comportamento e a configuração padrão para um valor de limiar específico desse controle de recursos em um processo específico ou um processo coletivo. Os sinalizadores locais para um valor de limiar não afetam o comportamento de outros valores de limiar definidos para o mesmo controle de recursos. No entanto, os sinalizadores globais afetam o comportamento de cada valor associado a um controle específico. Sinalizadores locais podem ser modificados, dentro de restrições fornecidas pelos sinalizadores globais correspondentes, pelo comando prctl ou pela chamada do sistema setrctl. Consulte setrctl(2).

Para obter uma lista completa de sinalizadores locais, sinalizadores globais e suas definições, consulte rctlblk_set_value(3C).

Para determinar o comportamento do sistema quando um valor de limiar para um controle de recursos específico for atingido, use rctladm para exibir os sinalizadores globais para o controle de recursos. Por exemplo, para exibir os valores para process.max-cpu-time, digite o que se segue:

$ rctladm process.max-cpu-time
	process.max-cpu-time  syslog=off  [ lowerable no-deny cpu-time inf seconds ]

Os sinalizadores globais indicam o seguinte.

lowerable

Privilégios de superusuário não são necessários para diminuir os valores privilegiados para este controle.

no-deny

Mesmo quando valores de limiar são excedidos, o acesso a esse recurso nunca é negado.

cpu-time

SIGXCPU está disponível para ser enviado quando valores de limiar desse recurso são atingidos.

seconds

O valor de tempo para o controle de recursos.

no-basic

Os valores de controle de recursos com o tipo de privilégio basic não podem ser definidos. Somente valores de controle de recursos privilegiados são permitidos.

no-signal

Uma ação de sinal local não pode ser definido em valores de controle de recursos.

no-syslog

A ação de mensagem global syslog não pode ser definida para esse controle de recursos.

deny

Sempre negue a solicitação para o recurso quando os valores de limite sejam excedidos.

count

Um valor de contagem (inteiro) de controle de recursos.

bytes

Unidade de tamanho do controle de recursos.

Use o comando prctl para exibir valores e ações locais e para o controle de recursos.

$ prctl -n process.max-cpu-time $$
	process 353939: -ksh
	NAME    PRIVILEGE    VALUE    FLAG   ACTION              RECIPIENT
 process.max-cpu-time
         privileged   18.4Es    inf   signal=XCPU                 -
         system       18.4Es    inf   none 

O sinalizar max (RCTL_LOCAL_MAXIMAL) é definido para os dois valores de limiar e o sinalizador inf (RCTL_GLOBAL_INFINITE) é definido para este controle de recursos. Um valor inf tem uma quantidade infinita. O valor nunca é aplicado. Portanto, como configuradas, as duas quantidades de limiar representam valores infinitos que nunca são excedidos.

Aplicação de controle de recursos

Mais de um controle de recursos pode existir em um recurso. Um controle de recursos pode existe em cada nível de confinamento no modelo do processo. Se controles de recurso estiverem ativos no mesmo recurso em diferentes níveis de recipiente, o menor controle de recipiente é aplicado primeiro. Assim, uma ação será tomada em process.max-cpu-time antes de task.max-cpu-time se os dois controles forem encontrados simultaneamente.

Figura 6–1 Processos coletivos, relacionamentos de recipiente e suas configurações de controle de recursos

Monitoração global de eventos de controle de recursos

Com freqüência, o consumo de recursos de processos é desconhecido. Para obter mais informações, tente usar as ações do controle de recursos global que estão disponíveis com o comando rctladm. Use rctladm para estabelecer uma ação syslog em um controle de recursos. Em seguida, se alguma entidade gerenciada por esse controle de recursos encontrar um valor de limiar, uma mensagem de sistema será registrada no nível de registro configurado. Para obter mais informações, consulte o Capítulo 7Administração de controles de recursos (tarefas) e a página do manual rctladm(1M).

Aplicação de controles de recursos

Cada controle de recursos listado na Tabela 6–1 pode ser atribuído a um projeto no login ou quando newtask, su, ou os outros iniciadores que reconhecem projeto at, batch ou cron são invocados. Cada comando que é iniciado é inicializado em uma tarefa separada com o projeto padrão do usuário que o invoca. Para obter mais informações, consulte as páginas do manual login(1), newtask(1), at(1), cron(1M) e su(1M).

Atualizações de entradas no banco de dados de project, seja para o arquivo /etc/project ou para uma representação do banco de dados em um serviço de nomes de rede network, não são aplicadas aos projetos atualmente ativos. As atualizações são aplicadas quando uma nova tarefa se une ao projeto através de login ou de newtask.

Atualização temporária de valores do controle de recursos em um sistema em execução

Valores alterados no banco de dados de project somente se tornam efetivas para novas tarefas que são iniciadas em um projeto. No entanto, você pode usar os comandos rctladm e prctl para atualizar controles de recursos em um sistema em execução.

Atualização de status de registro

O comando rctladm afeta o estado de registro global de cada controle de recursos com base em um sistema geral. Este comando pode ser usado para visualizar o estado global e para configurar o nível de registro syslog quando controles são excedidos.

Atualização de controles de recursos

Você pode visualizar e alterar temporariamente valores de controle de recursos e ações em uma base por processo, por tarefa ou por projeto usando o comando prctl. Um ID de projeto, tarefa ou processo é dado como entrada, e o comando opera sobre o controle de recursos no nível em que o controle é definido.

Quaisquer modificações de valores e ações têm efeito imediatamente. No entanto, essas modificações se aplicam somente ao processo, à tarefa ou ao projeto atuais. As alterações não registradas no banco de dados de project. Se o sistema for reiniciado, as modificações serão perdidas. Alterações permanentes em controles de recursos devem ser feitas no banco de dados de project.

Todas as configurações de controle que podem ser modificadas no banco de dados de project também podem ser modificadas com o comando prctl. Valores básicos e privilegiados podem ser adicionados ou excluídos. Suas ações também podem ser modificadas. Por padrão, o tipo básico é considerado para todas as operações definidas, mas processos e usuários com privilégios de superusuário também pode modificar controles de recurso privilegiados. Controles de recurso de sistema no podem ser alterados.

Comandos usados com controles de recursos

Os comandos que são usados com controles de recursos são mostrados na tabela abaixo.

A página do manual resource_controls(5) descreve controles de recursos disponíveis através do banco de dados de projeto, incluindo unidades e fatores de escala.

Capítulo 7 Administração de controles de recursos (tarefas)

Este capítulo descreve como administrar a facilidade de controles de recursos.

Para uma visão geral da facilidade de controles de registros, consulte o Capítulo 6Controles de recursos (visão geral).

Administração de controles de recursos (mapa de tarefas)

Configuração de controles de recursos

Como definir o número máximo de LWPs para cada tarefa em um projeto

Este procedimento adiciona um projeto nomeado x-files ao arquivo /etc/project e define um número máximo de LWPs para uma tarefa criada no projeto.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Use o comando projadd com a opção -K para criar um projeto nomeado x-files. Defina o número máximo de LWPs para cada tarefa criada no projeto como 3 .

   # projadd -K 'task.max-lwps=(privileged,3,deny)' x-files

3. Visualize a entrada no arquivo /etc/project usando um dos seguintes métodos:

   • Tipo:

     # projects -l system projid : 0 comment: "" users : (none) groups : (none) attribs: . . . x-files projid : 100 comment: "" users : (none) groups : (none) attribs: task.max-lwps=(privileged,3,deny)

   • Tipo:

     # cat /etc/project system:0:System::: . . . x-files:100::::task.max-lwps=(privileged,3,deny)

Exemplo 7–1 Sessão de amostra

Após implementar as etapas neste procedimento, quando um superusuário cria uma nova tarefa no projeto x-files unindo o projeto a newtask , o superusuário não poderá criar mais do que três LWPs enquanto estiver em execução nesta tarefa. Isso é mostrado na sessão de amostra anotada a seguir.

# newtask -p x-files csh

# prctl -n task.max-lwps $$
process: 111107: csh
NAME    PRIVILEGE    VALUE    FLAG   ACTION            RECIPIENT
task.max-lwps
        privileged       3       -   deny                      -
        system       2.15G     max   deny                      -
# id -p
uid=0(root) gid=1(other) projid=100(x-files)

# ps -o project,taskid -p $$
 PROJECT TASKID
 x-files    73

# csh        /* creates second LWP */

# csh        /* creates third LWP */

# csh        /* cannot create more LWPs */
Vfork failed
#

Como definir múltiplos controles em um projeto

O arquivo /etc/project pode conter configurações para múltiplos controles de recursos para cada projeto, assim como múltiplos valores de limiar para cada controle. Valores de limiar são definidos em cláusulas de ação, que são separadas por vírgulas para múltiplos valores.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Use o comando projmod com as opções -s e -K para definir controles de recursos no projeto x-files:

   # projmod -s -K 'task.max-lwps=(basic,10,none),(privileged,500,deny); process.max-file-descriptor=(basic,128,deny)' x-filesone line in file

   Os seguintes controles são definidos:

   • Um controle basic sem ação no máximo de LWPs por tarefa.

   • Um controle deny privilegiado no máximo de LWPs por tarefa.. Este controle faz falhar qualquer criação de LWP que exceda o máximo, como mostrado no exemplo anterior Como definir o número máximo de LWPs para cada tarefa em um projeto.

   • Um limite nos descritores de arquivo máximos por processo no nível basic, que força a falha de qualquer chamada openque exceda o máximo.

3. Visualize a entrada no arquivo usando um dos seguintes métodos:

   • Tipo:

     # projects -l . . . x-files projid : 100 comment: "" users : (none) groups : (none) attribs: process.max-file-descriptor=(basic,128,deny) task.max-lwps=(basic,10,none),(privileged,500,deny) one line in file

   • Tipo:

     # cat etc/project . . . x-files:100::::process.max-file-descriptor=(basic,128,deny); task.max-lwps=(basic,10,none),(privileged,500,deny) one line in file

Uso do comando prctl

Use o comando prctl para fazer interrogações de tempo de execução, ou modificações, aos controles de recursos associados a um processo, tarefa ou projeto ativo no sistema. Para obter mais informações, consulte a página do manual prctl(1).

Como usar o comando prctl para exibir valores de controle de recurso padrão

Este procedimento deve ser usado em um sistema no qual nenhum controle de recurso tenha sido definido ou alterado. Pode haver somente entradas não padrão no arquivo /etc/system ou no banco de dados de project.

1. Use o comando prctl em qualquer processo, como o shell atual em execução.

   # prctl $$ process: 100337: -sh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT process.max-port-events privileged 65.5K - deny - system 2.15G max deny - process.crypto-buffer-limit system 16.0EB max deny - process.max-crypto-sessions system 18.4E max deny - process.add-crypto-sessions privileged 100 - deny - system 18.4E max deny - process.min-crypto-sessions privileged 20 - deny - system 18.4E max deny - process.max-msg-messages privileged 8.19K - deny - system 4.29G max deny - process.max-msg-qbytes privileged 64.0KB - deny - system 16.0EB max deny - process.max-sem-ops privileged 512 - deny - system 2.15G max deny - process.max-sem-nsems privileged 512 - deny - system 32.8K max deny - process.max-address-space privileged 16.0EB max deny - system 16.0EB max deny - process.max-file-descriptor basic 256 - deny 100337 privileged 65.5K - deny - system 2.15G max deny - process.max-core-size privileged 8.00EB max deny - system 8.00EB max deny - process.max-stack-size basic 8.00MB - deny 100337 privileged 8.00EB - deny - system 8.00EB max deny - process.max-data-size privileged 16.0EB max deny - system 16.0EB max deny - process.max-file-size privileged 8.00EB max deny,signal=XFSZ - system 8.00EB max deny - process.max-cpu-time privileged 18.4Es inf signal=XCPU - system 18.4Es inf none - task.max-cpu-time system 18.4Es inf none - task.max-lwps system 2.15G max deny - project.max-contracts privileged 10.0K - deny - system 2.15G max deny - project.max-device-locked-memory privileged 499MB - deny - system 16.0EB max deny - project.max-port-ids privileged 8.19K - deny - system 65.5K max deny - project.max-shm-memory privileged 1.95GB - deny - system 16.0EB max deny - project.max-shm-ids privileged 128 - deny - system 16.8M max deny - project.max-msg-ids privileged 128 - deny - system 16.8M max deny - project.max-sem-ids privileged 128 - deny - system 16.8M max deny - project.max-tasks system 2.15G max deny - project.max-lwps system 2.15G max deny - project.cpu-shares privileged 1 - none - system 65.5K max none - zone.max-lwps system 2.15G max deny - zone.cpu-shares privileged 1 - none - system 65.5K max none -

Como usar o comando prctl para exibir informações para um determinado controle de recurso

1. Exiba o descritor de arquivo máximo para o shell atual em execução.

   # prctl -n process.max-file-descriptor $$ process: 110453: -sh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT process.max-file-descriptor basic 256 - deny 110453 privileged 65.5K - deny - system 2.15G max deny

Como usar prctl para alterar um valor temporariamente

Este procedimento de exemplo usa o comando prctl para adicionar temporariamente um novo valor privilegiado para negar o uso de mais do que três LWPs por projeto para o projeto x-files. O resultado é comparável ao resultado em Como definir o número máximo de LWPs para cada tarefa em um projeto.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Use newtask para unir o projeto x-files.

   # newtask -p x-files

3. Use o comando id com a opção - p para verificar se o projeto correto foi unido.

   # id -p uid=0(root) gid=1(other) projid=101(x-files)

4. Adicione um novo valor privilegiado para project.max-lwps que limita o número de LWPs a três.

   # prctl -n project.max-lwps -t privileged -v 3 -e deny -i project x-files

5. Verifique o resultado.

   # prctl -n project.max-lwps -i project x-files process: 111108: csh NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT project.max-lwps privileged 3 - deny - system 2.15G max deny -

Como usar prctl para baixar um valor de controle de recurso

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Use o comando prctl com a opção -r para alterar o valor mais baixo do controle de recurso process.max-file-descriptor .

   # prctl -n process.max-file-descriptor -r -v 128 $$

Como usar prctl para exibir, substituir e verificar o valor de um controle em um projeto

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Exiba o valor de project.cpu-shares no projeto group.staff.

   # prctl -n project.cpu-shares -i project group.staff project: 2: group.staff NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT project.cpu-shares privileged 1 - none - system 65.5K max none

3. Substitua o valor atual 1 de project.cpu-shares pelo valor 10.

   # prctl -n project.cpu-shares -v 10 -r -i project group.staff

4. Exiba o valor de project.cpu-shares no projeto group.staff.

   # prctl -n project.cpu-shares -i project group.staff project: 2: group.staff NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT project.cpu-shares privileged 10 - none - system 65.5K max none

Uso de rctladm

Como usar rctladm

Use o comando rctladm para fazer a interrogação de tempo de execução, ou modificações, ao estado global da facilidade de controles de recursos. Para obter mais informações, consulte a página do manual rctladm(1M).

Por exemplo, você pode usar rctladm com a opção -e para ativar o atributo global syslog de um controle de recurso. Quando o controle é excedido, uma notificação é registrada no nível de syslog especificado. Para ativar o atributo global syslog de process.max-file-descriptor , digite o seguinte:

# rctladm -e syslog process.max-file-descriptor

Quando usado sem argumentos, o comando rctladm exibe os sinalizadores globais, incluindo o sinalizador de tipo global, para cada controle de recurso.

# rctladm
process.max-port-events     syslog=off  [ deny count ]
process.max-msg-messages    syslog=off  [ deny count ]
process.max-msg-qbytes      syslog=off  [ deny bytes ]
process.max-sem-ops         syslog=off  [ deny count ]
process.max-sem-nsems       syslog=off  [ deny count ]
process.max-address-space   syslog=off  [ lowerable deny no-signal bytes ]
process.max-file-descriptor syslog=off  [ lowerable deny count ]
process.max-core-size       syslog=off  [ lowerable deny no-signal bytes ]
process.max-stack-size      syslog=off  [ lowerable deny no-signal bytes ]
.
.
.

Uso de ipcs

Como usar ipcs

Use o utilitário ipcs para exibir informações sobre as facilidades ativas da comunicação entre processos (IPC). Para obter mais informações, consulte a página do manual ipcs(1).

Você pode usar ipcs com a opção -J para ver o limite de projeto contra o qual um objeto IPC está alocado.

# ipcs -J
    IPC status from <running system> as of Wed Mar 26 18:53:15 PDT 2003
T         ID      KEY        MODE       OWNER    GROUP    PROJECT
Message Queues:
Shared Memory:
m       3600      0       --rw-rw-rw-   uname    staff    x-files
m        201      0       --rw-rw-rw-   uname    staff    x-files
m       1802      0       --rw-rw-rw-   uname    staff    x-files
m        503      0       --rw-rw-rw-   uname    staff    x-files
m        304      0       --rw-rw-rw-   uname    staff    x-files
m        605      0       --rw-rw-rw-   uname    staff    x-files
m          6      0       --rw-rw-rw-   uname    staff    x-files
m        107      0       --rw-rw-rw-   uname    staff    x-files
Semaphores:
s          0      0       --rw-rw-rw-   uname    staff    x-files

Avisos de capacidade

Uma ação global em um controle de recurso permite que você receba aviso de qualquer entidade que esteja encontrando um valor de controle de recurso com definição muito baixa.

Por exemplo, suponha que você deseja determinar se um servidor Web processa CPUs suficientes para uma carga de trabalho típica. Você pode analisar dados de sar para tempo ocioso de CPU e média de carga. Pode também examinar dados de contabilidade estendida para determinar o número de processos simultâneos que estão em execução para o processo do servidor Web.

No entanto, uma abordagem mais fácil é colocar o servidor Web em uma tarefa. Você pode então definir uma ação global, usando syslog, para notificar você toda vez que uma tarefa exceder o número agendado de LWPs apropriado para as capacidades da máquina.

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

Como determinar se há alocação de capacidade de CPU suficiente para um servidor Web

1. Use o comando prctl para colocar um controle de recurso privilegiado (pertencente ao superusuário) em tarefas que contenham um processo httpd. Limite o número total de LWPs de cada tarefa a 40, e desative todas as ações locais.

   # prctl -n task.max-lwps -v 40 -t privileged -d all `pgrep httpd`

2. Ative uma ação global de log do sistema no controle de recurso task.max-lwps.

   # rctladm -e syslog task.max-lwps

3. Observe se a carga de trabalho encontra o controle de recurso.

   Se sim, você verá /var/adm/messages como:

   Jan 8 10:15:15 testmachine unix: [ID 859581 kern.notice] NOTICE: privileged rctl task.max-lwps exceeded by task 19

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.

Capítulo 9 Administração do fair share scheduler (tarefas)

Este capítulo descreve como usar o fair share scheduler (FSS).

Para uma visão geral do FSS, consulte o Capítulo 8Fair share scheduler (visão geral). Para obter informações sobre classe de agendamento quando regiões estão em uso, consulte Classe de agendamento em uma região.

Administração do fair share scheduler (mapa de tarefas)

Monitoração do FSS

Você pode usar o comando prstat descrito na página do manual prstat(1M) para monitorar o uso da CPU por projetos ativos.

Você pode usar os dados de contabilidade estendida para tarefas para obter estatísticas por projeto sobre a quantidade de recursos da CPU que é consumida durante longos períodos. Para obter mais informações, consulte o Capítulo 4Contabilidade estendida (visão geral).

Como monitorar uso da CPU do sistema por projetos

1. Para monitorar o uso da CPU de projetos executados no sistema, use o comando prstat com a opção -J.

   % prstat -J

Como monitorar o uso da CPU por projetos em conjuntos de processadores

1. Para monitorar o uso da CPU da projetos em uma lista de conjuntos de processadores, digite:

   % prstat -J -C pset-list

   onde pset-list é uma lista de IDs de conjuntos de processadores que são separados por vírgulas.

Configuração do FSS

Os mesmos comandos que você usa com outras classes de agendamento no sistema do Solaris podem ser usados com FSS. Você pode definir a classe de agendamento, configurar os parâmetros ajustáveis do agendador e configurar as propriedades de processos individuais.

Observe que você pode usar svcadm restart para reiniciar o serviço do agendador. Para obter mais informações, consulte svcadm(1M).

Como tornar o FSS a classe padrão do agendador

O FSS deve ser o agendador padrão no sistema para que a atribuição de compartilhamentos de CPU tenha efeito.

O uso de uma combinação dos comandos priocntl e dispadmin assegura que o FSS se torne o agendador padrão imediatamente e também após a reinicialização.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Defina o agendador padrão do sistema para que seja o FSS.

   # dispadmin -d FSS

   Esta alteração tem efeito na próxima reinicialização. Após a reinicialização, cada processo no sistema é executado na classe de agendamento FSS.

3. Faça com que esta configuração tenha efeito imediatamente, sem reinicializar.

   # priocntl -s -c FSS -i all

Como mover manualmente processos da classe TS para a classe FSS

Você pode mover manualmente processos de uma classe de agendamento para outra classe de agendamento sem alterar a classe de agendamento padrão ou reinicializar. Este procedimento mostra como mover manualmente processos da classe de agendamento TS para a classe de agendamento FSS.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Mova o processo (pid 1) init para as classes de agendamento FSS.

   # priocntl -s -c FSS -i pid 1

3. Mova todos os processos da classe de agendamento TS para a classe de agendamento FSS.

   # priocntl -s -c FSS -i class TS

   ---

   Observação –

   Todos os processos são novamente executados na classe de agendamento TS após a reinicialização.

   ---

Como mover manualmente processos de classes de todos os usuários para a classe FSS

Você pode estar usando uma classe padrão que não seja a TS. Por exemplo, o sistema pode executar um ambiente de janela que use a classe IA por padrão. Você pode mover manualmente todos os processos para a classe de agendamento FSS sem alterar a classe de agendamento padrão e sem reinicializar.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Mova o processo (pid 1) init para as classes de agendamento FSS.

   # priocntl -s -c FSS -i pid 1

3. Mova todos os processos das classes de agendamento atuais para a classe de agendamento FSS.

   # priocntl -s -c FSS -i all

   ---

   Observação –

   Todos os processos são novamente executados na classe de agendamento padrão após a reinicialização.

   ---

Como mover manualmente processos de um projeto para a classe FSS

Você pode mover manualmente processos de um projeto da classe de agendamento atual para uma classe de agendamento FSS.

1. Torne-se superusuário ou assuma uma função equivalente.

   Funções contêm autorizações e comandos privilegiados. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Mova processos executados em ID de projeto 10 para a classe de agendamento FSS.

   # priocntl -s -c FSS -i projid 10

   Os processos do projeto são novamente executados na classe de agendamento padrão após a reinicialização.

Como ajustar parâmetros do agendador

Você pode usar o comando dispadmin para exibir ou alterar parâmetros do agendador do processo enquanto o sistema está em execução. Por exemplo, pode usar dispadmin para examinar e ajustar o valor quantum do tempo do agendador FSS. Quantum de tempo é a quantidade de tempo que um segmento pode ser executado antes de ter de abandonar o processador.

Para exibir o quantum de tempo atual do FSS scheduler enquanto o sistema está em execução, digite:

$ dispadmin -c FSS -g
#
# Fair Share Scheduler Configuration
#
RES=1000
#
# Time Quantum
#
QUANTUM=110

Quando usa a opção -g, você também pode usar a opção -r para especificar a resolução usada para imprimir valores de quantum de tempo. Se nenhuma resolução for especificada, os valores de quantum de tempo são exibidos em milissegundos por padrão.

$ dispadmin -c FSS -g -r 100
#
# Fair Share Scheduler Configuration
#
RES=100
#
# Time Quantum
#
QUANTUM=11

Para definir os parâmetros de agendamento da classe de agendamento do FSS, use dispadmin -s. Os valores no arquivo devem estar no formato definido pela opção -g. Esses valores sobrescrevem os valores no kernel. Digite o seguinte:

$ dispadmin -c FSS -s file

Capítulo 10 Controle da memória física usando o resource capping daemon (visão geral)

O resource capping daemon rcapd permite que você regule o consumo da memória física através de processos executados em projetos que têm limites de recursos definidos.

Solaris 10 8/07: Se estiver executando regiões no sistema, você pode usar rcapd a partir da região global para regular o consumo da memória física em regiões não globais. Consulte o Capítulo 18Planejamento e configuração de regiões não globais (tarefas).

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

• Introdução ao resource capping daemon

• Como funciona o resource capping

• Atributo para limitar o uso da memória física em projetos

• Configuração de rcapd

• Monitorização da utilização de recursos com rcapstat

• Comandos usados com rcapd

Para procedimentos que usam o recurso rcapd, consulte o Capítulo 11Administração do resource capping daemon (tarefas).

O que há de novo no controle da memória física com o uso do resource capping daemon?

Solaris 10: Você agora pode usar o comando projmod para definir o atributo rcap.max-rss no arquivo /etc/project.

Solaris 10 11/06: Foram adicionadas informações sobre a ativação e a desativação do resource capping daemon como um recurso de gerenciamento de serviço (SMF) no Solaris.

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.

Introdução ao resource capping daemon

Um limite de recurso é uma limitação superior aplicada ao consumo de um recurso, como a memória física. Há suporte para limites de memória física por projeto.

O resource capping daemon e seus utilitários associados fornecem mecanismo para a aplicação e a administração do limite de recurso da memória física.

Como o controle de recursos, o limite de recurso pode ser definido pelo uso de atributos de entrada de projeto no banco de dados project. No entanto, enquanto os controles de recursos são aplicados sincronicamente pelo kernel, os limites de recurso são aplicados assincronicamente no nível de usuário pelo resource capping daemon. Com a aplicação assíncrona, ocorre um pequeno atraso como resultado do intervalo de amostragem usado pelo daemon.

Para obter informações sobre rcapd, consulte a página do manual rcapd(1M) Para obter informações sobre projetos e o banco de dados project, consulte o Capítulo 2Projetos e tarefas (visão geral) e a página do manual project(4). Para obter informações sobre controles de recursos, consulte o Capítulo 6Controles de recursos (visão geral).

Como funciona o resource capping

O daemon faz repetidamente amostras da utilização de recursos de projetos que têm limites de memória física. O intervalo de amostragem usado pelo daemon é especificado pelo administrador. Para obter informações adicionais, consulte Determinação de intervalos de amostra Quando a utilização da memória física do sistema excede o limiar de aplicação do limite, e outras condições são atendidas, o daemon atua para reduzir o consumo de recursos do projeto com limites de memória nos níveis de memória ou abaixo deles.

O sistema da memória virtual divide a memória física em segmentos conhecidos como páginas. Páginas são a unidade fundamental da memória física no subsistema de gerenciamento da memória do Solaris. Para ler dados de um arquivo na memória, o sistema da memória virtual lê uma página por vez, ou pagina um arquivo. Para reduzir o consumo de recursos, o daemon pode despaginar, ou realocar, páginas não usadas com freqüência para um dispositivo de permuta, que é uma área fora da memória física.

O daemon gerencia a memória física regulando o tamanho do conjunto residente da carga de trabalho de um projeto em relação ao tamanho de seu conjunto de trabalho. O conjunto residente é o conjunto de páginas residentes na memória física. O conjunto de trabalhos é o conjunto de páginas que a carga de trabalho usa ativamente durante o ciclo de processamento. O conjunto de trabalho muda com o tempo, dependendo do modo de operação do processo e do tipo de dados que estão sendo processados. Idealmente, toda carga de trabalho tem acesso à memória física suficiente para permitir que seu conjunto de trabalho permaneça residente. No entanto, o conjunto de trabalho pode também incluir o uso de armazenamento de disco secundário para conter a memória que não caiba na memória física.

Somente uma instância de rcapd pode ser executada a qualquer tempo.

Atributo para limitar o uso da memória física em projetos

Para definir um limite de recurso da memória física para um projeto, estabeleça um limite do tamanho de conjunto residente (RSS) adicionando este atributo à entrada do banco de dados project:

rcap.max-rss

A quantidade total da memória física, em bytes, que está disponível para processos no projeto.

Por exemplo, a linha seguinte no arquivo /etc/project define um limite RSS de 10 gigabytes para um projeto chamado db.

db:100::db,root::rcap.max-rss=10737418240

O sistema pode arredondar o valor de limite especificado para um tamanho de página.

Você pode usar o comando projmod para definir o atributo rcap.max-rss no arquivo /etc/project:

# projmod -s -K rcap.max-rss=10GB db

O arquivo /etc/project então contém a linha:

db:100::db,root::rcap.max-rss=10737418240

Configuração de rcapd

Você usa o comando rcapadm para configurar o resource capping daemon. Você pode executar as seguintes ações:

• Definir o valor de limite para a aplicação do limite

• Definir intervalos para as operações executadas por rcapd

• Ativar ou desativar o resource capping

• Exibir o status atual do resource capping daemon configurado

Para configurar o daemon, você deve ter privilégios de superusuário ou ter o perfil Gerenciamento de processo na lista de perfis. As funções Gerenciamento de processo e Administrador de sistema incluem o perfil Gerenciamento de processo.

Alterações de configuração podem ser incorporadas ao rcapd de acordo com o intervalo da configuração (consulte Intervalos de operação de rcapd) ou por demanda enviando-se um SIGHUP (consulte a página do manual kill(1)).

Se usado sem argumentos, rcapadm exibe o status atual do resource capping daemon, se foi configurado.

As subseções a seguir discutem a aplicação de limite, os valores de limite e os intervalos de operação de rcapd.

Uso do resource capping daemon em um sistema com regiões instaladas

Você pode controlar o uso do tamanho do conjunto residente (RSS) definindo o recurso capped-memory ao configurar a região. Para obter mais informações, consulte Solaris 10 8/07: controle da memória física e o recurso capped-memory. Você pode executar rcapd em uma região, inclusive a região global, para aplicar limites de memória em projetos nessa região.

Você pode definir um limite provisório da quantidade máxima de memória que pode ser consumida em uma região específica, até a próxima reinicialização. Consulte Como especificar um limite de recurso provisório de uma região.

Se você estiver usando rcapd em uma região para regular o consumo da memória física através de processos executados em projetos com limites de recursos definidos, é necessário configurar o daemon nessa região.

Ao escolher limites de memória para aplicativos em regiões diferentes, geralmente você não precisa levar em consideração que os aplicativos residem em regiões diferentes. A exceção é serviços por região. Serviços por região consomem memória. Este consumo de memória deve ser levado em consideração ao determinar a quantidade da memória física de um sistema, assim como limites de memória.

Não é possível executar rcapd em uma região com marca lx. No entanto, é possível usar o daemon a partir da região global para limitar a memória na região com marca.

Limiar de aplicação de limitação de memória

O limiar de aplicação de limitação de memória é a porcentagem da utilização da memória física no sistema que aciona a aplicação da limitação. Quando o sistema excede esta utilização, limites são aplicados. A memória física usada por aplicativos e pelo kernel está incluída nesta porcentagem. A porcentagem da utilização determina como os limites de memória são aplicados.

Para aplicar limites, a memória pode ser despaginada das cargas de trabalho do projeto.

• A memória pode ser despaginada para reduzir o tamanho da parte da memória que está sobre seu limite para uma determinada carga de trabalho.

• A memória pode ser despaginada para reduzir a proporção da memória física usada que está sobre o limiar da aplicação do limite de memória no sistema.

Uma carga de trabalho é permitida para usar a memória física até seu limite. Uma carga de trabalho pode usar memória adicional desde que a utilização da memória do sistema esteja abaixo do limiar da aplicação do limite de memória.

Para definir o valor para a aplicação do limite, consulte Como definir o limiar de aplicação de limite de memória.

Determinação de valores de limite

Se um limite de projeto for definido muito baixo, talvez não haja memória suficiente para a carga de trabalho continuar efetivamente em condições normais. A paginação que ocorre devido à carga de trabalho requerer mais memória tem um efeito negativo sobre o desempenho do sistema.

Projetos que têm limites definidos muito altos podem consumir memória física disponível antes de seus limites serem excedidos. Neste caso, a memória física é efetivamente gerenciada pelo kernel e não por rcapd.

Ao determinar limites em projetos, leve em consideração os fatores abaixo.

Impacto sobre o sistema de E/S

O daemon pode tentar reduzir o uso da memória física da carga de trabalho de um projeto sempre que o uso de amostrar exceder o limite do projeto. Durante a aplicação do limite, são usados os dispositivos de permuta e outros dispositivos que contêm arquivos que a carga de trabalho mapeou. O desempenho dos dispositivos de permuta é um fator crucial na determinação do desempenho de uma carga de trabalho que rotineiramente excede seu limite. A execução da carga de trabalho é semelhante a sua execução em uma máquina com a mesma quantidade de memória física que o limite da carga de trabalho.

Impacto sobre o uso da CPU

O uso da CPU do daemon varia com o número de processos nas cargas de trabalho do projeto que está limitando e com os tamanhos dos espaços de endereço das cargas de trabalho.

Uma pequena parte do tempo da CPU do daemon é gasta na amostragem do uso de cada carga de trabalho. A adição de processos a cargas de trabalho aumenta o tempo gasto na amostragem do uso.

Outra parte do tempo da CPU do daemon é gasto na aplicação de limites quando são excedidos. O tempo gasto é proporcional à quantidade da memória virtual envolvida. O tempo gasto da CPU aumenta ou diminui em resposta às alterações correspondentes no tamanho total do espaço de endereço de uma carga de trabalho. Estas informações são relatadas na coluna vm da saída de rcapstat. Para obter mais informações, consulte Monitorização da utilização de recursos com rcapstat e a página do manual rcapstat(1).

Relato de memória compartilhada

O daemon rcapd relata o RSS das páginas da memória que são compartilhadas com outros processos ou mapeadas várias vezes dentro do mesmo processo como uma estimativa razoavelmente precisa. Se os processos de diferentes projetos compartilham a mesma memória, então esta memória será incluída no total de RSS de todos os projetos que compartilham a memória.

A estimativa é útil com cargas de trabalho, como bancos de dados que usam memória compartilhada amplamente. Para as cargas de trabalho de banco de dados, você também pode fazer uma amostragem do uso regular do projeto para determinar um valor de limite inicial adequado usando a saída das opções -J ou -Z do comando prstat. Para obter mais informações, consulte a página do manual prstat(1M)

Intervalos de operação de rcapd

Você pode ajustar os intervalos para as operações periódicas executadas por rcapd.

Todos os intervalos são especificados em segundos. As operações de rcapd e seus valores de intervalo padrão são descritos na tabela abaixo.

Para ajustar intervalos, consulte Como definir intervalos de operação.

Determinação de intervalos de escaneamento rcapd

O intervalo de escaneamento controla a freqüência com que rcapd procura novos processos. Em sistemas com muitos processos em execução, o escaneamento da lista leva mais tempo, por isso é preferível estender o intervalo para reduzir o tempo total gasto da CPU. No entanto, o intervalo de escaneamento também representa a quantidade mínima de tempo que um processo deve existir para ser atribuído a uma carga de trabalho limitada. Se houver cargas de trabalho que executam muitos processos breves, rcapd poderá não atribuir os processos a uma carga de trabalho se o intervalo de escaneamento foi estendido.

Determinação de intervalos de amostra

O intervalo de amostra configurado com rcapadm é a quantidade mais curta de tempo que rcapd aguarda entre a amostragem do uso de uma carga de trabalho e a aplicação de um limite, se for excedido. Se você reduzir esse intervalo, rcapd irá, na maioria das condições, aplicar limites com mais freqüência, resultando possivelmente em uma E/S aumentada devido à paginação. No entanto, um intervalo de amostra mais curto pode também diminuir o impacto que um aumento repentino no uso da memória física de uma carga de trabalho específica teria sobre outras cargas de trabalho. A janela entre as amostragens, em que a carga de trabalho pode consumir memória sem demora e possivelmente tomar a memória de outras cargas de trabalho limitadas, é reduzida.

Se o intervalo de amostra especificado para rcapstat for mais curto do que o intervalo especificado para rcapd com rcapadm, a saída de alguns intervalos poderá ser zero. Esta situação ocorre porque rcapd não atualiza estatísticas com mais freqüência do que o intervalo especificado com rcapadm. O intervalo especificado com rcapadm independe do intervalo de amostragem usado por rcapstat.

Monitorização da utilização de recursos com rcapstat

Use rcapstat para monitorar a utilização de recursos de projetos limitados. Para visualizar um relatório rcapstat de exemplo, consulte Produção de relatórios com rcapstat.

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

Especifica o intervalo de amostragem em segundos. O intervalo padrão é 5 segundos.

count

Especifica o número de vezes que a estatística será repetida. Por padrão, rcapstat relata estatísticas até um sinal de término ser recebido ou até a saída do processo de rcapd.

As estatísticas de página no primeiro relatório emitido por rcapstat mostram a atividade desde que o daemon começou. Relatórios subseqüentes refletem a atividade desde que o último relatório foi emitido.

A tabela abaixo define os cabeçalhos de colunas em um relatóriorcapstat.

Comandos usados com rcapd

Capítulo 11 Administração do resource capping daemon (tarefas)

Este capítulo contém procedimentos para configurar e usar o resource capping daemon rcapd.

Para uma visão geral de rcapd, consulte o Capítulo 10Controle da memória física usando o resource capping daemon (visão geral).

Configuração e uso do resource capping daemon (mapa de tarefas)

Administração do resource capping daemon com rcapadm

Esta seção contém procedimentos para configurar o resource capping daemon com o comando rcapadm. Consulte a Configuração de rcapd e a página do manual rcapadm(1M) para mais informações. Também há informações sobre o uso do rcapadm para especificar um limite de recurso provisório de uma região.

Se usado sem argumentos, rcapadm exibe o status atual do resource capping daemon, se foi configurado.

Como definir o limiar de aplicação de limite de memória

Limites podem ser configurados para que não sejam aplicados antes que a memória física disponível para processos esteja baixa. Para obter mais informações, consulte Limiar de aplicação de limitação de memória.

O valor mínimo (e padrão) é 0, o que significa que os limites de memória são sempre aplicados. Para definir um mínimo diferente, adote este procedimento.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter informações sobre como criar a função e atribuí-la a um usuário, consulte Gerenciamento de RBAC (mapa de tarefas) em Guia de administração de sistema: serviços de segurança.

2. Use a opção -c de rcapadm para definir um valor diferente de utilização de memória física para a aplicação do limite de memória.

   # rcapadm -c percent

   percent é o intervalo de 0 a 100. Valores mais altos são menos restritivos. Um valor mais alto significa que as cargas de trabalho de projeto limitadas podem ser executadas sem a aplicação de limites antes de a utilização da memória do sistema exceder esse limiar.

Consulte também

Para exibir a utilização da memória física atual e o limiar de aplicação de limite, consulte Relato da utilização de memória e limiar de aplicação de limite de memória.

Como definir intervalos de operação

Intervalos de operação de rcapd contém informações sobre os intervalos para as operações periódicas executadas por rcapd. Para definir intervalos de operação usando rcapadm, adote este procedimento.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter informações sobre como criar a função e atribuí-la a um usuário, consulte Gerenciamento de RBAC (mapa de tarefas) em Guia de administração de sistema: serviços de segurança.

2. Use a opção -i para definir valores de intervalo.

   # rcapadm -i interval=value,...,interval=value

   ---

   Observação –

   Todos os valores de intervalo são especificados em segundos.

   ---

Como ativar o resource capping

Há três maneiras de ativar o resource capping em seu sistema. A ativação do resource capping também define o arquivo /etc/rcap.conf com valores padrão.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter informações sobre como criar a função e atribuí-la a um usuário, consulte Gerenciamento de RBAC (mapa de tarefas) em Guia de administração de sistema: serviços de segurança.

2. Ative o resource capping daemon usando uma das seguintes maneiras:

   • Ative o resource capping usando o comando svcadm.

     # svcadm enable rcap

   • Ative o resource capping daemon para que seja iniciado agora e também seja iniciado toda vez que o sistema for inicializado, digite:

     # rcapadm -E

   • Ative o resource capping daemon na inicialização sem iniciá-lo agora especificando também a opção -n:

     # rcapadm -n -E

Como desativar o resource capping

Há três maneiras de desativar o resource capping em seus sistema.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter informações sobre como criar a função e atribuí-la a um usuário, consulte Gerenciamento de RBAC (mapa de tarefas) em Guia de administração de sistema: serviços de segurança.

2. Desative o resource capping daemon usando uma das seguintes maneiras:

   • Desative o resource capping usando o comando svcadm.

     # svcadm disable rcap

   • Para desativar o resource capping daemon, de modo que seja parado agora e não seja iniciado quando o sistema for inicializado, digite:

     # rcapadm -D

   • Para desativar o resource capping daemon sem pará-lo, especifique também a opção -n:

     # rcapadm -n -D

   ---

   Dica –

   Desativação segura do resource capping daemon

   ---

   Utilize o comando svcadm ou o comando rcapadm com -D para desativar rcapd com segurança. Se o daemon for eliminado (consulte a página do manual kill(1)), os processos poderão ser deixados em um estado de parado e requerer que seja reiniciado manualmente. Para retomar a execução de um processo, use o comando prun. Para obter mais informações, consulte a página do manual prun(1).

Como especificar um limite de recurso provisório de uma região

Esse procedimento é usado para alocar a quantidade máxima de memória que pode ser consumida por uma região específica. Esse valor é válido somente até a próxima reinicialização. Para definir um limite permanente, use o comando zonecfg.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo.

2. Defina o valor máximo da memória como 512 Mbytes para a região my-zone.

   # rcapadm -z testzone -m 512M

Produção de relatórios com rcapstat

Use rcapstat para relatar estatística de resource capping. Monitorização da utilização de recursos com rcapstat explica como usar o comando rcapstat para gerar relatórios. Essa seção também descreve os cabeçalhos de coluna no relatório. A página do manual rcapstat(1) também contém estas informações.

As subseções a seguir usam exemplos para ilustrar como produzir relatórios para propósitos específicos.

Relatório de informações de limite e projeto

Neste exemplo, limites são definidos para dois projetos associados a dois usuários. O user1 tem um limite de 50 megabytes, e o user2 tem um limite de 10 megabytes.

O comando a seguir produz cinco relatórios a intervalos de amostragem de 5 segundos.

user1machine% rcapstat 5 5
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M   50M    0K 3312K    0K
 78194   user2      1  2368K  1856K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1856K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1928K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1928K   10M    0K    0K    0K    0K
    id project  nproc     vm    rss   cap    at avgat    pg avgpg
112270   user1     24   123M    35M   50M    0K    0K    0K    0K
 78194   user2      1  2368K  1928K   10M    0K    0K    0K    0K 

As três primeiras linhas de saída constituem o primeiro relatório, que contém as informações de limite e projeto para os dois projetos e estatística de paginação desde que rcapd foi iniciado. As colunas at e pg são um número maior do que zero para o user1 e zero para o user2, o que indica que ao mesmo tempo no histórico do daemon o user1 excedeu seu limite, mas o user2 não.

Os relatórios subseqüentes não relatam atividade significativa.

Monitoração do RSS de um projeto

O exemplo a seguir mostra o user1 do projeto, que tem um RSS em excesso do limite de RSS.

O comando a seguir produz cinco relatórios a intervalos de amostragem de 5 segundos.

user1machine% rcapstat 5 5

    id project  nproc    vm   rss   cap    at avgat     pg  avgpg
376565   user1      3 6249M 6144M 6144M  690M  220M  5528K  2764K
376565   user1      3 6249M 6144M 6144M    0M  131M  4912K  1637K
376565   user1      3 6249M 6171M 6144M   27M  147M  6048K  2016K
376565   user1      3 6249M 6146M 6144M 4872M  174M  4368K  1456K
376565   user1      3 6249M 6156M 6144M   12M  161M  3376K  1125K

O projeto do user1 tem três processos que estão usando ativamente a memória física. Os valores positivos na coluna pg indicam que rcapd está despaginando consistentemente a memória ao tentar observar o limite reduzindo a utilização da memória física dos processos do projeto. No entanto, rcapd não consegue manter o RSS abaixo do valor de limite. Isto é indicado pelos valores variáveis de rss que não mostram uma diminuição correspondente. Assim que a memória é despaginada, a carga de trabalho usa-a novamente e a contagem do RSS volta a subir. Isso significa que toda a memória residente do projeto está sendo usada ativamente e que o tamanho do conjunto de trabalho (WSS) é maior do que o limite. Assim, rcapd é forçado a despaginar uma parte do conjunto de trabalho para observar o limite. Nesta condição, o sistema continuará a experimentar altas taxas de falha de página e E/S associadas, até que um do que se segue ocorra:

• O WSS se torna menor.

• O limite é aumentado.

• O padrão de acesso à memória do aplicativo é alterado.

Nesta situação, o encurtamento do intervalo de amostragem poderia reduzir a discrepância entre o valor do RSS e o valor do limite, fazendo rcapd efetuar a amostra da carga de trabalho e aplicar limites com mais freqüência.

Ocorre uma falha de página quando uma nova página deve ser criada ou quando o sistema deve copiar uma página de um dispositivo de permuta.

Determinação do tamanho conjunto de trabalho de um projeto

O exemplo a seguir é uma continuação do exemplo anterior, e usa o mesmo projeto.

O exemplo anterior mostra que o projeto do user1 está usando mais memória física do que o limite permite. Este exemplo mostra a quantidade de memória requerida pela carga de trabalho do projeto.

user1machine% rcapstat 5 5
    id project  nproc    vm   rss   cap    at avgat     pg  avgpg
376565   user1      3 6249M 6144M 6144M  690M    0K   689M     0K
376565   user1      3 6249M 6144M 6144M    0K    0K     0K     0K
376565   user1      3 6249M 6171M 6144M   27M    0K    27M     0K
376565   user1      3 6249M 6146M 6144M 4872K    0K  4816K     0K
376565   user1      3 6249M 6156M 6144M   12M    0K    12M     0K
376565   user1      3 6249M 6150M 6144M 5848K    0K  5816K     0K
376565   user1      3 6249M 6155M 6144M   11M    0K    11M     0K
376565   user1      3 6249M 6150M   10G   32K    0K    32K     0K
376565   user1      3 6249M 6214M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K
376565   user1      3 6249M 6247M   10G    0K    0K     0K     0K

Na metade do ciclo, o limite no projeto do user1 foi aumentado de 6 gigabytes para 10 gigabytes. Este aumento interrompe a aplicação do limite e permite que o tamanho do conjunto residente aumente, limitado somente por outros processos e pela quantidade de memória na máquina. A coluna rss poderia se estabilizar para refletir o tamanho do conjunto de trabalho do projeto (WSS), 6247 M neste exemplo. Este é o valor de limite mínimo que permite que os processos do projeto sejam operados sem incorrerem continuamente em falhas de página.

Enquanto o limite no user1 é 6 segundos, em cada intervalo de amostra de 5 segundos o RSS diminui e a I/O aumenta à medida que rcapd despagina parte da memória da carga de trabalho. Logo depois que uma despaginação é concluída, a carga de trabalho que necessita dessas páginas as repagina enquanto continua sendo executada. Esse ciclo se repete até que o limite aumenta para 10 gigabytes, aproximadamente na metade do exemplo. Em seguida, o RSS se estabiliza em 6,1 gigabytes. Já que o RSS da carga de trabalho agora está abaixo do limite, não ocorrem mais paginações. A E/S associada à paginação também é interrompida. Portanto, o projeto requeria 6,1 gigabytes para realizar o trabalho que estava fazendo no momento em que estava sendo observado.

Consulte também as páginas do manual vmstat(1M) e iostat(1M).

Relato da utilização de memória e limiar de aplicação de limite de memória

Você pode usar a opção -g de rcapstat para relatar o seguinte:

• A utilização de memória física atual como um percentual da memória física instalada no sistema

• O limite da aplicação de limiar de memória do sistema definido por rcapadm

A opção -g faz com que uma utilização de memória e uma linha de aplicação de limite sejam impressas no fim do relatório de cada intervalo.

# rcapstat -g
    id project   nproc    vm   rss   cap    at avgat   pg  avgpg
376565    rcap       0    0K    0K   10G    0K    0K   0K     0K
physical memory utilization: 55%   cap enforcement threshold: 0%
    id project   nproc    vm   rss   cap    at avgat   pg  avgpg
376565    rcap       0    0K    0K   10G    0K    0K   0K     0K
physical memory utilization: 55%   cap enforcement threshold: 0%

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.

Capítulo 13 Criação e administração de grupos de recursos (tarefas)

Este capítulo descreve como configurar e administrar grupos de recursos no sistema.

Para obter informações complementares sobre grupos de recursos, consulte o Capítulo 12Grupos de recursos (visão geral).

Administração de grupos de recursos dinâmicos (mapa de tarefas)

Ativação e desativação da facilidade de grupos

A partir da versão Solaris 10 11/06, você pode ativar e desativar serviços de grupos de recursos e grupos de recursos dinâmicos no sistema usando o comando svcadm, descrito na página do manual svcadm(1M).

Você também pode usar o comando pooladm, descrito na página do manual pooladm(1M), para executar as seguintes tarefas:

• Ativar a facilidade de grupos para que grupos possam ser manipulados

• Desativar a facilidade de grupos para que grupos não possam ser manipulados

Quando o sistema é atualizado, se a estrutura de grupos de recursos estiver ativada e um arquivo /etc/pooladm.conf existir, o serviço de grupos será ativado e a configuração contida no arquivo será aplicada ao sistema.

Solaris 10 11/06 e posterior: como ativar o serviço de grupos de recursos usando svcadm

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Ative o serviço de grupos de recursos.

   # svcadm enable system/pools:default

Solaris 10 11/06 e posterior: como desativar o serviço de grupos de recursos usando svcadm

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Desative o serviço de grupos de recursos.

   # svcadm disable system/pools:default

Solaris 10 11/06 e posterior: como ativar o serviço de grupos de recursos dinâmicos usando svcadm

1. Torne-se superusuário ou assuma uma função que inclua o perfil de direitos Gerenciamento de serviço.

   Funções contêm autorizações e comandos privilegiados. Para obter informações sobre como criar a função e atribuir a função a um usuário, consulte Configuring RBAC (Task Map) no System Administration Guide: Security Services Managing RBAC (Task Map) no System Administration Guide: Security Services.

2. Ative o serviço de grupos de recursos dinâmicos.

   # svcadm enable system/pools/dynamic:default

Exemplo 13–1 Dependência do serviço de grupos de recursos dinâmicos no serviço de grupos de recursos

Este exemplo mostra que você deve primeiro ativar grupos de recursos, se desejar executar DRP.

Há uma dependência entre grupos de recursos e grupos de recursos dinâmicos. DRP agora é um serviço dependente de grupos de recursos. DRP pode ser ativado e desativado independentemente dos grupos de recursos.

A exibição a abaixo mostra que grupos de recursos e grupos de recursos dinâmicos estão desativados atualmente:

# svcs *pool*
STATE          STIME    FMRI
disabled       10:32:26 svc:/system/pools/dynamic:default
disabled       10:32:26 svc:/system/pools:default

Ative grupos de recursos dinâmicos:

# svcadm enable svc:/system/pools/dynamic:default
# svcs -a | grep pool
disabled       10:39:00 svc:/system/pools:default
offline        10:39:12 svc:/system/pools/dynamic:default

Observe que o serviço DRP ainda está off-line.

Use a opção -x do comando svcs para determinar por que o serviço DRP está off-line:

# svcs -x *pool*
svc:/system/pools:default (resource pools framework)
 State: disabled since Wed 25 Jan 2006 10:39:00 AM GMT
Reason: Disabled by an administrator.
   See: http://sun.com/msg/SMF-8000-05
   See: libpool(3LIB)
   See: pooladm(1M)
   See: poolbind(1M)
   See: poolcfg(1M)
   See: poolstat(1M)
   See: /var/svc/log/system-pools:default.log
Impact: 1 dependent service is not running.  (Use -v for list.)

svc:/system/pools/dynamic:default (dynamic resource pools)
 State: offline since Wed 25 Jan 2006 10:39:12 AM GMT
Reason: Service svc:/system/pools:default is disabled.
   See: http://sun.com/msg/SMF-8000-GE
   See: poold(1M)
   See: /var/svc/log/system-pools-dynamic:default.log
Impact: This service is not running.

Ative o serviço de grupos de recursos para que o serviço DRP possa ser executado:

# svcadm enable svc:/system/pools:default

Quando o comando svcs *pool* é usado, o sistema exibe:

# svcs *pool*
STATE          STIME    FMRI
online         10:40:27 svc:/system/pools:default
online         10:40:27 svc:/system/pools/dynamic:default

Exemplo 13–2 Efeito nos grupos de recursos dinâmicos quando o serviço de grupos de recursos está desativado

Se os dois serviços estiverem on-line e você desativar o serviço de grupos de recursos:

# svcadm disable svc:/system/pools:default 

Quando o comando svcs *pool* é usado, o sistema exibe:

# svcs *pool*
STATE          STIME    FMRI
disabled       10:41:05 svc:/system/pools:default
online         10:40:27 svc:/system/pools/dynamic:default
# svcs *pool*
STATE          STIME    FMRI
disabled       10:41:05 svc:/system/pools:default
online         10:40:27 svc:/system/pools/dynamic:default

Mas no fim o serviço DRP passa para offline porque o serviço de grupos de recursos foi desativado:

# svcs *pool*
STATE          STIME    FMRI
disabled       10:41:05 svc:/system/pools:default
offline        10:41:12 svc:/system/pools/dynamic:default

Determine por que o serviço DRP está off-line:

# svcs -x *pool*
svc:/system/pools:default (resource pools framework)
 State: disabled since Wed 25 Jan 2006 10:41:05 AM GMT
Reason: Disabled by an administrator.
   See: http://sun.com/msg/SMF-8000-05
   See: libpool(3LIB)
   See: pooladm(1M)
   See: poolbind(1M)
   See: poolcfg(1M)
   See: poolstat(1M)
   See: /var/svc/log/system-pools:default.log
Impact: 1 dependent service is not running.  (Use -v for list.)

svc:/system/pools/dynamic:default (dynamic resource pools)
 State: offline since Wed 25 Jan 2006 10:41:12 AM GMT
Reason: Service svc:/system/pools:default is disabled.
   See: http://sun.com/msg/SMF-8000-GE
   See: poold(1M)
   See: /var/svc/log/system-pools-dynamic:default.log
Impact: This service is not running.

Grupos de recursos devem ser iniciados para DRP funcionar. Por exemplo, grupos de recursos podem ser iniciados usando-se o comando pooladm com a opção -e:

# pooladm -e

Em seguida o comando svcs *pool* exibe:

# svcs *pool*
STATE          STIME    FMRI
online         10:42:23 svc:/system/pools:default
online         10:42:24 svc:/system/pools/dynamic:default

Solaris 10 11/06 e posterior: como desativar o serviço de grupos de recursos dinâmicos usando svcadm

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Desativa o serviço de grupos de recursos dinâmicos.

   # svcadm disable system/pools/dynamic:default

Como ativar grupos de recursos usando pooladm

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Ative a facilidade de grupos.

   # pooladm -e

Como desativar grupos de recursos usando pooladm

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Desative a facilidade de grupos.

   # pooladm -d

Configuração de grupos

Como criar uma configuração estática

Use a -s opção /usr/sbin/pooladm para criar um arquivo de configuração estática que coincida com a configuração dinâmica atual. A menos que um nome de arquivo diferente seja especificado, o local padrão /etc/pooladm.conf é usado.

Comprometa a configuração usando o comando pooladm com a opção -c. Em seguida, use o comando pooladm com a opção -s para atualizar a configuração estática, de modo que coincida com o estado da configuração dinâmica.

A nova funcionalidade pooladm -s é preferida à funcionalidade anterior poolcfg -c discover para criar uma nova configuração que coincida com a configuração dinâmica.

Antes de começar

Ative grupos no sistema.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Atualize o arquivo de configuração estática para coincidir com a configuração dinâmica atual.

   # pooladm -s

3. Visualize o conteúdo do arquivo de configuração em uma forma legível.

   Observe que a configuração contém elementos padrão criados pelo sistema.

   # poolcfg -c info system tester string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line

4. Comprometa a configuração em /etc/pooladm.conf .

   # pooladm -c

5. (Opcional) Para copiar a configuração dinâmica para um arquivo de configuração estática chamado /tmp/backup, digite o seguinte:

   # pooladm -s /tmp/backup

Como modificar uma configuração

Para otimizar a configuração, crie um conjunto de processadores nomeado pset_batch e um grupo nomeado pool_batch. Em seguida una o grupo e o conjunto de processados com uma associação.

Observe que você deve usar argumentos de subcomando que contenham espaço em branco.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Crie o conjunto de processadores pset_batch.

   # poolcfg -c 'create pset pset_batch (uint pset.min = 2; uint pset.max = 10)'

3. Crie o grupo pool_batch.

   # poolcfg -c 'create pool pool_batch'

4. Una o grupo e o conjunto de processadores com uma associação.

   # poolcfg -c 'associate pool pool_batch (pset pset_batch)'

5. Exiba a configuração editada.

   # poolcfg -c info system tester string system.comment kernel state int system.version 1 boolean system.bind-default true int system.poold.pid 177916 pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line pool pool_batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment pset pset_batch pset pset_batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line

6. Comprometa a configuração em /etc/pooladm.conf .

   # pooladm -c

7. (Opcional) Para copiar a configuração dinâmica para um arquivo de configuração estática nomeado /tmp/backup, digite o seguinte:

   # pooladm -s /tmp/backup

Como associar um grupo a uma classe de agendamento

Você pode associar um grupo a uma classe de agendamento para que todos os processos vinculados a esse grupo usem este agendador. Para isso, defina a propriedade pool.scheduler como o nome do agendador. Este exemplo associa o grupo pool_batch ao fair share scheduler (FSS).

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter informações sobre como criar a função e atribuí-la a um usuário, consulte Gerenciamento de RBAC (mapa de tarefas) em Guia de administração de sistema: serviços de segurança.

2. Modifique o grupo pool_batch para ser associado ao FSS.

   # poolcfg -c 'modify pool pool_batch (string pool.scheduler="FSS")'

3. Exiba a configuração editada.

   # poolcfg -c info system tester string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line pool pool_batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler FSS pset batch pset pset_batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line

4. Comprometa a configuração em /etc/pooladm.conf :

   # pooladm -c

5. (Opcional) Para copiar a configuração dinâmica para um arquivo de configuração estática chamado /tmp/backup, digite o seguinte:

   # pooladm -s /tmp/backup

Como definir restrições de configuração

Restrições afetam a gama de configurações possíveis eliminando algumas das alterações potenciais que podem ser feitas em uma configuração. Este procedimento mostra como definir a propriedade cpu.pinned.

Nos exemplos abaixo, cpuid é um inteiro.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Modifique a propriedade cpu.pinned na configuração estática ou dinâmica:

   • Modifique a configuração de tempo de inicialização (estática):

     # poolcfg -c 'modify cpu <cpuid> (boolean cpu.pinned = true)'

   • Modifique a configuração de execução (dinâmica) sem modificar a configuração de tempo de inicialização:

     # poolcfg -dc 'modify cpu <cpuid> (boolean cpu.pinned = true)'

Como definir objetivos de configuração

Você pode especificar objetivos para poold a serem considerados ao tomar uma ação corretiva.

No procedimento abaixo, o objetivo wt-load está sendo definido de modo que poold tente coincidir a alocação de recursos com a utilização de recursos. O objetivo locality é desativado para auxiliar na realização do objetivo desta configuração.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Modifique tester do sistema para favorecer o objetivo wt-load.

   # poolcfg -c 'modify system tester (string system.poold.objectives="wt-load")'

3. Desative o objetivo locality para o conjunto de processadores padrão.

   # poolcfg -c 'modify pset pset_default (string pset.poold.objectives="locality none")'

4. Desative o objetivo locality para o conjunto de processadores pset_batch.

   # poolcfg -c 'modify pset pset_batch (string pset.poold.objectives="locality none")'

5. Exiba a configuração editada.

   # poolcfg -c info system tester string system.comment int system.version 1 boolean system.bind-default true int system.poold.pid 177916 string system.poold.objectives wt-load pool pool_default int pool.sys_id 0 boolean pool.active true boolean pool.default true int pool.importance 1 string pool.comment pset pset_default pset pset_default int pset.sys_id -1 boolean pset.default true uint pset.min 1 uint pset.max 65536 string pset.units population uint pset.load 10 uint pset.size 4 string pset.comment boolean testnullchanged true string pset.poold.objectives locality none cpu int cpu.sys_id 3 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 2 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 1 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 0 string cpu.comment string cpu.status on-line pool pool_batch boolean pool.default false boolean pool.active true int pool.importance 1 string pool.comment string pool.scheduler FSS pset batch pset pset_batch int pset.sys_id -2 string pset.units population boolean pset.default true uint pset.max 10 uint pset.min 2 string pset.comment boolean pset.escapable false uint pset.load 0 uint pset.size 0 string pset.poold.objectives locality none cpu int cpu.sys_id 5 string cpu.comment string cpu.status on-line cpu int cpu.sys_id 4 string cpu.comment string cpu.status on-line

6. Comprometa a configuração em /etc/pooladm.conf .

   # pooladm -c

7. (Opcional) Para copiar a configuração dinâmica para um arquivo de configuração estática chamado /tmp/backup, digite o seguinte:

   # pooladm -s /tmp/backup

Como definir o nível de registro de poold

Para especificar o nível de informações de registro que poold gera, defina a propriedade system.poold.log-level na configuração de poold. A configuração de poold é contida na configuração de libpool. Para obter informações, consulte Informações de registro do poold e as páginas do manual poolcfg(1M) e libpool(3LIB).

Você também pode usar o comando poold na linha de comando para especificar o nível de informações de registro que poold gera.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Defina o nível de registro usando o comando poold com a opção with the -l e um parâmetro, por exemplo, INFO.

   # /usr/lib/pool/poold -l INFO

   Para obter informações sobre parâmetros disponíveis, consulte Informações de registro do poold. O nível de registro padrão é NOTICE.

Como usar arquivos de comando com poolcfg

O comando poolcfg com a opção -f pode tomar entrada de um arquivo de texto que contenha argumentos do subcomando poolcfg para a opção -c. Este método é apropriado quando você deseja que um conjunto de operações seja executado. Quando vários comando são processados, a configuração é somente atualizada se todos os comandos tiverem êxito. Para configurações grandes ou complexas, esta técnica pode ser mais útil do que chamadas por subcomando.

Observe que, em arquivos de comando, o caractere # atua como uma marca de comentário para o resto da linha.

1. Crie um arquivo de entrada poolcmds.txt .

   $ cat > poolcmds.txt create system tester create pset pset_batch (uint pset.min = 2; uint pset.max = 10) create pool pool_batch associate pool pool_batch (pset pset_batch)

2. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter informações sobre como criar a função e atribuí-la a um usuário, consulte “Gerenciamento de RBAC” no Guia de administração de sistema: serviços de segurança.

3. Execute o comando:

   # /usr/sbin/poolcfg -f poolcmds.txt

Transferência de recursos

Use o argumento do subcomando transfer para a opção -c de poolcfg com a opção -d para transferir recursos no kernel. A opção -d especifica que o comando opere diretamente no kernel e não tome entrada de um arquivo.

O procedimento abaixo move duas CPUs do conjunto de processadores pset1 para o conjunto de processadores pset2 no kernel.

Como mover CPUs entre conjuntos de processadores

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Mova duas CPUs de pset1 para pset2.

   As subcláusulas from e to podem ser usadas em qualquer ordem. Somente uma subclásula to e fromtem suporte do comando.

   # poolcfg -dc 'transfer 2 from pset pset1 to pset2'

Exemplo 13–3 Método alternativo para mover CPUs entre conjuntos de processadores

Se IDs específicos conhecidos de um tipo de recurso tiverem de ser transferidos, uma sintaxe alternativa será fornecida. Por exemplo, o seguinte comando atribui duas CPUs com IDs 0 e 2 ao conjunto de processadores pset_large:

# poolcfg -dc "transfer to pset pset_large (cpu 0; cpu 2)"

Solução de problemas

Se uma transferência falhar porque não há recursos suficientes para atender a solicitação ou porque os IDs específicos não podem ser localizados, o sistema exibirá uma mensagem de erro.

Ativação e remoção de configurações de grupos

Use o comando pooladm para tornar ativa uma determinada configuração de grupo para remover a configuração de grupo atualmente ativa. Para obter mais informações este comando, consulte a página do manual pooladm(1M).

Como ativar uma configuração de grupo

Para ativar a configuração no arquivo de configuração padrão, /etc/pooladm.conf, chame pooladm com a opção -c, “comprometa a configuração.”

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Comprometa a configuração em /etc/pooladm.conf .

   # pooladm -c

3. (Opcional) Copie a configuração dinâmica para um arquivo de configuração estática, por exemplo, /tmp/backup.

   # pooladm -s /tmp/backup

Como validar uma configuração antes de comprometê-la

Você pode usar a opção -n com a opção -c para testar o que acontecerá quando ocorrer a validação. A configuração não será realmente comprometida.

O comando abaixo tenta validar a configuração contida em /home/admin/newconfig. Quaisquer erros encontrados são exibidos, mas a configuração propriamente dita não é modificada.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Teste a validade da configuração antes de comprometê-la.

   # pooladm -n -c /home/admin/newconfig

Como remover uma configuração de grupo

Para remover a atual configuração ativa e retornar todos os recursos associados, como conjuntos de processadores, para o status padrão, use a opção -x para “remover a configuração.”

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Remova a atual configuração ativa.

   # pooladm -x

   A opção - x para pooladm remove da configuração dinâmica todos os elementos definidos pelo usuário. Todos os recursos são revertidos para os estados padrão, e todas as vinculações de grupos são substituídas por um vínculo com o grupo padrão.

Mescla de classes de agendamento dentro de um conjunto de processadores

Você pode mesclar processos com segurança nas classes TS e IA no mesmo conjunto de processadores. A mescla de outras classes de agendamento dentro de um conjunto de processadores pode levar a resultados imprevisíveis. Se o uso de pooladm -x resultar em classes de agendamento mescladas dentro de um conjunto de processadores, use o comando priocntl para mover processos em execução para uma classe de agendamento diferente. Consulte Como mover manualmente processos da classe TS para a classe FSS Consulte também a página do manual priocntl(1).

Definição de atributos de grupos e vinculação a um grupo

Você pode definir um atributo project.pool para associar um grupo de recursos a um projeto.

Você pode vincular um processo em execução a um grupo de duas maneiras:

• Você pode usar o comando poolbind, descrito em poolbind(1M), para vincular um processo específico a um grupo de recursos nomeado.

• Você pode usar o atributo project.pool no banco de dados de project para identificar a vinculação de grupo para uma nova sessão de login ou uma tarefa que é iniciada através do comando newtask. Consulte as páginas do manual newtask(1), projmod(1M), e project(4).

Como vincular processos a um grupo

O procedimento abaixo usar poolbind com a opção -p para vincular manualmente um processo (neste caso, o shell atual) a um grupo nomeado ohare.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Vincule manualmente um processo a um grupo:

   # poolbind -p ohare $$

3. Verifique a vinculação do grupo para o processo usando poolbind com a opção -q.

   $ poolbind -q $$ 155509 ohare

   O sistema exibe o ID do processo e a vinculação do grupo.

Como vincular tarefas ou projetos a um grupo

Para vincular tarefas ou projetos a um grupo, use o comando poolbind com a opção -i. O exemplo abaixo vincula todos os processos no projeto airmiles ao grupo laguardia.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Vincule todos os processos no projeto airmiles ao grupo laguardia.

   # poolbind -i project -p laguardia airmiles

Como definir o atributo project.pool para um projeto

Você pode definir o atributo project.pool para vincular processos de um projeto a um grupo de recursos.

1. Torne-se superusuário ou assuma uma função que inclua o perfil Gerenciamento de processo.

   A função Administrador de sistema inclui o perfil Gerenciamento de processo. Para obter mais informações sobre funções, consulte Using the Solaris Management Tools With RBAC (Task Map) no System Administration Guide: Basic Administration .

2. Adicione um atributo project.pool a cada entrada no banco de dados de project.

   # projmod -a -K project.pool=poolname project

Como usar atributos de project para vincular um processo a um grupo diferente

Suponha que você tem uma configuração com dois grupos nomeados studio e backstage. O arquivo /etc/project tem o seguinte conteúdo:

user.paul:1024::::project.pool=studio
user.george:1024::::project.pool=studio
user.ringo:1024::::project.pool=backstage
passes:1027::paul::project.pool=backstage

Com esta configuração, processos que são iniciados pelo usuário paul são vinculados por padrão ao grupo studio.

O usuário paul pode modificar a vinculação de grupo para processos que ele inicia. paul pode usar newtask para vincular trabalho ao grupo backstage também, iniciando o projeto passes.