Parte I Gestión de recursos

Esta parte introduce la administración de recursos de Solaris 10, que permite controlar el modo en que las aplicaciones utilizan los recursos del sistema disponibles.

Capítulo 1 Introducción a administración de recursos de Solaris 10

La función de administración de recursos es un componente del entorno de contenedores de Solaris. La administración de recursos permite controlar el modo en que las aplicaciones utilizan los recursos del sistema. Se puede:

• Asignar recursos informáticos, como tiempo del procesador

• Supervisar el modo en que se utilizan las asignaciones y luego ajustarlas según sea preciso

• Generar información de contabilidad ampliada para análisis, facturación y planificación de capacidades

En este capítulo se tratan los temas siguientes.

• Información general sobre la gestión de recursos

• Cuándo utilizar la administración de recursos

• Configuración de la administración de recursos (mapa de tareas)

Información general sobre la gestión de recursos

Los entornos informáticos modernos deben proporcionar una respuesta flexible a las diferentes cargas de trabajo que generan las distintas aplicaciones de un sistema. Una carga de trabajo es una adición de todos los procesos de una aplicación o grupo de aplicaciones. Si no se utilizan las funciones de administración de recursos, el sistema operativo Solaris responde a las demandas de carga de trabajo adaptándose a las nuevas solicitudes de aplicaciones de forma dinámica. Esta respuesta predeterminada general significa que toda la actividad del sistema tiene el mismo acceso a los recursos. Las funciones de administración de recursos de Solaris permiten tratar las cargas de trabajo individualmente. Se puede:

• Restringir el acceso a un recurso específico

• Ofrecer recursos a las cargas de trabajo de modo preferencial

• Aislar cargas de trabajo entre sí

La capacidad de minimizar los compromisos de rendimiento de varias cargas de trabajo, junto con las funciones que supervisan el uso de los recursos, se denomina administración de recursos. La administración de recursos se implementa a través de un conjunto de algoritmos. Los algoritmos controlan las series de solicitudes de capacidades que presenta una aplicación durante su ejecución.

Las funciones de administración de recursos permiten modificar el comportamiento predeterminado del sistema operativo con respecto a las diferentes cargas de trabajo. El comportamiento hace referencia principalmente al conjunto de decisiones que toman los algoritmos del sistema operativo cuando una aplicación presenta una o más solicitudes de recursos para el sistema. Puede utilizar las funciones de administración de recursos para:

• Denegar recursos o preferir una aplicación para un conjunto de asignaciones mayor que no se permitiría con otra aplicación

• Tratar determinadas asignaciones de forma colectiva en lugar de utilizar mecanismos aislados

La implementación de una configuración del sistema que utilice las funciones de administración de recursos puede tener varias finalidades. Se puede:

• Impedir a una aplicación el consumo indiscriminado de recursos

• Cambiar una prioridad de aplicación basándose en eventos externos

• Equilibrar las garantías de recursos para un conjunto de aplicaciones con el fin de maximizar el uso del sistema

Al planificar una configuración administrada por recursos, algunos de los requisitos clave son:

• Identificar las cargas de trabajo implicadas en el sistema

• Distinguir las cargas de trabajo que no están en conflicto de las que tienen requisitos de rendimiento que afectan a las cargas se trabajo principales

Una vez identificadas las cargas de trabajo conflictivas y las de cooperación, puede crear una configuración de recursos que presente el menor compromiso para los objetivos de servicio del negocio, dentro de las limitaciones de las funciones del sistema.

El sistema Solaris cuenta con una administración de recursos eficaz que ofrece mecanismos de control, de notificación y de supervisión. Muchas de estas funciones se proporcionan a través de mejoras en los mecanismos existentes, como el sistema de archivos proc(4), los conjuntos de procesadores y las clases de planificación. Otras funciones son específicas de la administración de recursos. Estas funciones se describen en los capítulos siguientes.

Clasificación de los recursos

Un recurso es cualquier aspecto del sistema informático que pueda manipularse con la finalidad de cambiar el comportamiento de la aplicación. En consecuencia, un recurso es una capacidad que solicita una aplicación implícita o explícitamente. Si se deniega o limita la capacidad, la ejecución de una aplicación potente es más lenta.

La clasificación de recursos, a diferencia de la identificación de recursos, puede realizarse para una serie de ejes. Los ejes se pueden solicitar de forma implícita (en contraposición a su solicitud explícita), pueden basarse en el tiempo, como el tiempo de la CPU (en contraposición a las solicitudes independientes del tiempo, como los recursos compartidos de la CPU), etc.

Generalmente, la administración de recursos basada en el planificador se aplica a los recursos que puede solicitar la aplicación de forma implícita. Por ejemplo, para continuar la ejecución, una aplicación solicita de forma implícita tiempo de CPU adicional. Para grabar datos en un socket de red, una aplicación solicita ancho de banda implícitamente. Pueden colocarse limitaciones en el uso total de un recurso solicitado de forma implícita.

Pueden presentarse interfaces adicionales para que los niveles de servicio de CPU o el ancho de banda se negocien de forma explícita. Los recursos que se solicitan de forma explícita, como una solicitud de subproceso adicional, se pueden administrar por limitación.

Mecanismos de control de administración de recursos

Los tres tipos de mecanismos de control disponibles en el sistema operativo Solaris son las limitaciones, la planificación y las particiones.

Mecanismos de limitación

Las limitaciones permiten al administrador o al desarrollador de aplicaciones definir los límites de consumo de recursos específicos para una carga de trabajo. Con unos límites establecidos, el consumo de recursos de modelación pasa a ser un proceso más sencillo. Asimismo, pueden utilizarse los límites para controlar las aplicaciones cuyo comportamiento incorrecto podría afectar al rendimiento o la disponibilidad del sistema a través de solicitudes de recursos no reguladas.

Las limitaciones suponen complicaciones para la aplicación. La relación entre la aplicación y el sistema puede modificarse hasta que la aplicación deje de funcionar. Para atenuar este riesgo, puede reducir gradualmente las limitaciones en las aplicaciones cuyos recursos tienen un comportamiento desconocido. La función de controles de recursos que se describe en el Capítulo 6Controles de recursos (descripción general) ofrece un mecanismo de limitación. Las aplicaciones más nuevas pueden programarse para que tengan en cuenta sus limitaciones de recursos, pero no todos los programadores deciden hacerlo.

Mecanismos de planificación

La planificación hace referencia a la toma de una serie de decisiones de asignación a intervalos específicos. La decisión que se toma se basa en un algoritmo predecible. Una aplicación que no necesita su asignación actual deja el recurso disponible para el uso de otra aplicación. La administración de recursos basada en la planificación permite el uso completo de una configuración no asignada, a la vez que proporciona asignaciones controladas en una situación de asignaciones excesivas. El algoritmo subyacente define el modo en que se interpreta el término "controlado". En algunas instancias, es posible que el algoritmo de planificación, garantice que todas las aplicaciones tengan algún tipo de acceso al recurso. El planificador de reparto justo (FSS) descrito en el Capítulo 8Programador de reparto justo (descripción general) administra el acceso de la aplicación a los recursos de la CPU de un modo controlado.

Mecanismos de partición

La partición se utiliza para vincular una carga de trabajo con un subconjunto de los recursos disponibles del sistema. Este vínculo garantiza que siempre haya disponible una cantidad determinada de recursos para la carga de trabajo. Las funciones de agrupaciones de recursos que se describen en el Capítulo 12Agrupaciones de recursos (descripción general) permiten limitar las cargas de trabajo de subconjuntos específicos del equipo.

En las configuraciones que utilizan la partición se puede evitar la asignación excesiva en el sistema. Sin embargo, al evitar esta asignación excesiva, la capacidad de obtener usos elevados puede verse reducida. Un grupo reservado de recursos, como procesadores, no está disponible para ser utilizado por otra carga de trabajo cuando la carga vinculada a ellos está inactiva.

Configuración de la administración de recursos

Partes de la configuración de administración de recursos puede colocarse en un servicio de nombres de la red. Esta función permite al administrador aplicar limitaciones de administración de recursos a un grupo de equipos, en lugar de basarse en los equipos individuales. Los trabajos relacionados pueden compartir un identificador común, y el uso adicional de dichos trabajos se puede tabular desde los datos de cuentas.

La configuración de administración de recursos y los identificadores orientados a la carga de trabajo se describen con mayor detalle en el Capítulo 2Proyectos y tareas (información general). La función de contabilidad ampliada que vincula estos identificadores con el uso del recurso de la aplicación se describe en el Capítulo 4Contabilidad ampliada (descripción general).

Interacción con Zonas de Solaris

Las funciones de administración de recursos pueden utilizarse con Zonas de Solaris para detallar más el entorno de aplicación. Las interacciones entre estas funciones y las zonas se describen en las secciones aplicables de esta guía.

Cuándo utilizar la administración de recursos

Utilice la administración de recursos para asegurarse de que las aplicaciones cumplan los tiempos de respuesta requeridos.

La administración de recursos también puede aumentar el uso de los recursos. Al categorizar y priorizar el uso, puede utilizar de forma eficaz la capacidad de reserva durante los períodos no pico, lo que a menudo acaba con la necesidad de potencia de procesamiento adicional. También puede asegurarse de que los recursos no se malgasten debido a la variabilidad de la carga.

Consolidación de servidores

La administración de recursos es ideal para los entornos que consolidan una serie de aplicaciones en un único servidor.

El coste y la complejidad de administrar varios equipos fomenta la consolidación de varias aplicaciones en servidores más grandes y más escalables. En lugar de ejecutar cada carga de trabajo en un sistema distinto, con acceso completo a los recursos de dicho sistema, puede utilizar el software de administración de recursos para segregar las cargas de trabajo en el sistema. La administración de recursos permite reducir el coste total de propiedad al ejecutar y controlar varias aplicaciones en un único sistema Solaris.

Si proporciona servicios de aplicaciones e Internet, puede utilizar la administración de recursos para:

• Alojar varios servidores Web en un único equipo. Puede controlar el consumo de recursos para cada sitio web y proteger cada sitio de los posibles excesos de otros sitios.

• Evitar que una secuencia de interfaz Common Gateway Interface (CGI) agote los recursos de la CPU.

• Detener una aplicación cuyo comportamiento sea anómalo para que no afecte a la memoria virtual disponible.

• Asegurarse de que las aplicaciones de un cliente no se vean afectadas por las aplicaciones de otro cliente que se ejecutan en el mismo sitio.

• Proporcionar clases o niveles de servicios diferenciados en el mismo equipo.

• Obtener información de cuentas para fines de facturación.

Bases de usuarios diversas y de gran tamaño

Utilice las funciones de administración de recursos de cualquier sistema que tenga una base de usuarios diversa y de gran tamaño, como una institución educativa. Si tiene una combinación de cargas de trabajo, el software se puede configurar para otorgar prioridad a determinados proyectos.

Por ejemplo, en grandes agencias de corredores, los agentes necesitan acceso de forma intermitente y rápida para ejecutar una consulta o realizar un cálculo. En cambio, otros usuarios del sistema tienen cargas de trabajo más coherentes. Si asigna una cantidad proporcionalmente mayor de potencia de procesamiento a los proyectos de los agentes, éstos obtendrán la respuesta que necesitan.

La administración de recursos también resulta ideal para los sistemas e clientes sencillos. Estas plataformas proporcionan consolas sin estado con búferes de trama y dispositivos de entrada, como tarjetas inteligentes. Los cálculos reales se llevan a cabo en un servidor compartido, lo que tiene como resultado un tipo de entorno en el que se comparte el tiempo. Utilice las funciones de administración de recursos para aislar los a usuarios del servidor. Un usuario que genere una carga excesiva no monopolizará los recursos de hardware ni afectará a los demás usuarios del sistema.

Configuración de la administración de recursos (mapa de tareas)

El siguiente mapa de tareas proporciona información general de alto nivel sobre los pasos para configurar la administración de recursos del sistema.

Capítulo 2 Proyectos y tareas (información general)

En este capítulo se describen las funciones de proyectos y tareas de la administración de recursos de Solaris. Los proyectos y tareas se utilizan para etiquetar cargas de trabajo y separarlas entre sí.

En este capítulo, se describen los siguientes temas:

• Funciones de proyectos y tareas

• Identificadores de proyecto

• Identificadores de tareas

• Comandos utilizados con proyectos y tareas

Para utilizar las funciones de proyectos y tareas, consulte el Capítulo 3Administración de proyectos y tareas.

Novedades de los comandos de control de recursos y bases de datos del proyecto para Solaris 10

En Solaris 10 se incorporan las mejoras siguientes:

• Valor escalado y compatibilidad con el modificador de unidades para los comandos y los valores de control de recursos.

• Validación mejorada y facilitación de la gestión del campo de atributos del proyecto

• Formato de salida revisado y nuevas opciones para los comandos prctl y projects

• Posibilidad de definir el proyecto predeterminado del usuario a través del comando useradd y modificar la información utilizando los comandos usermod y passmgmt

Además de la información que contiene este capítulo y el Capítulo 6Controles de recursos (descripción general), consulte las siguientes páginas de comando man:

• passmgmt(1M)

• projadd(1M)

• projmod(1M)

• useradd(1M)

• usermod(1M)

• resource_controls(5)

En Solaris 10 5/08, las mejoras incluyen la adición de una opción -A en el comando projmod. Consulte Comandos utilizados con proyectos y tareas.

Para ver una lista completa de las nuevas funciones de Solaris 10 y una descripción de las versiones de Solaris, consulte Novedades de Oracle Solaris 10 9/10.

Funciones de proyectos y tareas

Para optimizar la respuesta de la carga de trabajo, primero debe ser capaz de identificar las cargas de trabajo que se ejecutan en el sistema que está analizando. Esta información puede ser difícil de obtener utilizando un método orientado únicamente a procesos o usuarios. En el sistema Solaris, pueden utilizarse dos funciones adicionales para separar e identificar las cargas de trabajo: el proyecto y la tarea. El proyecto proporciona un identificador administrativo de red para el trabajo relacionado. La tarea recopila un grupo de procesos en una entidad con posibilidades de administración que representa un componente de la carga de trabajo.

Los controles especificados en la base de datos del servicio de nombres de project se configuran en el proceso, la tarea y el proyecto. Dado que los controles del proceso y la tarea se heredan de las llamadas del sistema fork y settaskid, todos los procesos y tareas que se crean en el proyecto heredan dichos controles. Para obtener información sobre estas llamadas del sistema, consulte las páginas de comando man fork(2) y settaskid(2).

Basándose en su pertenencia a un proyecto o tarea, los procesos en ejecución se pueden manipular con los comando estándar de Solaris. La función de contabilidad ampliada puede informar del uso de procesos y tareas, y etiquetar cada registro con el identificador del proyecto en cuestión. Este proceso permite correlacionar el análisis de carga de trabajo fuera de línea con la supervisión en línea. El identificador de proyecto puede compartirse en varios equipos mediante la base de datos de servicio de nombres de project. De este modo, el consumo de recursos de las cargas de trabajo relacionadas que se ejecutan o abarcan varios equipos se puede analizar en última instancia en todos los equipos.

Identificadores de proyecto

El identificador de proyecto es un identificador alternativo que se utiliza para identificar el trabajo relacionado. El identificador de proyecto se puede considerar una etiqueta de carga de trabajo equivalente a los identificadores de usuario y grupo. Un usuario o grupo puede pertenecer a un proyecto o más. Estos proyectos pueden utilizarse para representar las cargas de trabajo en las que el usuario (o el grupo de usuarios) tiene permiso para participar. Esta pertenencia al grupo puede constituir la base del contracargo que se basa, por ejemplo, en el uso o las asignaciones de recursos iniciales. Aunque debe asignarse un usuario a un proyecto predeterminado, el proceso que inicia el usuario se puede asociar con cualquier proyecto del que es miembro el usuario.

Determinación de un proyecto predeterminado del usuario

Para iniciar sesión en el sistema, un usuario debe tener asignado un proyecto predeterminado. Un usuario es automáticamente miembro del proyecto predeterminado, aunque no se encuentre en la lista de usuarios o grupos del proyecto.

Dado que cada proceso del sistema procesa la pertenencia a un grupo del proyecto, se necesita un algoritmo para asignar un proyecto predeterminado al proceso de conexión u otro proceso inicial. El algoritmo se documenta en la página del comando man getprojent(3C). El sistema sigue una serie de pasos para determinar el proyecto predeterminado. Si no se encuentra ningún proyecto predeterminado, se deniega la conexión del usuario o su solicitud para iniciar un proceso.

El sistema sigue estos pasos de forma secuencial para determinar un proyecto predeterminado del usuario:

1. Si el usuario tiene una entrada con un atributo project definido en la base de datos de atributos de usuario extendida /etc/user_attr, el valor del atributo project es el proyecto predeterminado. Consulte la página del comando man user_attr(4).

2. Si hay un proyecto con el nombre user.ID_usuario en la base de datos project, dicho proyecto es el predeterminado. Consulte la página del comando man project(4) para obtener más información.

3. Si hay un proyecto con el nombre group.nombre_grupo en la base de datos project, en el que nombre_grupo es el nombre del grupo predeterminado para el usuario, tal como se especifica en el archivo passwd, dicho proyecto es el predeterminado. Para obtener información sobre el archivo passwd, consulte la página del comando man passwd(4).

4. Si el proyecto especial default está presente en la base de datos project, dicho proyecto es el predeterminado.

Esta lógica la proporciona la función de biblioteca getdefaultproj. () Consulte la página del comando man getprojent(3PROJECT) para obtener más información.

Definición de atributos de usuario con los comandos useradd, usermod y passmgmt

Puede utilizar los siguientes comandos con la opción -K y un par clave=valor para definir los atributos de usuario en los archivos locales:

passmgmt

Modificar información del usuario

useradd

Definir proyecto predeterminado para el usuario

usermod

Modificar información del usuario

Los archivos locales pueden incluir:

• /etc/group

• /etc/passwd

• /etc/project

• /etc/shadow

• /etc/user_attr

Si se utiliza un servicio de nombres de red como NIS para complementar el archivo local con entradas adicionales, estos comandos no pueden cambiar la información proporcionada por el servicio de nombres de red. Sin embargo, los comandos comprueban lo siguiente en la base de datos de servicio de nombres externa:

• Exclusividad del nombre de usuario (o su función)

• Exclusividad del ID de usuario

• Existencia de cualquier nombre de grupo especificado

Para obtener más información, consulte las páginas de comando man passmgmt(1M), useradd(1M), usermod(1M), y user_attr(4).

Base de datos project

Puede almacenar los datos de proyecto en un archivo local, en el mapa de proyecto del Servicio de información de la red (NIS) o en un servicio de directorio de protocolo ligero de acceso a directorios (LDAP). El archivo /etc/project o el servicio de nombres lo utilizan durante la conexión todas las solicitudes de administración de cuentas del módulo de autenticación enchufable (PAM) para vincular un usuario a un proyecto predeterminado.

Las actualizaciones de las entradas de la base de datos del proyecto, tanto si son para el archivo /etc/project como para una representación de la base de datos en un servicio de nombres de red, no se aplican a los proyectos activos. Las actualizaciones se aplican a las nuevas tareas que se unen al proyecto cuando se utilizan los comandos login o newtask. Para obtener más información, consulte las páginas de comando man login(1) y newtask(1).

Subsistema PAM

Las operaciones que cambian o definen identidades incluyen el registro en el sistema, la invocación de un comando rcp o rsh, utilizando ftp o su. Cuando una operación implica cambiar o definir una identidad, se utiliza un conjunto de módulos configurables para proporcionar autenticación y administración de cuentas, credenciales y sesiones.

El módulo PAM de administración de cuentas para los proyectos se documenta en la página del comando man pam_projects(5) Para ver una descripción general de PAM, consulte el Capítulo 17, Using PAM de System Administration Guide: Security Services.

Configuración de servicios de nombres

La administración de recursos admite las bases de datos project del servicio de nombres. La ubicación donde se almacena la base de datos project se define en el archivo /etc/nsswitch.conf. De modo predeterminado, files aparece en primer lugar, pero los orígenes pueden enumerarse en cualquier orden.

project: files [nis] [ldap]

Si se enumera más de un origen para la información del proyecto, el archivo nsswitch.conf dirige la rutina para empezar a buscar la información en el primer origen enumerado y luego buscar los orígenes subsiguientes.

Para obtener más información sobre el archivo /etc/nsswitch.conf, consulte el Capítulo 2, The Name Service Switch (Overview) de System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) y nsswitch.conf(4).

Formato de archivo /etc/project local

Si selecciona files como origen de la base de datos project en el archivo nsswitch.conf, el proceso de inicio de sesión busca el archivo /etc/project para obtener información del proyecto. Consulte las páginas del comando man projects(1) y project(4) para obtener información adicional.

El archivo project contiene una entrada de una línea con el siguiente formato para cada proyecto reconocido por el sistema:

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

Los campos se definen del modo siguiente:

nombre_proyecto

Nombre del proyecto. El nombre debe ser una cadena que esté compuesta por caracteres alfanuméricos, guiones bajos (_), guiones (-) y puntos (.). El punto, que queda reservado para los proyectos que tengan un significado especial para el sistema operativo, sólo se puede utilizar en los nombres de proyectos predeterminados para usuarios. projname no puede contener dos puntos (: ) o caracteres de línea nueva.

ID_proyecto

El ID numérico exclusivo del proyecto (PROJID) en el sistema. El valor máximo del campo projid es UID_MAX (2147483647).

comentario

Descripción del proyecto.

lista_usuario

Lista separada por comas de los usuarios que se permiten en el proyecto.

En este campo pueden utilizarse comodines. El símbolo de asterisco (*) permite a los usuarios unirse al proyecto. Un signo de exclamación de cierre seguido de un asterisco (!*) excluye del proyecto a todos los usuarios. Un signo de exclamación (!) seguido de un nombre de usuario excluye del proyecto al usuario especificado.

lista_grupos

Lista separada por comas de los grupos de usuarios que se permiten en el proyecto.

En este campo pueden utilizarse comodines. El símbolo de asterisco (*) permite a todos los grupos unirse al proyecto. Un signo de exclamación de cierre seguido de un asterisco (!*) excluye del proyecto a todos los grupos. Un signo de exclamación (!) seguido de un nombre de grupo excluye del proyecto al grupo especificado.

atributos

Una lista de pares de nombre-valor separados por puntos y coma, como los controles de recursos (consulte el Capítulo 6Controles de recursos (descripción general)). nombre es una cadena arbitraria que especifica el atributo relacionado con el objeto y valor es el valor opcional de dicho atributo.

name[=value]

En el par de nombre-valor, los nombres se restringen a letras, dígitos, subrayados y puntos. Un punto suele utilizarse como separador entre las categorías y subcategorías del control de recursos (rctl). El primer carácter de un nombre de atributo debe ser una letra. El nombre distingue entre mayúsculas y minúsculas.

Los valores pueden estructurarse utilizando comas y paréntesis para establecer el orden de precedencia.

El símbolo de punto y coma se utiliza para separar pares de nombre-valor. No se puede utilizar un punto y coma en una definición de valor. El símbolo de dos puntos se utiliza para separar campos de proyecto. No se puede utilizar el símbolo de dos puntos en una definición de valor.

Las rutinas que leen este archivo se detienen si detectan una entrada mal creada. Cualquier proyecto que se especifique después de la entrada incorrecta no podrá asignarse.

Este ejemplo muestra el archivo /etc/project predeterminado:

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

Este ejemplo muestra el archivo /etc/project predeterminado con entradas de proyecto añadidas al final:

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::

También puede añadir controles de recursos y atributos al archivo /etc/project:

• Para agregar controles de recursos para un proyecto, consulte Configuración de controles de recursos.

• Para definir un límite de recursos de memoria física para un proyecto mediante el daemon de límite de recursos que se describe en rcapd(1M), consulte Atributo para limitar el uso de memoria física para proyectos.

• Para añadir un atributo project.pool a la entrada de un proyecto, consulte Creación de la configuración.

Configuración del proyecto para NIS

Si utiliza NIS, puede especificar en el archivo /etc/nsswitch.conf la búsqueda de las asignaciones de proyecto NIS para los proyectos:

project: nis files 

Las asignaciones NIS, tanto project.byname como project.bynumber, tienen la misma forma que el archivo /etc/project:

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

Para más información, consulte el Capítulo 4, Network Information Service (NIS) (Overview) de System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Configuración del proyecto para LDAP

Si utiliza LDAP, puede especificar en el archivo /etc/nsswitch.conf la búsqueda de bases de datos LDAP project para los proyectos:

project: ldap files

Para obtener más información acerca de LDAP, consulte el Capítulo 8, Introduction to LDAP Naming Services (Overview/Reference) de System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP). Para obtener más información sobre el esquema para las entradas de proyecto en una base de datos LDAP, consulte Solaris Schemas de System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Identificadores de tareas

Cada inicio de sesión correcto en un proyecto crea una nueva tarea que contiene el proceso de inicio de sesión. La tarea es un proceso colectivo que representa un conjunto de trabajos en el tiempo. Una tarea también puede visualizarse como componente de carga de trabajo. A cada tarea se asigna automáticamente un ID.

Cada proceso es miembro de una tarea, y cada tarea se asocia con un proyecto.

Figura 2–1 Árbol de proyectos y tareas

Todas las operaciones de los grupos de procesos, como la entrega de señales, también se admiten para las tareas. Asimismo, puede vincular una tarea a un conjunto de procesadores y definir una prioridad de planificación y una clase para una tarea, lo que modifica todos los procesos actuales y subsiguientes de la tarea.

Se crea una tarea siempre que se incorpora un proyecto. Los siguientes comandos, acciones y funciones crean tareas:

• inicio de sesión

• cron

• newtask

• setproject

• su

Puede crear una tarea finalizada siguiendo uno de estos métodos. Cualquier intento adicional de crear tareas fallará.

• Puede utilizar el comando newtask con la opción - F.

• Puede definir el atributo task.final en un proyecto en la base de datos del servicio de nombres project. Todas las tareas creadas en dicho proyecto por setproject tienen la etiqueta TASK_FINAL.

Para más información, consulte las páginas del comando man login(1), newtask(1), cron(1M), su(1M) y setproject(3PROJECT).

La función de contabilidad ampliada puede proporcionar datos de cuentas para los procesos. Los datos se añaden en el nivel de la tarea.

Comandos utilizados con proyectos y tareas

Los comandos que se incluyen en la tabla siguiente proporcionan la interfaz administrativa principal para las funciones de proyectos y tareas.

Capítulo 3 Administración de proyectos y tareas

En este capítulo se describe cómo utilizar las funciones de proyectos y tareas de la administración de recursos de Solaris.

Se tratan los temas siguientes.

• Ejemplos y opciones de comandos

• Administración de proyectos

Para obtener una descripción general de las funciones de proyectos y tareas, consulte el Capítulo 2Proyectos y tareas (información general).

Si utiliza estas funciones en un sistema Solaris con zonas instaladas, sólo los procesos de la misma zona estarán visibles en las interfaces de llamada del sistema que obtengan ID de proceso cuando se ejecuten estos comandos en una zona no global.

Administración de proyectos y tareas (mapa de tareas)

Ejemplos y opciones de comandos

En esta sección se incluyen ejemplos de comandos y opciones que se utilizan con proyectos y tareas.

Opciones de comandos utilizadas con proyectos y tareas

Comando ps

Utilice el comando ps con la opción -o para ver los ID de proyectos y tareas. Por ejemplo, para ver el ID de proyecto, escriba:

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

Comando id

Utilice el comando id con la opción -p para imprimir el ID de proyecto actual además de los ID de grupo y usuario. Si se proporciona el operando user, se imprime el proyecto asociado con el inicio de sesión normal del usuario:

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

Comandos pgrep y pkill

Para hacer coincidir sólo los procesos con un ID de proyecto en una lista específica, utilice los comandos pgrep y pkill con la opción -J:

# pgrep -J projidlist
# pkill -J projidlist

Para hacer coincidir sólo los procesos con un ID de tarea en una lista específica, utilice los comandos pgrep y pkill con la opción -T:

# pgrep -T taskidlist
# pkill -T taskidlist

Comando prstat

Para mostrar varias estadísticas para procesos y proyectos que se ejecutan en el sistema, utilice el comando prstat con la opción -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 mostrar varias estadísticas para procesos y tareas que se ejecutan en el sistema, utilice el comando prstat con la opción -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	

Las opciones -J y -T no se pueden utilizar de forma simultánea.

Uso de cron y su con proyectos y tareas

Comando cron

El comando cron emite settaskid para asegurarse de que cada tarea cron, at y batch se ejecute en una tarea distinta, con el proyecto predeterminado adecuado para el usuario que realiza el envío. Los comandos at y batch también capturan el ID de proyecto actual, lo que garantiza que el ID de proyecto se restablezca al ejecutar una tarea at.

Comando su

El comando su se une al proyecto predeterminado del usuario de destino al crear una tarea nueva, como parte de la simulación de un inicio de sesión.

Para alternar el proyecto predeterminado del usuario con el comando su, escriba:

# su user

Administración de proyectos

Cómo definir un proyecto y ver el proyecto actual

En este ejemplo se describe cómo utilizar el comando projadd para añadir una entrada de proyecto y el comando projmod para modificar dicha entrada.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Visualice el archivo /etc/project predeterminado en el sistema utilizando 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. Añada un proyecto con el nombre booksite. Asigne el proyecto a un usuario con el nombre mark con el número de ID de proyecto 4113.

   # projadd -U mark -p 4113 booksite

4. Vuelva a visualizar el archivo /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. Añada un comentario que describa el proyecto en el campo de comentarios.

   # projmod -c `Book Auction Project' booksite

6. Visualice los cambios en el archivo /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:

Véase también

Para vincular proyectos, tareas y procesos con una agrupación, consulte Configuración de atributos de agrupaciones y vinculación a una agrupación.

Cómo eliminar un proyecto del archivo /etc/project

En este ejemplo se muestra cómo utilizar el comando projdel para eliminar un proyecto.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Elimine el proyecto booksite utilizando el comando projdel.

   # projdel booksite

3. Visualice el archivo /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. Inicie sesión como usuario mark y escriba projects para ver los proyectos asignados al usuario.

   # su - mark # projects default

Cómo validar el contenido del archivo /etc/project

Si no se facilitan opciones de edición, el comando projmod valida el contenido del archivo project.

Para validar una asignación NIS, como superusuario, escriba:

# ypcat project | projmod -f —

El comando ypcat project | projmod -f — no se ha implementado todavía.

Para comprobar la sintaxis del archivo /etc/project, escriba:

# projmod -n

Cómo obtener información sobre la pertenencia de un proyecto a un grupo

Utilice el comando id con la etiqueta -p para mostrar la pertenencia del proyecto actual a un grupo del proceso que ejecuta el comando.

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

Cómo crear una tarea

1. Inicie sesión como miembro del proyecto de destino, booksite.

2. Cree una tarea en el proyecto booksite utilizando el comando newtask con la opción -v (detallado) para obtener el ID de tarea del sistema.

   machine% newtask -v -p booksite 16

   La ejecución de newtask crea una tarea en el proyecto especificado, y coloca el shell predeterminado del usuario en esta tarea.

3. Visualice la pertenencia del proyecto actual a un grupo del proceso que ejecuta el comando.

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

   El proceso ahora es miembro del nuevo proyecto.

Cómo mover un proceso en ejecución a una nueva tarea

Este ejemplo muestra cómo asociar un proceso en ejecución con una tarea diferente y un proyecto nuevo. Para ejecutar esta acción, debe ser un superusuario o el propietario del proceso y miembro del proyecto nuevo.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

   ---

   Nota –

   Si es el propietario del proceso o un miembro del proyecto nuevo, puede omitir este paso.

   ---

2. Obtenga el ID de proceso de catálogo_guías.

   # pgrep book_catalog 8100

3. Asocie el proceso 8100 con un nuevo ID de tarea en el proyecto booksite.

   # newtask -v -p booksite -c 8100 17

   La opción -c especifica que newtask opera en el proceso con nombre existente.

4. Confirme la tarea para procesar la asignación de ID.

   # pgrep -T 17 8100

Edición y validación de atributos de proyecto

Puede utilizar los comandos de administración de bases de datos de proyecto projadd y projmod para editar los atributos del proyecto.

La opción -K especifica una lista de sustitución de los atributos. Los atributos se delimitan con puntos y coma (;). Si se utiliza la opción -K con la opción -a, se añade el atributo o el valor de atributo. Si se utiliza la opción -K con la opción -r, se elimina el atributo o el valor de atributo. Si se utiliza la opción -K con la opción - s, se sustituye el atributo o el valor de atributo.

Cómo añadir atributos y valores de atributos a los proyectos

Utilice el comando projmod con las opciones -a y - K para añadir valores a un atributo de proyecto. Si el atributo no existe, se crea.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Añada el atributo de control de recursos task.max-lwps sin valores en el proyecto myproject. Una tarea que se introduce en el proyecto sólo tiene el valor de sistema para el atributo.

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

3. A continuación, puede añadir un valor para task.max-lwps en el proyecto myproject. El valor se compone de un nivel de privilegio, un valor umbral y una acción asociada con el umbral.

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

4. Dado que los controles de recursos pueden tener varios valores, puede añadir otro valor a la lista utilizando las mismas opciones.

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

   Los valores múltiples se separan con comas. La entrada task.max-lwps ahora es:

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

Cómo eliminar valores de atributo de los proyectos

Este procedimiento da por sentados los valores:

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

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Para eliminar un valor de atributo del control de recursos task.max-lwps en el proyecto myproject, utilice el comando projmod con las opciones -r y -K.

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

   Si task.max-lwps tiene múltiples valores, como:

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

   se eliminará el primer valor coincidente. El resultado sería:

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

Cómo eliminar un atributo de control de recursos de un proyecto

Para eliminar el control de recursos task.max-lwps del proyecto myproject, utilice el comando projmod con las opciones - r y -K.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Elimine el atributo task.max-lwps y todos sus valores del proyecto myproject:

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

Cómo sustituir atributos y valores de atributos para los proyectos

Para sustituir un valor diferente para el atributo task.max-lwps en el proyecto myproject, utilice el comando projmod con las opciones -s y -K. Si el atributo no existe, se crea.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Sustituya los valores task.max-lwps actuales con los nuevos valores:

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

   El resultado sería:

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

Cómo eliminar los valores existentes para un atributo de control de recursos

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Para eliminar los valores actuales para task.max-lwps del proyecto myproject, escriba:

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

Capítulo 4 Contabilidad ampliada (descripción general)

Al utilizar las funciones de proyectos y tareas que se describen en el Capítulo 2Proyectos y tareas (información general) para etiquetar y separar cargas de trabajo, puede supervisar el consumo de recursos por cada carga de trabajo. Puede utilizar el subsistema de contabilidad ampliada para capturar un conjunto detallado de estadísticas de consumo de recursos en los proyectos y tareas.

En este capítulo se cubren los temas siguientes.

• Introducción a la contabilidad ampliada

• Funcionamiento de la contabilidad ampliada

• Configuración de contabilidad ampliada

• Comandos utilizados con contabilidad ampliada

• Interfaz Perl para libexacct

Para empezar a utilizar la contabilidad ampliada, pase a Cómo activar la contabilidad ampliada para procesos, tareas y flujos.

Novedades en la contabilidad ampliada de Solaris 10

Ahora se pueden generar los datos de mstate para las cuentas del proceso. Consulte Cómo ver los recursos de cuentas disponibles.

Para ver una lista completa de las nuevas funciones de Solaris 10 y una descripción de las versiones de Solaris, consulte Novedades de Oracle Solaris 10 9/10.

Introducción a la contabilidad ampliada

El subsistema de contabilidad ampliada etiqueta los registros de uso con el proyecto para el que se ha realizado el trabajo. También puede utilizar la contabilidad ampliada, junto con el módulo de cuentas de flujo de Internet Protocol Quality of Service (IP QoS) descrito en el Capítulo 36, Uso de control de flujo y recopilación de estadísticas (Tareas) de Guía de administración del sistema: servicios IP, con el fin de capturar la información de flujo de red en un sistema.

Antes de aplicar los mecanismos de administración de recursos, debe caracterizar las demandas de consumo de recursos de las distintas cargas de trabajo en un sistema. La función de contabilidad ampliada del sistema operativo Solaris proporciona un método flexible para registrar el consumo de recursos de red y del sistema por tarea o proceso, o por los selectores que proporciona el módulo flowacct de IPQoS. Para obtener más información, consulte ipqos(7IPP).

A diferencia de otras herramientas de supervisión en línea, que permiten medir el uso del sistema en tiempo real, la contabilidad ampliada permite examinar el uso histórico. Puede realizar evaluaciones de los requisitos de capacidades para las futuras cargas de trabajo.

Gracias a los datos de contabilidad ampliada, puede desarrollar o adquirir software para el contracargo de recursos, la supervisión de la carga de trabajo o la planificación de las capacidades.

Funcionamiento de la contabilidad ampliada

La función de contabilidad ampliada del sistema operativo Solaris utiliza un formato de archivo ampliable con versión que contiene los datos de contabilidad. Se puede acceder a los archivos que utilizan este formato de datos o éstos se pueden crear utilizando la API que se proporciona con la biblioteca incluida, libexacct (consulte libexacct(3LIB)). Estos archivos pueden analizarse en cualquier plataforma con la función de contabilidad ampliada activada, y sus datos se pueden utilizar para el contracargo y la planificación de capacidades.

Si la función de contabilidad ampliada está activa, se recopilan estadísticas que pueden examinarse con la API libexacct. libexacct permite examinar los archivos exacct hacia delante o hacia atrás. La API admite archivos de terceros que genera libexacct, así como los archivos que crea el núcleo. Hay una interfaz de Lenguaje Práctico de Extracción e Informes (Practical Extraction and Report Language o Perl) para libexacct que permite desarrollar secuencias de extracción e informes personalizados. Consulte Interfaz Perl para libexacct.

Por ejemplo, con la contabilidad ampliada habilitada, la tarea supervisa el uso de los recursos adicionales de sus procesos miembro. Al finalizar la tarea se guarda un registro de cuentas de las tareas. También pueden guardarse registros provisionales sobre los procesos y tareas en ejecución. Para obtener más información sobre las tareas, consulte el Capítulo 2Proyectos y tareas (información general).

Figura 4–1 Supervisión de tareas con la contabilidad ampliada activada

Formato ampliable

El formato de contabilidad ampliada es sustancialmente más ampliable que el formato de software de cuentas del sistema heredado SunOS (consulte What is System Accounting? de System Administration Guide: Advanced Administration). La contabilidad ampliada permite añadir y eliminar métrica de cuentas en las distintas versiones del sistema, e incluso durante el funcionamiento del sistema.

La contabilidad ampliada y el software de contabilidad del sistema heredado pueden estar activos en el sistema de forma simultánea.

Registros y formato exacct

Las rutinas que permiten crear registros exacct tienen dos finalidades.

• Permitir la creación de archivos exacct de terceros.

• Permitir la creación de registros de etiquetas para integrarlos en el archivo de cuentas núcleo utilizando la llamada del sistema putacct (consulte getacct(2)).

  ---

  Nota –

  La llamada del sistema putacct también está disponible en la interfaz de Perl.

  ---

El formato permite capturar diferentes formas de registros de cuentas sin necesidad de que cada cambio sea un cambio de versión explícito. Las aplicaciones potentes que consumen datos de cuentas deben omitir los registros que no comprenden.

La biblioteca libexacct convierte y produce archivos en el formato exacct. Esta biblioteca es la única interfaz compatible con los archivos de formato exacct.

Las llamadas de sistema getacct, putacct y wracct no se aplican a los flujos. El núcleo crea registros de flujo y los guarda en el archivo cuando se configuran las cuentas de flujo IPQoS.

Uso de contabilidad ampliada en un sistema Solaris con Zonas de Solaris instalado

El subsistema de contabilidad ampliada recopila y registra la información para todo el sistema (incluidas las zonas no globales) cuando se ejecuta en la zona global. El administrador global también puede determinar el consumo de recursos por zonas. Consulte Contabilidad ampliada en un sistema Solaris con zonas instaladas para más información.

Configuración de contabilidad ampliada

El archivo /etc/acctadm.conf contiene la configuración de contabilidad ampliada actual. El archivo se edita mediante la interfaz acctadm, no lo edita el usuario.

El directorio /var/adm/exacct es la ubicación estándar para colocar datos de contabilidad ampliada. Puede utilizar el comando acctadm para especificar una ubicación distinta para los archivos de datos y cuentas de procesos y tareas. Consulte acctadm(1M) para obtener más información.

Comandos utilizados con contabilidad ampliada

Para obtener información sobre los comandos asociados con los proyectos y tareas, consulte Ejemplos y opciones de comandos. Para obtener información sobre las cuentas de flujos IPQoS, consulte ipqosconf(1M).

Interfaz Perl para libexacct

La interfaz Perl permite crear secuencias Perl que lean los archivos de cuentas producidos por la estructura exacct. También puede crear secuencias Perl que escriban archivos exacct.

La interfaz es funcionalmente equivalente a la API C subyacente. Cuando sea posible, los datos obtenidos de la API C subyacente se presentan como tipos de datos Perl. Esta función facilita el acceso a los datos y acaba con la necesidad de las operaciones de compresión y descompresión del búfer. Asimismo, todas las funciones de administración de la memoria las lleva a cabo la biblioteca Perl.

Las diferentes funciones relacionadas con proyectos, tareas y exacct se separan en grupos. Cada grupo de funciones se encuentra en un módulo Perl distinto. Cada módulo empieza por el prefijo de paquete Perl Sun::Solaris:: estándar. Todas las clases proporcionadas por la biblioteca Perl exacct se encuentran en el módulo Sun::Solaris::Exacct.

La biblioteca libexacct(3LIB) subyacente proporciona operaciones en los archivos de formato exacct, las etiquetas de catálogo y los objetos exacct. Los objetos exacct se subdividen en dos tipos:

• Elementos, que son valores de datos únicos (escalares)

• Grupos, que son listas de elementos

La tabla siguiente resume cada uno de los módulos.

Para ver ejemplos sobre cómo utilizar los módulos descritos en la tabla anterior, consulte Uso de la interfaz de Perl para libexacct.

Capítulo 5 Administración de contabilidad ampliada (tareas)

Este capítulo describe cómo administrar el subsistema de contabilidad ampliada.

Para ver una descripción general del subsistema de contabilidad ampliada, consulte el Capítulo 4Contabilidad ampliada (descripción general).

Administración de la función de contabilidad ampliada (mapa de tareas)

Uso de funciones de contabilidad ampliada

Los usuarios pueden administrar la contabilidad ampliada (iniciar contabilidad, detener contabilidad y cambiar parámetros de configuración de contabilidad) si tienen el perfil con los derechos pertinentes para el tipo de contabilidad ampliada que se debe administrar:

• Gestión de flujo

• Gestión de procesos

• Administración de tareas

Cómo activar la contabilidad ampliada para procesos, tareas y flujos

Para activar la función de contabilidad ampliada para procesos, tareas y flujos, utilice el comando acctadm. El parámetro final opcional para acctadm indica si el comando se aplica al proceso, a la tarea del sistema o a los componentes de cuentas de flujo de la función de contabilidad ampliada.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Active la contabilidad ampliada para los procesos.

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

3. Active la contabilidad ampliada para las tareas.

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

4. Active la contabilidad ampliada para los flujos.

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

Véase también

Consulte acctadm(1M) para obtener más información.

Como activar la contabilidad ampliada con una secuencia de inicio

Active la contabilidad ampliada de forma continuada vinculando la secuencia /etc/init.d/acctadm en /etc/rc2.d.

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

La variable n se sustituye con un número.

Debe activar manualmente la contabilidad ampliada al menos una vez para establecer la configuración.

Consulte Configuración de contabilidad ampliada para obtener información sobre la configuración de cuentas.

Cómo mostrar el estado de la contabilidad ampliada

Escriba acctadm sin argumentos para mostrar el estado actual de la función de contabilidad ampliada.

# 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

En el ejemplo anterior, la cuenta de tareas del sistema está activa en el modo extendido y el modo mstate. Las cuentas de proceso y flujo están activas en modo extendido.

En el contexto de la contabilidad ampliada, el microestado (mstate) hace referencia a los datos ampliados, asociados con las transiciones de procesos de microestado, disponibles en el archivo de uso del proceso (consulte proc(4)). Estos datos proporcionan más cantidad de detalles sobre las actividades del proceso que los registros básicos o extendidos.

Cómo ver los recursos de cuentas disponibles

Los recursos disponibles pueden variar según el sistema y la plataforma. Utilice el comando acctadm con la opción -r para ver los grupos de recursos de contabilidad disponibles en el 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

Cómo desactivar las cuentas de procesos, tareas y flujos

Para desactivar las cuentas de procesos, tareas y flujos, desactive cada una de ellas de forma individual utilizando el comando acctadm con la opción -x.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Desactive las cuentas de procesos.

   # acctadm -x process

3. Desactive las cuentas de tareas.

   # acctadm -x task

4. Desactive las cuentas de flujos.

   # acctadm -x flow

5. Compruebe que se hayan desactivado las cuentas de procesos, tareas y flujos.

   # 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 de la interfaz de Perl para libexacct

Cómo imprimir de forma recurrente el contenido de un objeto exacct

Utilice el código siguiente para imprimir de forma recurrente el contenido de un objeto exacct. Tenga en cuenta que esta función la proporciona la biblioteca como función de Sun::Solaris::Exacct::Object::dump(). Esta función también está disponible mediante la función de conveniencia 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);
             }
     }

Cómo crear un registro de grupo y guardarlo en un archivo

Utilice esta secuencia para crear un registro de grupos y guardarlo en un archivo denominado /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;

Cómo imprimir el contenido de un archivo exacct

Utilice la siguiente secuencia Perl para imprimir el contenido de un archivo 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);

Ejemplo de salida de Sun::Solaris::Exacct::Object->dump()

A continuación se incluye un ejemplo de salida al ejecutar Sun::Solaris::Exacct::Object->dump() en el archivo creado en Cómo crear un registro de grupo y guardarlo en un archivo.

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 (descripción general)

Una vez determinado el consumo de recursos de las cargas de trabajo del sistema tal como se describe en el Capítulo 4Contabilidad ampliada (descripción general), puede establecer límites para el uso de recursos. Los límites evitan que las cargas de trabajo consuman recursos en exceso. La función de controles de recursos es el mecanismo de limitación que se utiliza para tal fin.

En este capítulo se tratan los temas siguientes.

• Conceptos de controles de recursos

• Configuración de controles de recursos y atributos

• Aplicación de controles de recursos

• Actualización temporal de los valores de controles de recursos en un sistema en ejecución

• Comandos utilizados con controles de recursos

Para obtener información sobre cómo administrar los controles de recursos, consulte el Capítulo 7Administración de controles de recursos (tareas).

Novedades en los controles de recursos de Solaris 10

El siguiente conjunto de controles de recursos sustituye los valores configurables de la comunicación entre procesos (IPC) System 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

Se han añadido los siguientes controles de recursos del puerto de eventos:

• project.max-device-locked-memory

• project.max-port-ids

• process.max-port-events

Se ha añadido el siguiente control de recursos criptográfico:

• project.max-crypto-memory

Se han añadido los siguientes controles de recursos adicionales:

• project.max-lwps

• project.max-tasks

• project.max-contracts

Para más información, consulte Controles de recursos disponibles.

Para ver una lista completa de las nuevas funciones de Solaris 10 y una descripción de las versiones de Solaris, consulte Novedades de Oracle Solaris 10 9/10.

Conceptos de controles de recursos

En el sistema operativo Solaris, el concepto de límite de recurso por proceso se ha extendido a las entidades de tareas y proyectos descritas en el Capítulo 2Proyectos y tareas (información general). Estas mejoras se incorporan a través de la función de controles de recursos (rctls). Asimismo, las asignaciones que se configuraban mediante opciones de /etc/system ahora son automáticas o se configuran también mediante el mecanismo de controles de recursos.

Un control de recurso puede identificarse por el prefijo zone, project, task o process. Los controles de recursos pueden observarse en todo el sistema. Es posible actualizar los valores de controles de recursos en un sistema en ejecución.

Para ver una lista de los controles de recursos estándar disponibles en esta versión, consulte Controles de recursos disponibles. Consulte Propiedades del tipo de recurso para obtener información sobre los controles de recursos disponibles de la zona.

Para ver una lista de los controles de recursos estándar disponibles en esta versión, consulte Controles de recursos disponibles.

Límites y controles de recursos

Los sistemas UNIX proporcionan tradicionalmente una función de límite de recursos ( rlimit). La función rlimit permite a los administradores configurar uno o más límites numéricos para la cantidad de recursos que puede consumir un proceso. Estos límites incluyen el tiempo de CPU utilizado por proceso, el tamaño de archivo núcleo por proceso y el tamaño de pila máximo por proceso. El tamaño de pila es la cantidad de memoria de trabajo asignada para el segmento de datos del proceso.

La función de controles de recursos ofrece interfaces de compatibilidad para la función de límites de recursos. Las aplicaciones existentes que utilizan límites de recursos siguen ejecutándose sin cambios. Estas aplicaciones pueden observarse del mismo modo que las aplicaciones modificadas para aprovechar la función de controles de recursos.

Comunicación entre procesos y controles de recursos

Los procesos pueden comunicarse entre sí utilizando uno de los distintos tipos de comunicación entre procesos (IPC). IPC permite transferir o sincronizar información entre procesos. Antes de la versión Solaris 10, los parámetros IPC configurables se establecían añadiendo una entrada al archivo /etc/system. La función de controles de recursos ahora proporciona controles de recursos que definen el comportamiento de las funciones IPC del núcleo. Estos controles de recursos sustituyen las opciones configurables de /etc/system.

Es posible que los parámetros obsoletos estén incluidos en el archivo /etc/system de este sistema Solaris. Si es el caso, los parámetros se usan para iniciar los valores de control de recursos predeterminados, al igual que en las versiones anteriores de Solaris. Sin embargo, no se recomienda el uso de los parámetros obsoletos.

Para observar qué objetos IPC contribuyen al uso de un proyecto, utilice el comando ipcs con la opción -J. Consulte Cómo utilizar ipcs para ver un ejemplo. Para obtener más información acerca del comando ipcs, consulte ipcs(1).

Para obtener información sobre la configuración del sistema Solaris, consulte Oracle Solaris Tunable Parameters Reference Manual.

Mecanismos de limitación del control de recursos

Los controles de recursos ofrecen un mecanismo para la limitación de los recursos del sistema. Es posible evitar que los procesos, tareas, proyectos y zonas consuman determinadas cantidades de recursos del sistema. Este mecanismo conduce a un sistema más eficaz, puesto que evita el consumo excesivo de recursos.

Los mecanismos de limitación pueden utilizarse para complementar los procesos de planificación de capacidades. Una limitación puede proporcionar información sobre las necesidades de recursos de una aplicación sin denegar necesariamente el recurso a la aplicación.

Mecanismos de atributos de proyecto

Los controles de recursos también pueden servir de mecanismo de atributo simple para las funciones de administración de recursos. Por ejemplo, el número de recursos compartidos de CPU disponibles para un proyecto en la clase de planificación del programador de reparto justo (FSS) se define mediante el control de recurso project.cpu-shares. Dado que el control asigna al proyecto un número fijo de recursos compartidos, las diferentes acciones que excedan el control no son relevantes. En este contexto, el valor actual del control project.cpu-shares se considera un atributo del proyecto especificado.

Otro tipo de atributo de proyecto se utiliza para regular el consumo de recursos de la memoria física por parte de los grupos de procesos asociados a un proyecto. Estos atributos tienen el prefijo rcap, por ejemplo, rcap.max-rss. Al igual que los controles de recursos, este tipo de atributo se configura en la base de datos project. Sin embargo, mientras que los controles de recursos los aplica de forma sincronizada el núcleo, los límites de recursos los aplica el daemon de aplicación de límites de recursos, rcapd, en el nivel del usuario y sin sincronización. Para obtener información sobre rcapd, consulte el Capítulo 10Control de memoria física utilizando el daemon de límite de recursos (descripción general) y rcapd (1M).

El atributo project.pool se utiliza para especificar la vinculación de agrupaciones para un proyecto. Para obtener más información sobre las agrupaciones de recursos, consulte el Capítulo 12Agrupaciones de recursos (descripción general).

Configuración de controles de recursos y atributos

La función de controles de recursos se configura a través de la base de datos project. Consulte el Capítulo 2Proyectos y tareas (información general). Los controles de recursos y otros atributos se configuran en el campo final de la entrada de la base de datos project. Los valores asociados con cada control de recursos se incluyen entre paréntesis, y aparecen como texto sin formato separado por comas. Los valores entre paréntesis constituyen una "cláusula de acción". Cada cláusula de acción se compone de un nivel de privilegio, un valor umbral y una acción asociada con el umbral específico. Cada control de recurso puede tener varias cláusulas de acción, que también se separan con comas. La entrada siguiente define un límite de proceso ligero por tarea y un límite de tiempo de CPU máximo por proceso en una entidad de proyecto. process.max-cpu-time enviaría SIGTERM a un proceso durante la ejecución del proceso durante una hora, y SIGKILL si el proceso siguiera ejecutándose durante una hora y un minuto. Consulte la Tabla 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

En los sistemas con zonas activadas, los controles de recursos de la zona se especifican en la configuración de zona con un formato ligeramente diferente. Consulte Datos de configuración de zonas para obtener más información.

El comando rctladm permite realizar interrogaciones de tiempo de ejecución y modificaciones en la función de controles de recursos con ámbito global. El comando prctl permite realizar interrogaciones de tiempo de ejecución y modificaciones en la función de controles de recursos, con ámbito local.

Para obtener más información, consulte Acciones locales y globales en valores de controles de recursos, rctladm(1M) y prctl(1).

En un sistema con zonas instaladas, no puede utilizar rctladm en una zona no global para modificar la configuración. Puede utilizar rctladm en una zona no global para ver el estado de registro global de cada control de recurso.

Controles de recursos disponibles

En la tabla siguiente se incluye una lista de los controles de recursos estándar disponibles en esta versión.

La tabla describe el recurso que limita cada control. Asimismo, identifica las unidades predeterminadas que utiliza la base de datos project para dicho recurso. Las unidades predeterminadas pueden ser de dos tipos:

• Las cantidades representan una cantidad limitada.

• Los índices representan un identificador válido máximo.

De este modo, project.cpu-shares especifica el número de recursos compartidos a los que tiene derecho el proyecto. process.max-file-descriptor especifica el número máximo de archivos que se pueden asignar a un proceso mediante la llamada de sistema open(2).

Puede ver los valores predeterminados de los controles de recursos de un sistema que no tenga controles de recursos definidos ni cambiados. Dicho sistema no contiene entradas que no sean predeterminadas en /etc/system o la base de datos project. Para ver los valores, utilice el comando prctl.

Controles de recursos de la zona

Los controles de recursos de la zona limitan el uso total de los recursos de todas las entidades de procesos de una zona. Los controles de recursos de la zona también pueden configurarse utilizando los nombres de propiedades globales descritos en Configuración de controles de recursos de zonas y Cómo configurar la zona.

Para obtener información sobre la configuración de controles de recursos de la zona, consulte Propiedades del tipo de recurso y Cómo configurar la zona. Para utilizar los controles de recursos de la zona en las zonas con marca lx, consulte Cómo configurar, verificar y confirmar la zona con marca lx.

Tenga en cuenta que es posible aplicar un control de recurso de la zona para la zona global. Para obtener más información, consulte el Capítulo 17Configuración de zonas no globales (descripción general) y Uso del programador de reparto justo en un sistema Solaris con zonas instaladas.

Compatibilidad con unidades

Los indicadores globales que identifican los tipos de controles de recursos se definen para todos los controles de recursos. El sistema utiliza los indicadores para comunicar la información de tipo básico a las aplicaciones como el comando prctl. Las aplicaciones utilizan la información para determinar lo siguiente:

• Las cadenas de unidades apropiadas para cada control de recurso

• La escala correcta que utilizar al interpretar valores a escala

Hay disponibles los siguientes indicadores globales:

Pueden utilizarse valores a escala con los controles de recursos. El ejemplo siguiente muestra un valor umbral a escala:

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

Los comandos prctl, projadd y projmod aceptan modificadores de unidades. No puede utilizar modificadores de unidades en la base de datos project.

Valores de controles de recursos y niveles de privilegio

Un valor umbral en un control de recurso constituye un punto de aplicación en el que se pueden desencadenar acciones locales o globales, por ejemplo registros.

Cada valor umbral de un control de recurso debe asociarse con un nivel de privilegio. El nivel de privilegio debe ser de uno de estos tres tipos.

• Básico, que puede modificar el propietario del proceso que realiza la llamada

• Con privilegios, que sólo pueden modificar los autores de la llamada con privilegios (superusuarios)

• Sistema, que es fijo para la duración de la instancia del sistema operativo

Se garantiza que un control de recurso tiene un valor de sistema, definido por el sistema, o un proveedor de recursos. El valor del sistema representa qué cantidad del recurso es capaz de proporcionar la implementación actual del sistema operativo.

Puede definirse cualquier número de valores con privilegio, y sólo se permite un valor básico. A las operaciones que se llevan a cabo sin especificar un valor de privilegio se les asigna de forma predeterminada un privilegio básico.

El nivel de privilegio para un valor de control de recurso se define en el campo de privilegio del bloque de control de recurso como RCTL_BASIC, RCTL_PRIVILEGED o RCTL_SYSTEM. Consulte setrctl(2) para obtener más información. Puede utilizar el comando prctl para modificar los valores asociados con los niveles básico y con privilegios.

Acciones locales y globales en valores de controles de recursos

Hay dos categorías de acciones en los valores de controles de recursos: globales y locales.

Acciones globales en valores de controles de recursos

Las acciones globales se aplican a los valores de controles de recursos para cada control de recurso del sistema. Puede utilizar el comando rctladm que se describe en la página del comando man rctladm(1M) para llevar a cabo las acciones siguientes:

• Mostrar el estado global de los controles de recursos activos del sistema

• Definir acciones de registro globales

Puede desactivar o activar la acción de registro global en los controles de recursos. Es posible definir la acción syslog hasta un grado específico asignando un nivel de gravedad, syslog=nivel. Las posibles configuraciones de nivel son:

• debug

• info

• notice

• warning

• err

• crit

• alert

• emerg

De modo predeterminado, no hay ningún registro global de los conflictos de controles de recursos. En Solaris 10 5/08, se agregó el nivel n/a para controles de recursos en los que no se podían configurar acciones globales.

Acciones locales en valores de controles de recursos

Las acciones locales se llevan a cabo en un proceso que intenta exceder el valor de control. Para cada valor umbral que se coloca en un control de recurso, puede asociar una o más acciones. Hay tres tipos de acciones locales: none, deny y signal=. Estas tres acciones se utilizan del modo siguiente:

none

No se emprende ninguna acción en las solicitudes de recursos para una cantidad que supere el umbral. Esta acción resulta útil para supervisar el uso de los recursos sin que ello afecte al progreso de las aplicaciones. También puede activar un mensaje global que se muestre al superar el control de recurso, aunque el proceso que supera el umbral no se vea afectado.

deny

Puede denegar las solicitudes de recursos para una cantidad que supere el umbral. Por ejemplo, un control de recurso task.max-lwps con la acción deny hace que la llamada de sistema fork falle si el nuevo proceso supera el valor de control. Consulte la página del comando man fork(2).

signal=

Puede activar una acción de mensaje de señal global cuando se supera el control de recurso. Se envía una señal al proceso cuando se supera el valor umbral. No se envían señales adicionales si el proceso consume recursos adicionales. En la Tabla 6–3 se enumeran las señales disponibles.

No se pueden aplicar todas las acciones a cada control de recurso. Por ejemplo, un proceso no puede superar el número de recursos compartidos de CPU asignados al proyecto del cual es miembro. Por tanto, no se permite una acción de denegación en el control de recurso project.cpu-shares.

Debido a la restricción de la implementación, las propiedades globales de cada control pueden restringir el intervalo de acciones disponibles que se pueden configurar en el valor umbral. (Consulte la página del comando man rctladm(1M) En la tabla siguiente se presenta una lista de las acciones de señales disponibles. Para obtener información adicional sobre las señales, consulte la página del comando man signal(3HEAD).

Propiedades e indicadores de controles de recursos

Cada control de recurso del sistema tiene un grupo determinado de propiedades asociadas. Este conjunto de propiedades se define como un conjunto de indicadores, asociados con todas las instancias controladas de dicho recurso. Los indicadores globales no se pueden modificar, pero se pueden recuperar utilizando las llamadas de sistema rctladm o getrctl.

Los indicadores globales definen el comportamiento predeterminado y la configuración de un valor umbral específico de dicho control de recurso en un proceso específico o colectivo. Los indicadores locales de un valor umbral no afectan al comportamiento de otros valores umbral definidos para el mismo control de recurso. Sin embargo, los indicadores globales afectan al comportamiento de cada valor asociado con un control particular. Los indicadores locales pueden modificarse, dentro de los límites establecidos por sus indicadores globales correspondientes, mediante el comando prctl o la llamada de sistema setrctl. Consulte setrctl(2).

Para ver una lista completa de los indicadores locales y sus definiciones, consulte rctlblk_set_value(3C).

Para determinar el comportamiento del sistema cuando se alcanza un valor umbral para un control de recurso concreto, utilice rctladm para ver los indicadores globales para el control de recurso. Por ejemplo, para ver los valores de process.max-cpu-time, escriba lo siguiente:

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

Los indicadores globales significan lo siguiente.

lowerable

No se requieren privilegios de superusuario para reducir los valores con privilegios para este control.

no-deny

Nunca se deniega el acceso al recurso, ni siquiera cuando se superan los valores umbral.

cpu-time

SIGXCPU está disponible para su envío cuando se alcanzan los valores umbral de este recurso.

seconds

Valor de tiempo para el control de recurso.

no-basic

Los valores de control de recurso con el tipo de privilegio basic no se pueden establecer. Sólo se permiten valores de control de recurso con privilegios.

no-signal

Una acción de señal local no se puede establecer en valores de control de recurso.

no-syslog

La acción de mensaje syslog global no se puede establecer para este control de recurso.

deny

Siempre que se sobrepasen los valores de umbral, deniegue la solicitud de recursos.

count

Valor (entero) de cantidad para el control de recurso.

bytes

Unidad de tamaño de control de recurso.

Utilice el comando prctl para ver las acciones y los valores locales para el control de recurso.

$ 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 

El indicador max (RCTL_LOCAL_MAXIMAL) se configura para ambos valores umbral, y el indicador inf (RCTL_GLOBAL_INFINITE) se define para este control de recurso. Un valor inf tiene una cantidad infinita. El valor nunca se aplica. Por ello, ambas cantidades umbral representan valores infinitos que nunca se superan.

Aplicación de controles de recursos

Un recurso puede tener más de un control de recurso. Puede haber un control de recurso en cada nivel de contenido en el modelo de proceso. Si hay controles de recursos activos en el mismo recurso en diferentes niveles de contenido, se aplicará en primer lugar el control del contenedor más pequeño. De este modo, la acción se lleva a cabo en process.max-cpu-time antes que en task.max-cpu-time si ambos controles se encuentran de forma simultánea.

Figura 6–1 Procesos colectivos, relaciones de contenedores y sus conjuntos de controles de recursos

Supervisión global de los eventos de controles de recursos

A menudo, se desconoce el consumo de recursos de los procesos. Para obtener más información, utilice las acciones de control de recursos globales disponibles con el comando rctladm. Utilice rctladm para establecer una acción syslog en un control de recursos. A continuación, si una entidad administrada por dicho control de recurso se encuentra con un valor umbral, se registra un mensaje del sistema en el nivel de registro configurado. Si desea más información, consulte el Capítulo 7Administración de controles de recursos (tareas) y la página del comando man rctladm(1M).

Aplicación de controles de recursos

Cada control de recurso incluido en la Tabla 6–1 puede asignarse a un proyecto al inicio de la sesión o cuando se invocan los dispositivos de lanzamiento newtask, su u otros dispositivos de lanzamiento del proyecto at, batch o cron. Cada comando que se inicia se abre en una tarea separada con el proyecto predeterminado del usuario que ejecuta el comando. Si desea más información, consulte las páginas del comando man login(1), newtask(1), at(1), cron(1M) y su(1M).

Las actualizaciones de las entradas de la base de datos project, tanto si son para el archivo /etc/project o una representación de la base de datos en un servicio de nombres de red, no se aplican a los proyectos activos. Las actualizaciones se aplican cuando una tarea nueva se une al proyecto mediante el inicio de sesión o newtask.

Actualización temporal de los valores de controles de recursos en un sistema en ejecución

Los valores modificados en la base de datos project sólo pasan a ser efectivos para las nuevas tareas que se inician en un proyecto. Sin embargo, puede utilizar los comandos rctladm y prctl para actualizar los controles de recursos en un sistema en ejecución.

Actualización de estados de registro

El comando rctladm afecta al estado de registro global de cada control de recurso en todo el sistema. Este comando puede utilizarse para ver el estado global y configurar el nivel de registro de syslog cuando se superan los controles.

Actualización de controles de recursos

Puede ver y modificar temporalmente los valores de controles de recursos y acciones por proceso, tarea o proyecto utilizando el comando prctl. Se especifica un ID de proceso, tarea o proyecto y el comando se aplica al control de recurso en el nivel en el que esté definido el control.

Cualquier modificación en los valores y acciones surtirá efecto de inmediato. No obstante, estas modificaciones se aplican únicamente al proceso, la tarea o el proyecto actuales. Los cambios no se registran en la base de datos project. Si se reinicia el sistema, se pierden las modificaciones. Los cambios permanentes en los controles de recursos deben realizarse en la base de datos project.

Todos los parámetros de los controles de recursos que se pueden modificar en la base de datos project también pueden modificarse con el comando prctl. Pueden añadirse o eliminarse valores básicos o con privilegios. Sus acciones también pueden modificarse. De modo predeterminado, se da por sentado el tipo básico para todas las operaciones, pero los procesos y usuarios con privilegios de superusuario también pueden modificar los controles de recursos con privilegios. No es posible modificar los controles de recursos del sistema.

Comandos utilizados con controles de recursos

En la tabla siguiente se incluyen los comandos que se utilizan con controles de recursos.

La página del comando man resource_controls(5) describe los controles de recursos disponibles a través de la base de datos del proyecto, incluidos los factores de escala y las unidades.

Capítulo 7 Administración de controles de recursos (tareas)

En este capítulo se describe cómo administrar la función de controles de recursos.

Para obtener información general sobre la función de controles de recursos, consulte el Capítulo 6Controles de recursos (descripción general).

Administración de controles de recursos (mapa de tareas)

Configuración de controles de recursos

Cómo definir el número máximo de procesos ligeros para cada tarea de un proyecto

Este procedimiento añade un proyecto denominado x-files al archivo /etc/project y establece un número máximo de procesos ligeros para una tarea creada en el proyecto.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Utilice el comando projadd con la opción -K para crear un proyecto denominado x-files. Defina el número máximo de procesos ligeros para cada tarea creada en el proyecto como 3.

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

3. Visualice la entrada en el archivo /etc/project siguiendo uno de estos métodos:

   • Type:

     # 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)

   • Type:

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

Ejemplo 7–1 Ejemplo de sesión

Una vez implementados los pasos de este procedimiento, cuando el superusuario cree una tarea en el proyecto x-files uniendo el proyecto con newtask, el no podrá crear más de tres procesos ligeros mientras se ejecute esta tarea. Esto puede verse en la siguiente sesión de ejemplo.

# 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
#

Cómo definir múltiples controles en un proyecto

El archivo /etc/project puede contener parámetros de varios controles de recursos para cada proyecto, así como diferentes valores umbral para cada control. Los valores umbral se definen en las cláusulas de acción, que se separan con comas en caso de haber múltiples valores.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Utilice el comando projmod con las opciones -s y -K para definir los controles de recursos en el proyecto 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

   Se definen los controles siguientes:

   • Un control basic sin acción en el máximo de procesos ligeros por tarea.

   • Un control deny con privilegios en el máximo de procesos ligeros por tarea. Este control hace que falle la creación de cualquier proceso ligero que supere el máximo, tal como se muestra en el ejemplo de Cómo definir el número máximo de procesos ligeros para cada tarea de un proyecto.

   • Un límite para los descriptores de archivo por proceso en el nivel basic, que hace que falle cualquier llamada open que supere el máximo.

3. Visualice la entrada en el archivo utilizando uno de estos métodos:

   • Type:

     # 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

   • Type:

     # 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 del comando prctl

Utilice el comando prctl para realizar interrogaciones de tiempo de ejecución y modificaciones de los controles de recursos asociados con un proceso, una tarea o un proyecto activos en el sistema. Consulte la página del comando man prctl(1) para obtener más información.

Cómo utilizar el comando prctl para ver los valores de control de recursos predeterminados

Debe utilizarse este procedimiento en un sistema en el que no se hayan configurado ni modificado controles de recursos. En el archivo /etc/system o la base de datos project sólo puede haber entradas no predeterminadas.

1. Utilice el comando prctl en cualquier proceso, como el shell en ejecución.

   # 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 -

Cómo utilizar el comando prctl para ver información de un control de recurso

1. Visualice el máximo de descriptores de archivo para el shell que está en ejecución.

   # 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

Cómo utilizar prctl para cambiar un valor temporalmente

Este procedimiento de ejemplo utiliza el comando prctl para añadir temporalmente un nuevo valor con privilegios con el fin de denegar el uso de más de tres procesos ligeros por proyecto para el proyecto x-files. El resultado se puede comparar con el resultado de Cómo definir el número máximo de procesos ligeros para cada tarea de un proyecto.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Utilice newtask para unir el proyecto x-files.

   # newtask -p x-files

3. Utilice el comando id con la opción - p para verificar que se ha unido el proyecto correcto.

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

4. Añada un nuevo valor con privilegios para project.max-lwps que limite el número de procesos ligeros a tres.

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

5. Compruebe el 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 -

Cómo utilizar prctl para reducir el valor de control de recurso

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Utilice el comando prctl con la opción -r para cambiar el valor inferior del control de recurso process.max-file-descriptor.

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

Cómo utilizar prctl para ver, sustituir y verificar el valor de un control en un proyecto

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Visualice el valor de project.cpu-shares en el proyecto 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. Sustituya el valor actual project.cpu-shares 1 con el valor 10.

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

4. Visualice el valor de project.cpu-shares en el proyecto 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

Cómo utilizar rctladm

Utilice el comando rctladm para realizar interrogaciones de tiempo de ejecución y modificaciones en el estado global de las funciones de controles de recursos. Consulte la página del comando man rctladm(1M) para obtener más información.

Por ejemplo, puede utilizar el comando rctladm con la opción -e para permitir el atributo syslog global de un control de recurso. Cuando se supera el control, la notificación se registra en el nivel syslog especificado. Para activar el atributo syslog global de process.max-file-descriptor, escriba:

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

Cuando se utiliza sin argumentos, el comando rctladm muestra los indicadores globales, incluido el indicador de tipo global, para cada control 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

Cómo utilizar ipcs

La utilidad ipcs permite mostrar información sobre las funciones de comunicación entre procesos (IPC) activas. Consulte la página del comando man ipcs(1) para obtener más información.

Puede utilizar ipcs con la opción -J para ver qué límite de proyecto tiene asignado un objeto IPC.

# 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

Advertencias de capacidad

Una acción global en un control de recurso permite recibir una advertencia de cualquier entidad que se encuentre con un valor de control de recurso configurado con un valor demasiado bajo.

Por ejemplo, supongamos que desea determinar si un servidor Web tiene suficiente CPU para su carga de trabajo típica. Puede analizar los datos sar para el tiempo de inactividad de la CPU y el promedio de carga. También puede examinar los datos de contabilidad ampliada con el fin de determinar el número de procesos simultáneos que se ejecutan para el proceso del servidor Web.

Sin embargo, un modo más sencillo de averiguarlo es colocar el servidor Web en una tarea. Puede definir una acción global, utilizando syslog, para recibir una notificación cada vez que una tarea supere el número planificado de procesos ligeros apropiados para la capacidad del equipo.

Consulte la página del comando man sar(1) para obtener más información.

Cómo determinar si un servidor Web tiene asignada suficiente capacidad de CPU

1. Utilice el comando prctl para colocar un control de recurso con privilegios (de un superusuario) en las tareas que contienen un proceso httpd. Limite el número total de procesos ligeros de cada tarea a 40, y desactive todas las acciones locales.

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

2. Active una acción global de registro del sistema en el control de recurso task.max-lwps.

   # rctladm -e syslog task.max-lwps

3. Observe si la carga de trabajo se encuentra con el control de recurso.

   Si lo hace, verá /var/adm/messages del modo siguiente:

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

Capítulo 8 Programador de reparto justo (descripción general)

El análisis de los datos de carga de trabajo puede indicar que una carga de trabajo particular o un grupo de cargas de trabajo está monopolizando los recursos de la CPU. Si estas cargas de trabajo no infringen las restricciones de recursos sobre el uso de la CPU, puede modificar la política de asignación de tiempo de la CPU en el sistema. La clase de planificación de reparto justo descrita en este capítulo permite asignar tiempo de CPU basándose en los recursos compartidos en lugar del esquema de prioridades de la clase de planificación de tiempo compartido (TS).

En este capítulo se tratan los temas siguientes.

• Introducción al programador

• Definición de recurso compartido de CPU

• Recursos compartidos de la CPU y estado del proceso

• Recursos compartidos de la CPU frente al uso

• Ejemplos de recursos compartidos de la CPU

• Configuración de FSS

• FSS y conjuntos de procesadores

• Combinación de FSS con otras clases de programación

• Configuración de la clase de programación para el sistema

• Clase de programación en un sistema con zonas instaladas

• Comandos utilizados con FSS

Para empezar a utilizar el programador de reparto justo, consulte el Capítulo 9Administración del programador de reparto justo (tareas).

Introducción al programador

Un trabajo fundamental del sistema operativo es determinar qué procesos obtienen acceso a los recursos del sistema. El programador del proceso, también denominado distribuidor, es la parte del núcleo que controla la asignación de CPU a los procesos. El programador respalda el concepto de las clases de planificación. Cada clase define una política de planificación que se utiliza para planificar procesos en la clase. El programador predeterminado del sistema operativo Solaris (programador TS) intenta asignar a cada proceso un acceso relativamente equitativo a las CPU disponibles. Sin embargo, puede especificar que determinados procesos tengan asignados más recursos que otros.

Puede utilizar el programador de reparto justo (FSS) para controlar la asignación de los recursos de CPU disponibles entre las cargas de trabajo, basándose en su importancia. Esta importancia se expresa con el número de recursos compartidos de la CPU que asigna a cada carga de trabajo.

A cada proyecto se asignan recursos compartidos de CPU para controlar el derecho que tiene el proyecto a los recursos de la CPU. El programador FSS garantiza un reparto justo de los recursos de la CPU entre los proyectos. Se basa en los recursos compartidos asignados, independientemente del número de procesos asociados al proyecto. El programador FSS logra realizar un reparto justo al reducir el derecho de un proyecto a un uso elevado de la CPU y aumentar su derecho a un uso más reducido, de acuerdo con la existencia de otros proyectos.

El programador FSS se compone de un módulo de clases de programación de núcleo y de versiones específicas de las clases de los comandos dispadmin(1M) y priocntl(1). Los recursos compartidos del proyecto que utiliza FSS se especifican mediante la propiedad project.cpu-shares en la base de datos project(4).

Si está utilizando el control de recurso project.cpu-shares en un sistema con zonas instaladas, consulte Datos de configuración de zonas, Controles de recursos utilizados en zonas no globales y Uso del programador de reparto justo en un sistema Solaris con zonas instaladas.

Definición de recurso compartido de CPU

El término "recurso compartido" se utiliza para definir una parte de los recursos de la CPU del sistema asignada a un proyecto. Si asigna un número mayor de recursos compartidos de la CPU a un proyecto, en relación con otros proyectos, el proyecto recibirá más recursos de CPU del programador de reparto justo.

Los recursos compartidos de la CPU no son equivalentes a los porcentajes de recursos de la CPU. Los recursos compartidos se utilizan para definir la importancia relativa de las cargas de trabajo con respecto a otras cargas de trabajo. Al asignar recursos compartidos de la CPU a un proyecto, lo más importante no es el número de recursos compartidos que tiene el proyecto. Es más importante conocer cuántos recursos compartidos tiene el proyecto en comparación con otros proyectos. También debe tomar en consideración cuántos de los proyectos competirán con él por los recursos de la CPU.

Los procesos de proyectos con ningún recurso compartido siempre se ejecutan con la prioridad de sistema inferior (0). Estos procesos sólo se ejecutan cuando los proyectos que no tienen recursos compartidos no utilizan recursos de la CPU.

Recursos compartidos de la CPU y estado del proceso

En el sistema Solaris, una carga de trabajo de proyecto suele estar compuesta por más de un proceso. Desde el punto de vista del programador de reparto justo, la carga de trabajo de cada proyecto puede encontrarse en un estado inactivo o activo. Un proyecto se considera inactivo si ninguno de sus procesos utiliza recursos de la CPU. Esto significa que dichos procesos están en segundo plano (a la espera de que finalice la E/S) o detenidos. Un proyecto se considera activo si al menos uno de sus procesos utiliza recursos de la CPU. La suma de recursos compartidos de todos los proyectos activos se utiliza para calcular la parte de recursos de la CPU que se asignará a los proyectos.

Cuando más proyectos pasan a estar activos, se reduce la asignación de CPU de cada proyecto, pero la proporción entre las asignaciones de los diferentes proyectos no cambia.

Recursos compartidos de la CPU frente al uso

La asignación de recursos compartidos no es lo mismo que el uso. Un proyecto que tiene asignado el 50 por ciento de los recursos de la CPU puede tener un promedio de sólo un 20 por ciento de uso de la CPU. Además, los recursos compartidos permiten limitar el uso de la CPU sólo cuando compiten con otros proyectos. Independientemente de lo baja que sea la asignación de un proyecto, siempre recibe el 100 por cien de la capacidad de procesamiento si se ejecuta solo en el sistema. Los ciclos de la CPU disponibles nunca se agotan. Se distribuyen entre proyectos.

La asignación de un recurso compartido reducido a una gran carga de trabajo puede disminuir el rendimiento. No obstante, la carga de trabajo completará la tarea si no se sobrecarga el sistema.

Ejemplos de recursos compartidos de la CPU

Supongamos que tiene un sistema con dos CPU que ejecutan dos cargas de trabajo paralelas denominadas A y B. Cada carga de trabajo se ejecuta como un proyecto independiente. Los proyectos se han configurado de modo que el proyecto A tenga asignados S_A recursos compartidos y el proyecto B tenga asignados S_B recursos compartidos.

Como media, con el programador TS tradicional, cada carga de trabajo que se ejecuta en el sistema operativo tiene asignada la misma cantidad de recursos de la CPU. Cada carga de trabajo recibiría el 50 por ciento de la capacidad del sistema.

Cuando los proyectos se ejecutan bajo el control del programador FSS con S _A=S_B, también reciben aproximadamente la misma cantidad de recursos de la CPU. Sin embargo, si los proyectos tienen asignada una cantidad diferente de recursos compartidos, sus asignaciones de recursos de la CPU también serán diferentes.

Los tres ejemplos siguientes muestran el funcionamiento de los recursos compartidos con diferentes configuraciones. Estos ejemplos muestran que los recursos compartidos sólo tienen precisión matemática para representar el uso si la demanda cumple o supera los recursos disponibles.

Ejemplo 1: Dos procesos vinculados a la CPU en cada proyecto

Si A y B tienen dos procesos vinculados a la CPU, S _A = 1 y S _B = 3, el número total de recursos compartidos es 1 + 3 = 4. En esta configuración, si hay suficiente demanda de CPU, a los proyectos A y B se les asigna el 25 por ciento y el 75 por ciento de los recursos de la CPU, respectivamente.

Ejemplo 2: Proyectos que no compiten

Si A y B sólo tienen un proceso vinculado a la CPU y S _A= 1 y S _B = 100, el número total de recursos compartidos es de 101. Cada proyecto no puede utilizar más de una CPU porque cada uno sólo tiene un proceso en ejecución. Dado que en esta configuración no existe competencia entre los proyectos por los recursos de la CPU, los proyectos A y B tienen asignado cada uno un 50 por ciento de todos los recursos de la CPU. En esta configuración, los valores de recursos compartidos de la CPU no son relevantes. Las asignaciones de los proyectos serían las mismas (50/50), aunque ambos proyectos no tengan asignado ningún recurso compartido.

Ejemplo 3: No se puede ejecutar un proyecto

Si A y B tienen dos procesos vinculados a la CPU, y al proyecto A se le asigna 1 recurso compartido y al B ninguno, el proyecto B no tendrá asignado ningún recurso de la CPU y el proyecto A tendrá asignados todos los recursos de la CPU. Los procesos de B siempre se ejecutan con una prioridad del sistema de 0, de modo que nunca podrán ejecutarse porque los procesos del proyecto A siempre tienen prioridades mayores.

Configuración de FSS

Proyectos y usuarios

Los proyectos son los contenedores de la carga de trabajo en el programador FSS. Los grupos de usuarios asignados a un proyecto se consideran bloques únicos. Tenga en cuenta que puede crear un proyecto con su propio número de recursos compartidos para un usuario individual.

Los usuarios pueden ser miembros de varios proyectos que tengan diferentes números de recursos compartidos asignados. Al mover procesos de un proyecto a otro, pueden asignarse diferentes cantidades de recursos de la CPU a los proyectos.

Para obtener más información sobre la base de datos project(4) y los servicios de nombres, consulte Base de datos project.

Configuración de recursos compartidos de la CPU

La configuración de los recursos compartidos de la CPU la lleva a cabo el servicio de nombres como una propiedad de la base de datos project.

Cuando la primera tarea (o proceso) que se asocia con un proyecto se crea mediante la función de biblioteca setproject(3PROJECT), el número de recursos compartidos de la CPU definidos como control de recurso project.cpu-shares en la base de datos project se pasa al núcleo. A los proyectos que no tengan definido el control de recurso project.cpu-shares se les asigna un recurso compartido.

En el ejemplo siguiente, esta entrada del archivo /etc/project define el número de recursos compartidos para el proyecto x-files como 5:

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

Si modifica el número de recursos compartidos de la CPU asignados a un proyecto en la base de datos cuando hay procesos en ejecución, el número de recursos compartidos para dicho proyecto no se modificará en ese punto. Es preciso reiniciar el proyecto para que el cambio surta efecto.

Si desea cambiar temporalmente el número de recursos compartidos asignados a un proyecto sin modificar los atributos del proyecto en la base de datos project, utilice el comando prctl. Por ejemplo, para cambiar el valor del control de recurso project.cpu-shares del proyecto x-files a 3 mientras se ejecutan los procesos asociados con dicho proyecto, escriba:

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

Consulte la página del comando man prctl(1) para obtener más información.

-r

Sustituye el valor actual del control de recurso nombrado.

-n nombre

Especifica el nombre del control de recurso.

-v val

Especifica el valor del control de recurso.

-i tipo_ID

Especifica el tipo de ID del siguiente argumento.

x-files

Especifica el objeto del cambio. En esta instancia, el proyecto x-files es el objeto.

El proyecto system con ID 0 incluye todos los daemons del sistema que se inician mediante secuencias de inicio de tiempo de inicio. system puede visualizarse como proyecto en un número ilimitado de recursos compartidos. Esto significa que system siempre se planifica en primer lugar, al margen de los recursos compartidos asignados a otros proyectos. Si no desea que el proyecto system tenga recursos compartidos ilimitados, puede especificar un número de recursos compartidos para este proyecto en la base de datos project.

Como se ha mencionado anteriormente, los procesos que pertenecen a proyectos con ningún recurso compartido siempre tienen la prioridad de sistema cero. Los proyectos con uno o más recursos compartidos se ejecutan con prioridades de uno o más. Por tanto, los proyectos que no tienen ningún recurso compartido sólo se programan cuando hay disponibles recursos de la CPU que no solicite ningún proyecto de recurso compartido que no sea cero.

El número máximo de recursos compartidos que se puede asignar a un proyecto es 65535.

FSS y conjuntos de procesadores

FSS puede utilizarse junto con los conjuntos de procesadores para ofrecer controles más precisos para la asignación de recursos de la CPU a los proyectos que se ejecutan en cada conjunto de procesadores de los que habría disponibles únicamente con los conjuntos de procesadores. El programador FSS trata los conjuntos de procesadores como particiones completamente independientes, y cada conjunto de procesadores se controla de modo independiente con respecto a las asignaciones de la CPU.

Las asignaciones de la CPU de los proyectos que se ejecutan en un conjunto de procesadores no se ven afectadas por los recursos de la CPU o la actividad de los proyectos que se ejecutan en otro conjunto de procesadores porque los proyectos no compiten por los mismos recursos. Los proyectos sólo compiten entre sí si se ejecutan en el mismo conjunto de procesadores.

El número de recursos compartidos asignados a un proyecto se aplica a todo el sistema. Al margen del conjunto de procesadores en el que se ejecute, cada parte de un proyecto tiene asignada la misma cantidad de recursos compartidos.

Cuando se utilizan conjuntos de procesadores, las asignaciones de la CPU del proyecto se calculan para los proyectos activos que se ejecutan en cada conjunto de procesadores.

Las particiones de proyectos que se ejecutan en diferentes conjuntos de procesadores pueden tener diferentes asignaciones de la CPU. La asignación de CPU para cada partición de proyecto de un conjunto de procesadores depende únicamente de las asignaciones de otros proyectos que se ejecutan en el mismo conjunto de procesadores.

El rendimiento y la disponibilidad de las aplicaciones que se ejecutan dentro de los límites de sus conjuntos de procesadores no se ven afectados por la introducción de nuevos conjuntos de procesadores. Las aplicaciones tampoco se ven afectadas por los cambios realizados en las asignaciones de recursos compartidos de los proyectos que se ejecutan en otros conjuntos de procesadores.

Los conjuntos de procesadores vacíos (conjuntos que no contienen procesadores) o los conjuntos de procesadores que no tienen procesos vinculados no tienen ninguna repercusión en el comportamiento del programador FSS.

FSS y ejemplos de conjuntos de procesadores

Supongamos que un servidor con ocho CPU ejecuta varias aplicaciones vinculadas a CPU en los proyectos A, B y C. El proyecto A tiene asignado un recurso compartido, el proyecto B tiene asignados dos recursos compartidos y el proyecto C tiene asignados tres recursos compartidos.

El proyecto A sólo se está ejecutando en el conjunto de procesadores 1. El proyecto B se está ejecutando en el conjunto de procesadores 1 y 2. El proyecto C se está ejecutando en el conjunto de procesadores 1, 2 y 3. Se da por supuesto que cada proyecto tiene suficientes procesos para utilizar toda la energía de la CPU disponible. De este modo, cada conjunto de procesadores siempre compite por los recursos de la CPU.

En la tabla siguiente se muestran las asignaciones de CPU totales del proyecto para un sistema de ese tipo.

Estos porcentajes no coinciden con las cantidades correspondientes de recursos compartidos de la CPU que se asignan a los proyectos. Sin embargo, en cada conjunto de procesadores, la asignación de CPU por proyecto es proporcional a sus respectivos recursos compartidos.

En el mismo sistema sin conjuntos de procesadores, la distribución de los recursos compartidos de la CPU sería diferente, tal como se muestra en la tabla siguiente.

Combinación de FSS con otras clases de programación

De modo predeterminado, la clase de programación de FSS utiliza el mismo intervalo de prioridades (de 0 a 59) que las clases de programación de tiempo compartido (TS), interactivas (IA) y de prioridad fija (FX). Por tanto, debe evitar tener procesos de estas clases de planificación que compartan el mismo conjunto de procesadores. Una combinación de los procesos en FSS y las clases TS, IA y FX podría ocasionar un comportamiento de programación inesperado.

Gracias al uso de conjuntos de procesadores, puede combinar TS, IA y FX con FSS en un sistema. Sin embargo, todos los procesos que se ejecutan en cada conjunto de procesadores deben estar en una clase de planificación, de modo que no compitan por las mismas CPU. En concreto, no debe utilizarse el programador FX junto con la clase de programación de FSS a menos que se utilicen conjuntos de procesadores. Esta acción evita que las aplicaciones de la clase FX utilicen prioridades lo suficientemente altas para quedarse sin aplicaciones en la clase FSS.

Puede combinar procesos en las clases TS e IA en el mismo conjunto de procesadores, o en el mismo sistema sin conjuntos de procesadores.

El sistema Solaris también ofrece un programador en tiempo real (RT) a los usuarios con privilegios de superusuario. De modo predeterminado, la clase de programación RT utiliza prioridades del sistema en un intervalo diferente (normalmente de 100 a 159) que FSS. Dado que RT y FSS utilizan intervalos de prioridades inconexos o no superpuestos, FSS puede coexistir con la clase de programación RT en el mismo conjunto de procesadores. Sin embargo, la clase de programación FSS no tiene ningún control sobre los procesos que se ejecutan en la clase RT.

Por ejemplo, en un sistema de cuatro procesadores, un proceso RT de un único subproceso puede consumir un procesador completo si el proceso está vinculado a la CPU. Si el sistema también ejecuta FSS, los procesos regulares del usuario compiten por las tres CPU restantes que no utiliza el proceso RT. Tenga en cuenta que es posible que el proceso RT no utilice la CPU de forma continuada. Cuando el proceso RT está inactivo, FSS utiliza los cuatro procesadores.

Puede escribir el comando siguiente para averiguar en qué clases de programación se ejecutan los conjuntos de procesadores y asegurarse de que cada conjunto de procesadores esté configurado para ejecutarse en procesos TS, IA, FX o FSS.

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

Configuración de la clase de programación para el sistema

Para establecer la clase de programación predeterminada para el sistema, consulte Cómo convertir FSS en la clase de programador predeterminada, Clase de planificación en una zona y dispadmin(1M). Para mover los procesos en ejecución a una clase de programación diferente, consulte Configuración de FSS y priocntl(1).

Clase de programación en un sistema con zonas instaladas

Las zonas no globales utilizan la clase de programación predeterminada para el sistema. Si el sistema se actualiza con una nueva configuración de clase de programación predeterminada, las zonas no globales obtienen la nueva configuración al iniciarse o reiniciarse.

En este caso, se recomienda configurar FSS como la clase de programación predeterminada del sistema con el comando dispadmin. De este modo, todas las zonas se beneficiarán de un reparto justo de los recursos de la CPU del sistema. Consulte Clase de planificación en una zona para obtener más información sobre la clase de planificación cuando las zonas están en uso.

Para obtener información sobre cómo mover procesos en ejecución a una clase de programación distinta sin cambiar las clase de programación predeterminada y reiniciar, consulte la Tabla 27–5 y la página del comando man priocntl(1).

Comandos utilizados con FSS

Los comandos que se muestran en la tabla siguiente proporcionan la interfaz administrativa principal para el programador de reparto justo.

Capítulo 9 Administración del programador de reparto justo (tareas)

En este capítulo se describe cómo utilizar el programador de reparto justo (FSS).

Para ver una descripción general de FSS, consulte el Capítulo 8Programador de reparto justo (descripción general). Para obtener información sobre la clase de planificación cuando hay zonas en uso, consulte Clase de planificación en una zona.

Administración del programador de reparto justo (mapa de tareas)

Supervisión de FSS

Puede utilizar el comando prstat descrito en la página del comando man prstat(1M) para supervisar el uso de la CPU que hacen los proyectos activos.

Puede utilizar los datos de contabilidad ampliada para las tareas con el fin de obtener estadísticas por proyecto sobre la cantidad de recursos de la CPU que se consumen durante períodos más prolongados. Consulte el Capítulo 4Contabilidad ampliada (descripción general) para obtener información adicional.

Cómo supervisar el uso que hacen los proyectos de la CPU del sistema

1. Para supervisar el uso de la CPU que hacen los proyectos que se ejecutan en el sistema, utilice el comando prstat con la opción -J.

   % prstat -J

Cómo supervisar el uso de la CPU que hacen los proyectos en los conjuntos de procesadores

1. Para supervisar el uso que hacen de la CPU los proyectos que se encuentran en una lista de conjuntos de procesadores, escriba:

   % prstat -J -C pset-list

   donde pset-list es una lista de los ID de conjuntos de procesadores, separada por comas.

Configuración de FSS

Con FSS pueden utilizarse los mismos comandos que se utilizan con otras clases de planificación en el sistema Solaris. Puede definir la clase de programador, configurar los parámetros ajustables del programador y establecer las propiedades de los procesos individuales.

Tenga en cuenta que puede utilizar svcadm restart para reiniciar el servicio del programador. Consulte svcadm(1M) para más información.

Cómo convertir FSS en la clase de programador predeterminada

Para que la asignación de recursos compartidos de la CPU surta efecto, FSS debe ser el programador predeterminado del sistema.

El uso de una combinación de los comandos priocntl y dispadmin garantiza que FSS pasará a ser de inmediato el programador predeterminado y también tras el reinicio.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Configure FSS como el programador predeterminado del sistema.

   # dispadmin -d FSS

   Este cambio surtirá efecto la próxima vez que reinicie. Tras reiniciar, todos los procesos del sistema se ejecutarán en la clase de planificación FSS.

3. Active esta configuración inmediatamente, sin reiniciar.

   # priocntl -s -c FSS -i all

Cómo mover manualmente los procesos de la clase TS a la clase FSS

Puede mover manualmente los procesos de una clase de planificación a otra sin cambiar la clase de planificación predeterminada ni reiniciar. Este procedimiento muestra cómo mover manualmente los procesos de la clase de planificación TS a la clase de planificación FSS.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Mueva el proceso init (pid 1) a la clase de planificación FSS.

   # priocntl -s -c FSS -i pid 1

3. Mueva todos los procesos de la clase de planificación TS a la clase de planificación FSS.

   # priocntl -s -c FSS -i class TS

   ---

   Nota –

   Tras el reinicio, todos los procesos volverán a ejecutarse en la clase de planificación TS.

   ---

Cómo mover manualmente los procesos de todas las clases de usuario a la clase FSS

Puede utilizar una clase predeterminada que no sea TS. Por ejemplo, el sistema puede ejecutar un entorno de ventanas que utilice una clase IA de modo predeterminado. Puede mover todos los procesos a la clase de planificación FSS sin cambiar la clase de planificación predeterminada ni reiniciar.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Mueva el proceso init (pid 1) a la clase de planificación FSS.

   # priocntl -s -c FSS -i pid 1

3. Mueva todos los procesos de sus clases de planificación actuales a la clase de planificación FSS.

   # priocntl -s -c FSS -i all

   ---

   Nota –

   De nuevo, todos los procesos se ejecutarán en la clase de planificación predeterminada después de reiniciar.

   ---

Cómo mover manualmente los procesos de un proyecto a la clase FSS

Puede mover manualmente los procesos de un proyecto de su clase de planificación actual a la clase de planificación FSS.

1. Conviértase en superusuario o asuma una función similar.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Mueva los procesos que se ejecutan en el ID de proyecto 10 a la clase de planificación FSS.

   # priocntl -s -c FSS -i projid 10

   De nuevo, los procesos del proyecto se ejecutarán en la clase de planificación predeterminada después de reiniciar.

Cómo ajustar los parámetros del programador

Puede utilizar el comando dispadmin para mostrar o cambiar los parámetros del programador de procesos mientras el sistema está en ejecución. Por ejemplo, puede utilizar dispadmin para examinar y ajustar el valor de tiempo del programador FSS. El valor de tiempo es la cantidad de tiempo durante la que puede ejecutarse un subproceso antes de renunciar al procesador.

Para ver el valor de tiempo actual para el programador FSS mientras se ejecuta el sistema, escriba:

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

Si utiliza la opción -g, también puede utilizar la opción -r para especificar la resolución que se utiliza para imprimir valores de tiempo. Si no se especifica ninguna resolución, los valores de tiempo se muestran de forma predeterminada en milisegundos.

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

Para definir los parámetros de planificación para la clase de planificación FSS, utilice dispadmin -s. Los valores de archivo deben tener el formato de la opción -g. Estos valores sobrescriben los valores actuales del núcleo. Escriba lo siguiente:

$ dispadmin -c FSS -s file

Capítulo 10 Control de memoria física utilizando el daemon de límite de recursos (descripción general)

El daemon de límite de recursos rcapd permite regular el consumo de memoria física por parte de los procesos que se ejecutan en los proyectos que tienen definidos límites de recursos.

Solaris 10 8/07: Si está ejecutando zonas en el sistema, puede utilizar rcapd desde la zona global para regular el consumo de memoria física en las zonas no globales. Consulte el Capítulo 18Planificación y configuración de zonas no globales (tareas).

En este capítulo se cubren los temas siguientes.

• Introducción al daemon de límite de recursos

• Funcionamiento de los límites de recursos

• Atributo para limitar el uso de memoria física para proyectos

• Configuración de rcapd

• Supervisión del uso de recursos con rcapstat

• Comandos utilizados con rcapd

Para conocer los procedimientos que utilizan la función rcapd, consulte el Capítulo 11Administración del daemon de límite de recursos (tareas).

Novedades en el control de la memoria física utilizando el daemon de límite de recursos

Solaris 10 Ahora puede utilizar el comando projmod para configurar el atributo rcap.max-rss en el archivo /etc/project.

Solaris 10 11/06: se ha agregado información sobre cómo habilitar e inhabilitar el daemon de límite de recursos como servicio de la utilidad de gestión de servicios (SMF) de Solaris.

Para ver una lista completa de las nuevas funciones de Solaris 10 y una descripción de las versiones de Solaris, consulte Novedades de Oracle Solaris 10 9/10.

Introducción al daemon de límite de recursos

Un límite de recursos es un límite superior colocado para el consumo de un recurso, como la memoria física. Se admite el uso de límites de memoria física por proyecto.

El daemon de límite de recursos y sus utilidades asociadas proporcionan mecanismos para la aplicación y administración de límites de recursos en la memoria física.

Al igual que el control de recursos, el límite de recursos se puede definir utilizando los atributos de entradas de proyecto en la base de datos project. Sin embargo, mientras que los controles de recursos los aplica de forma sincronizada el núcleo, los límites de recursos los aplica el daemon de límite de recursos en el nivel del usuario y sin sincronización. En el caso de la aplicación asíncrona, tiene lugar un breve retardo como consecuencia del intervalo de muestreo que utiliza el daemon.

Para obtener información sobre rcapd, consulte la página del comando man rcapd(1M) Para obtener información sobre los proyectos y la base de datos project, consulte el Capítulo 2Proyectos y tareas (información general) y la página del comando man project(4) Para obtener información sobre los controles de recursos, consulte el Capítulo 6Controles de recursos (descripción general).

Funcionamiento de los límites de recursos

El daemon muestrea de forma repetida el uso de los recursos de los proyectos que tienen límites de memoria física. El administrador especifica el intervalo de muestreo que utiliza el daemon. Consulte Cómo determinar los intervalos de muestra para obtener información adicional. Cuando el uso de la memoria física del sistema supera el umbral para la aplicación del límite, y además se dan otras condiciones, el daemon emprende las acciones necesarias para reducir el consumo de recursos de los proyectos con límites de memoria a niveles iguales o inferiores a los establecidos por los límites.

El sistema de memoria virtual divide la memoria física en segmentos conocidos como páginas. Las páginas son la unidad fundamental de memoria física del subsistema de administración de memoria de Solaris. Para leer datos de un archivo en la memoria, el sistema de memoria virtual lee una página cada vez, o carga la página en un archivo. Para reducir el consumo de recursos, el daemon puede extraer, o reasignar, las páginas poco utilizadas a un dispositivo de intercambio, que es un área fuera de la memoria física.

El daemon administra la memoria física regulando el tamaño del conjunto residente de la carga de trabajo de un proyecto para adaptarlo al tamaño de su conjunto de trabajo. El conjunto residente es el conjunto de páginas que residen en la memoria física. El conjunto de trabajo es el conjunto de páginas que utiliza la carga de trabajo de forma activa durante su ciclo de procesamiento. El conjunto de trabajo cambia con el tiempo, en función del modo de funcionamiento del proceso y el tipo de datos que se procesan. Se recomienda que cada carga de trabajo tenga acceso a la suficiente memoria física para permitir que su conjunto de trabajo permanezca como residente. Sin embargo, el conjunto de trabajo también puede incluir el uso de almacenamiento de disco secundario para contener la memoria que no quepa en la memoria física.

Sólo puede ejecutarse una instancia de rcapd en un momento preciso.

Atributo para limitar el uso de memoria física para proyectos

Para definir un límite de recurso de memoria física para un proyecto, establezca un límite en el tamaño de conjunto residente (RSS) añadiendo este atributo a la entrada de la base de datos project:

rcap.max-rss

La cantidad total de memoria física, en bytes, disponible para los procesos del proyecto.

Por ejemplo, la siguiente línea del archivo /etc/project define un límite RSS de 10 gigabytes para un proyecto denominado db.

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

El sistema puede redondear el valor límite especificado a un tamaño de página.

Puede utilizar el comando projmod para definir el atributo rcap.max-rss en el archivo /etc/project:

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

El archivo /etc/project contiene la línea:

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

Configuración de rcapd

Utilice el comando rcapadm para configurar el daemon de límite de recursos. Puede realizar las siguientes acciones:

• Definir el valor umbral para la aplicación del límite

• Establecer intervalos para las operaciones realizadas por rcapd

• Activar o desactivar los límites de recursos

• Mostrar el estado actual del daemon de límite de recursos configurado

Para configurar el daemon, debe tener privilegios de superusuario o tener el perfil de administración de procesos en la lista de perfiles. Tanto el rol de administración de procesos como el rol del administrador de sistemas incluyen el perfil de administración de procesos.

Los cambios de configuración se pueden incorporar en rcapd de acuerdo con el intervalo de configuración (consulte Intervalos de operación rcapd) o según se solicite enviando SIGHUP (consulte la página del comando man kill(1)).

Si se utiliza sin argumentos, rcapadm muestra el estado actual del daemon de límite de recursos si se ha configurado.

En las subsecciones siguientes se describe la aplicación del límite, los valores de límite y los intervalos de funcionamiento de rcapd.

Uso del daemon de límite de recursos en un sistema con zonas instaladas

Puede controlar el uso del tamaño del conjunto residente (RSS) de una zona configurando el recurso capped-memory cuando configura la zona. Para más información, consulte Solaris 10 8/07: control de memoria física y recurso capped-memory. Puede ejecutar el comando rcapd en una zona, incluida la zona global, para aplicar límites de memoria a los proyectos de dicha zona.

Puede establecer un límite temporal para la cantidad máxima de memoria que puede consumir una zona especificada, hasta la próxima vez que se reinicie el sistema. Consulte Cómo especificar un límite de recursos temporal para una zona .

Si utiliza rcapd en una zona para regular el consumo de memoria física por parte de los procesos que se ejecutan en proyectos que tengan definidos límites de recursos, debe configurar el daemon en dicha zona.

Al seleccionar límites de memoria para las aplicaciones en diferentes zonas, normalmente no es necesario que las aplicaciones residan en zonas distintas. Una excepción a esta norma son los servicios por zona. Dichos servicios consumen memoria. Este consumo de memoria debe tenerse en cuenta a la hora de determinar la cantidad de memoria física para un sistema, así como los límites de memoria.

No puede ejecutar rcapd en una zona con marca lx. Sin embargo, puede utilizar el daemon de la zona global para limitar la memoria de la zona con marca.

Umbral de aplicación de límite de memoria

El umbral de aplicación de límite de memoria es el porcentaje de utilización de la memoria física del sistema que activa la aplicación del límite. Cuando el sistema supera esta utilización, se aplican los límites. La memoria física que utilizan las aplicaciones y el núcleo se incluye en este porcentaje. El porcentaje de utilización determina el modo en que se aplican los límites de memoria.

Para aplicar los límites, puede extraer memoria de las cargas de trabajo del proyecto.

• La memoria puede extraerse para reducir el tamaño de la parte de memoria que supera el límite para una carga de trabajo determinada.

• La memoria puede extraerse para reducir la proporción de memoria física utilizada que supera el umbral de aplicación del límite de memoria en el sistema.

Se permite una carga de trabajo para utilizar la memoria física hasta su límite. Una carga de trabajo puede utilizar memoria adicional siempre que el uso de memoria del sistema esté por debajo del umbral de aplicación del límite de la memoria.

Para definir el valor para la aplicación del límite, consulte Cómo establecer el umbral de aplicación del límite de memoria.

Cómo determinar valores límite

Si un límite de proyecto está configurado con un valor demasiado bajo, es posible que no haya suficiente memoria para que la carga de trabajo siga funcionando de forma eficaz en condiciones normales. La paginación que se produce porque la carga de trabajo requiere más memoria afecta negativamente al rendimiento del sistema.

Los proyectos que tienen límites demasiado elevados pueden consumir la memoria física disponible antes de alcanzar los límites. En ese caso, el núcleo administra de forma eficaz la memoria física, no el comando rcapd.

Tenga en cuenta los siguientes aspectos a la hora de determinar los límites de los proyectos.

Impacto en el sistema de E/S

El daemon puede intentar reducir el uso de memoria física de la carga de trabajo de un proyecto siempre que el uso muestreado supere el límite del proyecto. Durante la aplicación del límite, se utilizan los dispositivos de intercambio y otros dispositivos que contienen archivos que ha asignado la carga de trabajo. El rendimiento de los dispositivos de intercambio es un factor crítico a la hora de determinar el rendimiento de una carga de trabajo que excede su límite de forma rutinaria. La ejecución de la carga de trabajo es similar a su ejecución en un equipo con la misma cantidad de memoria física que el límite de la carga de trabajo.

Impacto en el uso de CPU

El uso de CPU del daemon varía según el número de procesos de las cargas de trabajo del proyecto que limita y el tamaño de los espacios de direccionamiento de las cargas de trabajo.

Una pequeña parte del tiempo de CPU del daemon se dedica a muestrear el uso de cada carga de trabajo. Añadir procesos a las cargas de trabajo aumenta el tiempo que se dedica a muestrear el uso.

Otra parte del tiempo de CPU del daemon se dedica a aplicar los límites cuando se superan. El tiempo dedicado es proporcional a la cantidad de memoria virtual asignada. El tiempo de CPU dedicado aumenta o disminuye según los cambios correspondientes en el tamaño total del espacio de direccionamiento de la carga de trabajo. Esta información se registra en la columna vm de la salida de rcapstat. Para obtener más información, consulte Supervisión del uso de recursos con rcapstat y la página del comando man rcapstat(1).

Informes de memoria compartida

El daemon rcapd informa al RSS sobre las páginas de memoria que se comparten con otros procesos o que se asignan varias veces en un mismo proceso, a modo de promedio bastante preciso. Si hay procesos de distintos proyectos que comparten la misma memoria, dicha memoria se cuenta con el total del RSS para todos los proyectos que comparten la memoria.

El promedio se utiliza con cargas de trabajo como bases de datos, que utilizan una gran cantidad de memoria compartida. Para las cargas de trabajo de bases de datos, también puede probar con un uso habitual del proyecto para definir un valor límite inicial apropiado utilizando el resultado de las opciones -J o -Z del comando prstat. Para obtener más información, consulte la página de comando man prstat(1M).

Intervalos de operación rcapd

Puede configurar los intervalos para las operaciones periódicas que lleve a cabo rcapd.

Todos los intervalos se especifican en segundos. En la tabla siguiente se describen las operaciones rcapd y sus valores de intervalo predeterminados.

Para configurar los intervalos, consulte Cómo configurar intervalos de funcionamiento.

Cómo determinar los intervalos de exploración de rcapd

El intervalo de exploración controla la frecuencia con la que rcapd busca nuevos procesos. En los sistemas con múltiples procesos en ejecución, la exploración de la lista requiere más tiempo, de modo que quizá sea recomendable alargar el intervalo con el fin de reducir el tiempo de CPU global dedicado. Sin embargo, el intervalo de exploración también representa la cantidad de tiempo mínima durante la que debe existir un proceso para asignarse a una carga de trabajo limitada. Si hay cargas de trabajo que ejecutan múltiples procesos cortos, rcapd podría no atribuir los procesos a una carga de trabajo si se prolonga el intervalo de exploración.

Cómo determinar los intervalos de muestra

El intervalo de muestra configurado con rcapadm es la cantidad de tiempo más breve que rcapd espera entre el muestreo del uso de una carga de trabajo y la aplicación del límite si se supera. Si reduce este intervalo, de los casos rcapd aplicará los límites con mayor frecuencia, lo que posiblemente generará una mayor E/S debido a la paginación. Sin embargo, un intervalo de muestra más breve también puede disminuir el impacto que podría tener un aumento repentino del uso de memoria física de una carga de trabajo específica en otras cargas de trabajo. Se estrecha la ventana entre muestreos, en la que la carga de trabajo puede consumir memoria no afectada y posiblemente obtener memoria de otras cargas de trabajo limitadas.

Si el intervalo de muestra especificado como rcapstat es más breve que el intervalo especificado como rcapd con rcapadm, la salida de algunos intervalos puede ser cero. Esta situación tiene lugar porque rcapd no actualiza las estadísticas con mayor frecuencia que el intervalo especificado con rcapadm. El intervalo especificado con rcapadm es independiente del intervalo de muestreo que utiliza rcapstat.

Supervisión del uso de recursos con rcapstat

Utilice rcapstat para supervisar el uso de recursos de los proyectos limitados. Para ver un ejemplo del informe rcapstat, consulte Creación de informes con rcapstat.

Puede configurar el intervalo de muestreo para el informe y especificar el número de veces que se repiten las estadísticas.

intervalo

Especifica el intervalo de muestreo en segundos. El intervalo predeterminado es de 5 segundos.

count

Especifica el número de veces que se repiten las estadísticas. De modo predeterminado, rcapstat registra las estadísticas hasta que se recibe una señal de finalización o hasta que termina el proceso de rcapd.

Las estadísticas de paginación del primer informe que emite rcapstat muestran la actividad desde el inicio del daemon. Los informes subsiguientes reflejan la actividad desde que se emitió el último informe.

La tabla siguiente define las cabeceras de columna de un informe rcapstat.

Comandos utilizados con rcapd

Capítulo 11 Administración del daemon de límite de recursos (tareas)

Este capítulo contiene procedimientos para configurar y utilizar el daemon de límite de recursos rcapd.

Para ver una descripción general de rcapd, consulte el Capítulo 10Control de memoria física utilizando el daemon de límite de recursos (descripción general).

Configuración y uso del daemon de límite de recursos (mapa de tareas)

Administración del daemon de límite de recursos con rcapadm

Esta sección contiene los procedimientos para configurar el daemon de límite de recursos con el comando rcapadm. Consulte Configuración de rcapd y la página del comando man rcapadm(1M) para obtener información adicional. El uso de rcapadm para especificar un límite de recursos temporal para una zona también queda cubierto.

Si se utiliza sin argumentos, rcapadm muestra el estado actual del daemon de límite de recursos si se ha configurado.

Cómo establecer el umbral de aplicación del límite de memoria

Pueden configurarse los límites para que no se apliquen hasta que quede poca memoria física disponible para los procesos. Consulte Umbral de aplicación de límite de memoria para obtener más información.

El valor mínimo (y predeterminado) es 0, lo que significa que los límites de memoria siempre se aplican. Para definir un mínimo distinto, siga este procedimiento.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener información sobre cómo crear el rol y asignarlo a un usuario, consulte el apartado Managing RBAC (Task Map) en System Administration Guide: Security Services.

2. Utilice la opción -c de rcapadm para definir un valor de uso de memoria física distinto para la aplicación del límite de memoria.

   # rcapadm -c percent

   por ciento va de 0 a 100. Los valores más altos son menos restrictivos. Un valor más elevado significa que las cargas de trabajo del proyecto limitado pueden ejecutarse sin tener los límites aplicados hasta que el uso de memoria del sistema supere este umbral.

Véase también

Para ver el uso actual de la memoria física y el umbral de aplicación del límite, consulte Informes del uso de la memoria y el umbral de aplicación del límite de la memoria.

Cómo configurar intervalos de funcionamiento

Intervalos de operación rcapd contiene información sobre los intervalos para las operaciones periódicas que lleva a cabo rcapd. Siga este procedimiento para configurar los intervalos de funcionamiento utilizando rcapadm.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener información sobre cómo crear el rol y asignarlo a un usuario, consulte el apartado Managing RBAC (Task Map) en System Administration Guide: Security Services.

2. Utilice la opción -i para configurar los valores del intervalo.

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

   ---

   Nota –

   Todos los valores de intervalo se especifican en segundos.

   ---

Cómo activar los límites de recursos

Existen tres modos de activar los límites de recursos en el sistema. La activación de los límites de recursos también configura el archivo /etc/rcap.conf con los valores predeterminados.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener información sobre cómo crear el rol y asignarlo a un usuario, consulte el apartado Managing RBAC (Task Map) en System Administration Guide: Security Services.

2. Active el daemon de límite de recursos mediante uno de estos procedimientos:

   • Active los límites de recursos utilizando el comando svcadm.

     # svcadm enable rcap

   • Active el daemon de límite de recursos para que se inicie ahora y también cada vez que se inicie el sistema. Para ello, escriba:

     # rcapadm -E

   • Active el daemon de límite de recursos al iniciar sin iniciarlo ahora especificando también la opción -n:

     # rcapadm -n -E

Cómo desactivar los límites de recursos

Hay tres modos de desactivar los límites de recursos del sistema.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener información sobre cómo crear el rol y asignarlo a un usuario, consulte el apartado Managing RBAC (Task Map) en System Administration Guide: Security Services.

2. Desactive el daemon de límite de recursos mediante uno de estos procedimientos:

   • Desactive el límite de recursos utilizando el comando svcadm.

     # svcadm disable rcap

   • Para desactivar el daemon de límite de recursos para que se detenga ahora y que no se inicie al iniciar el sistema, escriba:

     # rcapadm -D

   • Para desactivar el daemon de límite de recursos sin detenerlo, especifique también la opción -n:

     # rcapadm -n -D

   ---

   Consejo –

   Desactivación segura del daemon de límite de recursos

   ---

   Utilice los comandos svcadm o rcapadm con -D para desactivar rcapd de forma segura. Si se cierra el daemon (consulte la página del comando man kill(1)), los procesos podrían quedar detenidos y deberían reiniciarse manualmente. Para reanudar un proceso en ejecución, utilice el comando prun. Consulte la página del comando man prun(1) para obtener más información.

Cómo especificar un límite de recursos temporal para una zona

Este procedimiento se utiliza para asignar la cantidad máxima de memoria que puede consumir una zona especificada. Este valor sólo dura hasta la próxima vez que se reinicie. Para establecer un límite persistente, utilice el comando zonecfg.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos.

2. Establezca un valor máximo de memoria de 512 MB para la zona my-zone.

   # rcapadm -z testzone -m 512M

Creación de informes con rcapstat

Utilice rcapstat para registrar las estadísticas de límites de recursos. Supervisión del uso de recursos con rcapstat explica cómo utilizar el comando rcapstat para generar informes. En dicha sección también se describen las cabeceras de columna en el informe. La página del comando man rcapstat(1) también contiene esta información.

Las siguientes subsecciones utilizan ejemplos para ilustrar el modo en que se producen informes para fines específicos.

Límite de informe e información del proyecto

En este ejemplo, se definen límites para dos proyectos asociados con dos usuarios. user1 tiene un límite de 50 megabytes y user2 un límite de 10 megabytes.

El comando siguiente produce cinco informes a intervalos de muestreo 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 

Las tres primeras líneas de la salida constituyen el primer informe, que contiene el límite y la información del proyecto para los dos proyectos y las estadísticas de paginación desde el inicio de rcapd. Las columnas at y pg tienen un número mayor que cero para user1 y cero para user2, lo que indica que en algún punto del historial del daemon user1 ha superado su límite pero user2 no lo ha hecho.

Los informes subsiguientes no muestran ninguna actividad significativa.

Supervisón del RSS de un proyecto

En el ejemplo siguiente se muestra el user1 del proyecto, que fue un RSS que superó su límite.

El comando siguiente produce cinco informes a intervalos de muestreo 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

El proyecto user1 tiene tres procesos que utilizan activamente la memoria física. Los valores positivos de la columna pg indican que rcapd está extrayendo de forma coherente la memoria al intentar alcanzar el límite bajando el uso de la memoria física de los procesos del proyecto. Sin embargo, rcapd no consigue mantener el RSS por debajo del valor límite. Esto se indica mediante los valores rss variables que no muestran una disminución correspondiente. En cuanto se extrae la memoria, la carga de trabajo vuelve a utilizarla y el número de RSS vuelve a subir. Esto significa que toda la memoria residente del proyecto se está utilizando de forma activa y el tamaño del conjunto de trabajo (WSS) es superior al límite. De este modo, rcapd fuerza la extracción de parte del conjunto de trabajo para cumplir el límite. Con esta condición, el sistema seguirá experimentando altos índices de fallos de paginación y la E/S asociada, hasta que tenga lugar una de las condiciones siguientes:

• Se reduzca el WSS.

• Se aumente el límite.

• La aplicación cambie su patrón de acceso a la memoria.

En esta situación, la reducción del intervalo de muestreo podría disminuir la discrepancia entre el valor de RSS y el límite al hacer que rcapd muestree la carga de trabajo y aplique los límites con mayor frecuencia.

Se produce un fallo de página cuando debe crearse una página o el sistema debe copiar una página desde un dispositivo de intercambio.

Cómo determinar el tamaño del conjunto de trabajo de un proyecto

El ejemplo siguiente es una continuación del anterior, y utiliza el mismo proyecto.

El ejemplo anterior muestra que el proyecto user1 está utilizando más memoria física de lo que permite su límite. Este ejemplo muestra cuánta memoria requiere la carga de trabajo del proyecto.

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

A mitad del ciclo, el límite del proyecto user1 se aumenta de 6 a 10 gigabytes. Este aumento detiene la aplicación del límite y permite el aumento del tamaño del conjunto residente, limitado sólo por los demás procesos y la cantidad de memoria del equipo. La columna rss podría estabilizarse para reflejar el tamaño del conjunto de trabajo del proyecto (WSS), en este caso 6247M. Se trata del valor de límite mínimo que permite que los procesos del proyecto funcionen sin incurrir en fallos de página continuos.

Mientras que el límite de user1 es de 6 s, en cada intervalo de 5 segundos el RSS disminuye y la E/S aumenta mientras rcapd extrae parte de la memoria de la carga de trabajo. Un poco después de completar la extracción, la carga de trabajo, que necesita dichas páginas, las vuelve a insertar mientras sigue ejecutándose. Este ciclo se repite hasta que se eleva el límite a 10 gigabytes, aproximadamente por la mitad del ejemplo. El RSS se estabiliza en 6,1 gigabytes. Dado que el RSS de la carga de trabajo está ahora por debajo del límite, no se produce ninguna paginación adicional. También se detiene la E/S asociada con la paginación. De este modo, el proyecto necesita 6,1 gigabytes para llevar a cabo el trabajo que estaba realizando en el momento en que se observó.

Consulte también las páginas del comando man vmstat(1M) y iostat(1M).

Informes del uso de la memoria y el umbral de aplicación del límite de la memoria

La opción -g de rcapstat permite registrar lo siguiente:

• Uso actual de la memoria física como porcentaje de la memoria física instalada en el sistema

• Umbral de aplicación del límite de memoria del sistema definido por rcapadm

La opción -g imprime una línea de aplicación del límite y el uso de la memoria al final del informe para 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 Agrupaciones de recursos (descripción general)

Este capítulo abarca las siguientes funciones:

• Agrupaciones de recursos, que se utilizan para particionar los recursos del equipo

• Agrupaciones de recursos dinámicos (DRP), que ajustan de forma dinámica la asignación de recursos de cada agrupación de recursos para cumplir los objetivos del sistema

A partir de la versión Solaris 10 11/06, las agrupaciones de recursos y las agrupaciones de recursos dinámicos son servicios de la Utilidad de gestión de servicios (SMF) de Solaris. Cada uno de estos servicios se activa por separado.

En este capítulo, se describen los siguientes temas:

• Introducción a las agrupaciones de recursos

• Introducción a las agrupaciones de recursos dinámicos

• Activación y desactivación de agrupaciones de recursos y agrupaciones de recursos dinámicos

• Agrupaciones de recursos utilizadas en zonas

• Cuándo se utilizan las agrupaciones

• Estructura de agrupaciones de recursos

• Implementación de agrupaciones en un sistema

• Atributo project.pool

• SPARC: Agrupaciones de recursos y operaciones de reconfiguración dinámica

• Creación de configuraciones de agrupaciones

• Manipulación directa de la configuración dinámica

• Descripción general de poold

• Administración de agrupaciones de recursos dinámicos

• Objetivos y restricciones de configuración

• Funciones de poold que pueden configurarse

• Cómo funciona la asignación de recursos dinámicos

• Uso de poolstat para supervisar la función de agrupaciones y el uso de los recursos

• Comandos utilizados con la función de agrupaciones de recursos

Para conocer los procedimientos para usar esta función, consulte el Capítulo 13Creación y administración de agrupaciones de recursos (tareas).

Novedades de las agrupaciones de recursos y las agrupaciones de recursos dinámicos

Solaris 10: las agrupaciones de recursos proporcionan ahora un mecanismo para ajustar la asignación de recursos de cada agrupación como respuesta a los eventos del sistema y los cambios de carga de la aplicación. Las agrupaciones de recursos dinámicos simplifican y reducen el número de decisiones que debe tomar un administrador. Se realizan ajustes automáticamente para mantener los objetivos de rendimiento del sistema que especifica un administrador.

Ahora puede utilizar el comando projmod para definir el atributo project.pool en el archivo /etc/project.

Para ver una lista completa de las nuevas funciones de Solaris 10 y una descripción de las versiones de Solaris, consulte Novedades de Oracle Solaris 10 9/10.

Solaris 10 11/06: Las agrupaciones de recursos y las agrupaciones de recursos dinámicos son ahora servicios SMF.

Introducción a las agrupaciones de recursos

Las agrupaciones de recursos permiten separar cargas de trabajo para que el consumo de carga de trabajo de determinados recursos no se superponga. Esta reserva de los recursos permite obtener un rendimiento predecible en los sistemas con cargas de trabajo mixtas.

Las agrupaciones de recursos proporcionan un mecanismo de configuración persistente para la configuración del conjunto de procesadores (pset) y, opcionalmente, la planificación de la asignación de clases.

Figura 12–1 Estructura de la agrupación de recursos

Una agrupación puede considerarse una vinculación específica de los diferentes conjuntos de recursos que están disponibles en el sistema. Puede crear agrupaciones que representen diferentes tipos de combinaciones de recursos posibles:

Al agrupar varias particiones, las agrupaciones pueden asociarse con las cargas de trabajo etiquetadas. Cada entrada de proyecto del archivo /etc/project puede tener asociada una única agrupación, que se especifica mediante el atributo project.pool.

Si las agrupaciones están activas, la configuración básica se establece mediante una agrupación predeterminada y un conjunto de procesadores predeterminado. Pueden crearse y añadirse a la configuración agrupaciones definidas por el usuario y conjuntos de procesadores adicionales. Una CPU sólo puede pertenecer a un conjunto de procesadores. Los conjuntos de procesadores y agrupaciones definidas por el usuario se pueden destruir. El conjunto de procesadores y la agrupación que se han configurado de forma predeterminada no se pueden destruir.

La agrupación predeterminada tiene la propiedad pool.default configurada como true. El conjunto de procesadores tiene la propiedad pset.default configurada como true. De este modo, pueden identificarse tanto la agrupación como el conjunto de procesadores predeterminados aunque sus nombres hayan cambiado.

El mecanismo de agrupaciones definidas por el usuario se utiliza principalmente en grandes equipos con más de una CPU. Sin embargo, los equipos pequeños también pueden aprovechar esta función. En el caso de los equipos pequeños, puede crear agrupaciones que compartan particiones de recursos no críticos. Las agrupaciones sólo se separan basándose en los recursos críticos.

Introducción a las agrupaciones de recursos dinámicos

Las agrupaciones de recursos dinámicos proporcionan un mecanismo para ajustar dinámicamente la asignación de recursos de cada agrupación como respuesta a los eventos del sistema y los cambios de carga de la aplicación. Las DRP simplifican y reducen el número de decisiones que debe tomar un administrador. Se realizan ajustes automáticamente para mantener los objetivos de rendimiento del sistema que especifica un administrador. Los cambios realizados en la configuración se registran. Estas funciones se realizan principalmente a través del controlador de recursos poold, un daemon de sistema que siempre debería estar activo si se requiere la asignación de recursos dinámicos. De forma periódica, poold examina la carga en el sistema y determina si se requiere una intervención para permitir que el sistema mantenga un rendimiento óptimo en lo que se refiere al consumo de recursos. La configuración de poold se realiza en la configuración de libpool. Para obtener más información sobre poold, consulte la página del comando man poold(1M).

Activación y desactivación de agrupaciones de recursos y agrupaciones de recursos dinámicos

Para activar y desactivar las agrupaciones de recursos y agrupaciones de recursos dinámicos, consulte Activación y desactivación de la función de agrupaciones.

Agrupaciones de recursos utilizadas en zonas

Solaris 10 8/07: Como alternativa a la asociación de una zona con una agrupación de recursos del sistema, puede utilizar el comando zonecfg para crear una agrupación temporal vigente mientras se ejecuta la zona. Consulte Solaris 10 8/07: recurso dedicated-cpu para obtener más información.

En un sistema con zonas activas, puede asociarse una zona no global con una agrupación de recursos, aunque no es necesario que la agrupación esté asignada exclusivamente a una zona concreta. Asimismo, no puede vincular procesos individuales en zonas no globales a una agrupación diferente utilizando el comando poolbind desde la zona global. Para asociar una zona no global con una agrupación, consulte Configuración, verificación y confirmación de una zona.

Observe que si configura una clase de programación para una agrupación y asocia una zona no global con dicha agrupación, la zona utiliza dicha clase de planificación de forma predeterminada.

Si utiliza agrupaciones de recursos dinámicos, el ámbito de una instancia de poold en ejecución se limita a la zona global.

Si la utilidad poolstat se ejecuta en una zona no global muestra sólo información sobre la agrupación asociada con la zona. El comando pooladm ejecutado sin argumentos en una zona no global muestra sólo información sobre la agrupación asociada con la zona.

Para obtener información sobre los comandos de agrupaciones de recursos, consulte Comandos utilizados con la función de agrupaciones de recursos.

Cuándo se utilizan las agrupaciones

Las agrupaciones de recursos ofrecen un mecanismo versátil que se puede aplicar a múltiples situaciones administrativas.

Servidor de cálculo por lotes

Utilice la función de agrupaciones para dividir un servidor en dos agrupaciones. Se utiliza una agrupación para las sesiones de inicio de sesión y el trabajo interactivo de los usuarios que comparten el tiempo. La otra agrupación se utiliza para los trabajos que se envían a través del sistema por lotes.

Servidor de base de datos o aplicación

Particione los recursos de las aplicaciones interactivas de acuerdo con los requisitos de las aplicaciones.

Activación de las aplicaciones por fases

Defina las expectativas del usuario.

Puede implementar inicialmente un equipo que ejecute sólo una fracción de los servicios que se espera que la máquina ofrezca en último término. El usuario puede tener dificultades si no se establecen mecanismos de administración de los recursos basados en las reservas cuando el equipo está en línea.

Por ejemplo, el programador de reparto justo optimiza el uso de la CPU. Los tiempos de respuesta de un equipo en el que sólo se ejecuta una aplicación pueden ser rápidos de manera equívoca. Los usuarios no verán estos tiempos de respuesta con varias aplicaciones cargadas. Al utilizar diferentes agrupaciones para cada aplicación, puede colocar un máximo para el número de CPU disponibles para cada aplicación antes de implementar todas las aplicaciones.

Servidor de tiempo compartido complejo

Particione un servidor que admite grandes cantidades de usuarios. La partición del servidor proporciona un mecanismo de aislamiento que conduce a una respuesta por usuario más predecible.

Al dividir a los usuarios en grupos que se vinculan a agrupaciones diferentes, y utilizar el programador de reparto justo (FSS), puede configurar las asignaciones de CPU para favorecer a los conjuntos de usuarios que tengan prioridad. Esta asignación puede basarse en el rol del usuario, el contracargo, etc.

Cargas de trabajo que cambian temporalmente

Utilice agrupaciones de recursos para adaptarse a las variaciones en la demanda.

El sitio puede experimentar cambios predecibles en la demanda de carga de trabajo durante largos períodos de tiempo, por ejemplo cada mes, cada trimestre o cada año. Si su sitio experimenta dichos cambios, puede alternar entre varias configuraciones de agrupaciones invocando pooladm desde un trabajo cron. (Consulte Estructura de agrupaciones de recursos.)

Aplicaciones en tiempo real

Cree una agrupación en tiempo real utilizando el programador RT y recursos de procesador designados.

Uso del sistema

Aplique los objetivos del sistema que establezca.

Utilice la función de daemon de agrupaciones automatizadas para identificar los recursos disponibles y luego supervisar las cargas de trabajo con el fin de detectar el momento en que dejan de cumplirse los objetivos especificados. El daemon puede emprender la acción correctiva, si es posible, o puede registrarse la condición.

Estructura de agrupaciones de recursos

El archivo de configuración /etc/pooladm.conf describe la configuración de las agrupaciones estáticas. Una configuración estática representa el modo en que un administrador desea configurar un sistema con respecto a la funcionalidad de las agrupaciones de recursos. Puede especificarse un nombre de archivo alternativo.

Cuando se utiliza el comando pooladm - e o la Utilidad de gestión de servicios (SMF) para activar la estructura de agrupaciones de recursos, si existe un archivo /etc/pooladm.conf, la configuración que contiene el archivo se aplica al sistema.

El kernel contiene información sobre la disposición de los recursos en la estructura de las agrupaciones de recursos. Esto se conoce como configuración dinámica, y representa la función de agrupaciones de recursos para un sistema concreto en un determinado momento. La configuración dinámica puede visualizarse con el comando pooladm. Tenga en cuenta que el orden en el que se muestran las propiedades para las agrupaciones y conjuntos de recursos puede variar. Las modificaciones en la configuración dinámica se realizan de los siguientes modos:

• Indirectamente, aplicando un archivo de configuración estática

• Directamente, utilizando el comando poolcfg con la opción -d

Puede haber más de un archivo de configuración de agrupaciones estáticas, para su activación en diferentes momentos. Puede alternar entre múltiples configuraciones de agrupaciones invocando pooladm desde un trabajo cron. Consulte la página del comando man cron(1M) para obtener más información sobre la utilidad cron.

De modo predeterminado, la estructura de las agrupaciones de recursos no está activa. Las agrupaciones de recursos deben activarse para crear o modificar la configuración dinámica. Los archivos de configuración estática pueden manipularse con los comandos poolcfg o libpool aunque la estructura de las agrupaciones de recursos esté desactivada. Los archivos de configuración estática no se pueden crear si no está activa la función de agrupaciones. Para obtener más información sobre el archivo de configuración, consulte Creación de configuraciones de agrupaciones.

Los comandos utilizados con las agrupaciones de recursos y el daemon de sistema poold se describen en las siguientes páginas del comando man:

• pooladm(1M)

• poolbind(1M)

• poolcfg(1M)

• poold(1M)

• poolstat(1M)

• libpool(3LIB)

Contenido de /etc/pooladm.conf

Todas las configuraciones de agrupaciones de recursos, incluida la configuración dinámica, pueden contener los elementos siguientes.

system

Propiedades que afectan al comportamiento global del sistema

agrupación

Definición de una agrupación de recursos

pset

Definición de un conjunto de procesadores

cpu

Definición de un procesador

Todos estos elementos tienen propiedades que se pueden modificar para cambiar el comportamiento de la estructura de las agrupaciones de recursos. Por ejemplo, la propiedad de agrupación pool.importance indica la importancia relativa de una agrupación concreta. Esta propiedad se utiliza para la posible resolución de conflictos relativos a los recursos. Para obtener más información, consulte libpool(3LIB).

Propiedades de agrupaciones

La utilidad de agrupaciones admite propiedades con nombre escritas que se pueden colocar en una agrupación, un recurso o un componente. Los administradores pueden almacenar propiedades adicionales en los distintos elementos de la agrupación. Se utiliza un espacio de nombre de propiedad similar al atributo del proyecto.

Por ejemplo, el siguiente comentario indica que se asocia un pset concreto con una base de datos Datatree específica.

Datatree,pset.dbname=warehouse

Para obtener más información sobre los tipos de propiedades, consulte Propiedades de poold.

Se ha reservado una serie de propiedades especiales para uso interno y no se pueden configurar ni eliminar. Consulte la página del comando man libpool(3LIB) para obtener más información.

Implementación de agrupaciones en un sistema

Pueden implementarse agrupaciones definidas por el usuario en un sistema utilizando uno de los métodos siguientes.

• Cuando se inicia el software de Solaris, una secuencia init comprueba si existe el archivo /etc/pooladm.conf. Si se encuentra el archivo y las agrupaciones están activas, se invoca pooladm para activar esta configuración de agrupaciones. El sistema crea una configuración dinámica para reflejar la organización que se solicita en /etc/pooladm.conf, y los recursos del equipo se particionan en consonancia.

• Cuando el sistema Solaris está en ejecución, puede activar una configuración de agrupaciones si no está presente todavía, o modificarla utilizando el comando pooladm. De modo predeterminado, el comando pooladm funciona en /etc/pooladm.conf. Sin embargo, de forma opcional puede especificar una ubicación y un nombre de archivo alternativos, y utilizar dicho archivo para actualizar la configuración de las agrupaciones.

Para obtener información sobre la activación y desactivación de agrupaciones de recursos, consulte Activación y desactivación de la función de agrupaciones. La función de agrupaciones no puede desactivarse cuando se están utilizando agrupaciones o recursos definidos por el usuario.

Para configurar las agrupaciones de recursos, debe tener privilegios de superusuario o el perfil de administración de procesos en la lista de perfiles. El rol de administrador del sistema incluye el perfil de administración de procesos.

El controlador de recursos poold se inicia con la función de agrupación de recursos dinámicos.

Atributo project.pool

Puede añadirse el atributo project.pool a una entrada de proyecto del archivo /etc/project para asociar una única agrupación con dicha entrada. Los nuevos trabajos que se inicien en un proyecto estarán vinculados a la agrupación adecuada. Consulte el Capítulo 2Proyectos y tareas (información general) para obtener más información.

Por ejemplo, puede utilizar el comando projmod para definir el atributo project.pool para el proyecto sales en el archivo /etc/project:

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

SPARC: Agrupaciones de recursos y operaciones de reconfiguración dinámica

La reconfiguración dinámica (DR) permite reconfigurar el hardware mientras se ejecuta el sistema. Una operación de DR puede aumentar, reducir o no tener ningún efecto sobre un tipo de recurso específico. Dado que la DR puede afectar a las cantidades de recursos disponibles, la función de agrupaciones debe incluirse en estas operaciones. Cuando se inicia una operación de DR, la estructura de las agrupaciones actúa para validar la configuración.

Si el funcionamiento de DR puede continuar sin que la configuración de las agrupaciones actuales deje de ser válida, se actualiza el archivo de configuración privado. Un archivo de configuración no válido es aquél que no admiten los recursos disponibles.

Si el funcionamiento de DR hace que la configuración de las agrupaciones deje de ser válida, se producirá un error y se notificará mediante un mensaje en el registro de mensajes. Si desea forzar la finalización de la configuración, debe utilizar la opción de forzado de DR. La configuración de las agrupaciones se modifica para cumplir la nueva configuración del recurso. Para obtener información sobre el proceso de DR y la opción de forzado, consulte la guía del usuario sobre reconfiguración dinámica para el hardware de Sun.

Si utiliza agrupaciones de recursos dinámicas, tenga en cuenta que es posible que una partición quede fuera del control de poold mientras el daemon está activo. Para más información, consulte Identificación de recursos insuficientes.

Creación de configuraciones de agrupaciones

El archivo de configuración contiene una descripción de las agrupaciones que se crearán en el sistema. El archivo describe los elementos que se pueden manipular.

• Sun StorageTek 5320

• pool

• pset

• cpu

Consulte poolcfg(1M) para obtener más información sobre los elementos que se manipulan.

Si las agrupaciones están activadas, puede crear un archivo /etc/pooladm.conf estructurado de dos modos.

• Puede utilizar el comando pooladm con la opción - s para conocer los recursos del sistema actual y colocar los resultados en un archivo de configuración.

  Se recomienda utilizar este método. Se registran todos los recursos y componentes del sistema que pueden manipular las agrupaciones. Los recursos incluyen las configuraciones de conjuntos de procesadores existentes. Puede modificar la configuración para cambiar el nombre de los conjuntos de procesadores o crear agrupaciones adicionales si es preciso.

• Puede utilizar el comando poolcfg con la opción - c y los subcomandos discover o create system nombre para crear una nueva configuración de las agrupaciones.

  Estas opciones se mantienen para la compatibilidad hacia atrás con versiones anteriores.

Utilice poolcfg o libpool para modificar el archivo /etc/pooladm.conf. No edite directamente este archivo.

Manipulación directa de la configuración dinámica

Los tipos de recursos de la CPU de la configuración dinámica se pueden manipular directamente utilizando el comando poolcfg con la opción -d. Existen dos métodos para transferir los recursos.

• Puede realizar una solicitud general para transferir cualquier recurso identificado disponible de un conjunto a otro.

• Puede transferir recursos con ID específicos a un conjunto de destino. Observe que los ID de sistema asociados con los recursos pueden cambiar cuando se modifica la configuración de los recursos o después de reiniciar el sistema.

Por ejemplo, consulte Transferencia de recursos.

Tenga en cuenta que la transferencia de recursos podría desencadenar una acción de poold. Consulte Descripción general de poold para obtener más información.

Descripción general de poold

El controlador de recursos de las agrupaciones, poold, utiliza objetivos del sistema y estadísticas observables para mantener los objetivos de rendimiento del sistema que especifique. El daemon del sistema siempre debe estar activo cuando se requiere la asignación de recursos dinámica.

El controlador de recursos poold identifica los recursos disponibles y luego supervisa las cargas de trabajo con el fin de determinar cuándo dejan de cumplirse los objetivos de uso del sistema. poold considera configuraciones alternativas en términos de objetivos y emprende las acciones correctivas oportunas. Si es posible, los recursos se vuelven a configurar para poder cumplir los objetivos. Si no se pueden emprender las acciones correctivas, el daemon registra que no se pueden seguir cumpliendo los objetivos especificados por el usuario. Tras una reconfiguración, el daemon reanuda la supervisión de los objetivos de la carga de trabajo.

poold mantiene un historial de las decisiones que puede consultar. El historial de decisiones permite eliminar las reconfiguraciones que no conllevan mejoras.

Tenga en cuenta que también se puede desencadenar una reconfiguración de forma asíncrona si se modifican los objetivos de la carga de trabajo o los recursos disponibles para el sistema.

Administración de agrupaciones de recursos dinámicos

El servicio de agrupaciones de recursos dinámicos lo administra la Utilidad de gestión de servicios (SMF) con el identificador de servicio svc:/system/pools/dynamic.

Las acciones administrativas de este servicio, como la activación, la desactivación o la solicitud de reinicio, pueden llevarse a cabo con el comando svcadm. El comando svcs permite consultar el estado del servicio. Consulte las páginas del comando man svcs(1) y svcadm(1M) para obtener más información.

La interfaz de SMF es el método recomendado para controlar las agrupaciones de recursos dinámicos, pero también se siguen otros métodos para conseguir compatibilidad con versiones anteriores.

• Si no se requiere la asignación de recursos dinámicos, poold puede detenerse con las señales SIGQUIT o SIGTERM. Estas dos señales hacen que poold termine correctamente.

• Aunque poold detecte automáticamente los cambios en la configuración de recursos o agrupaciones, también puede forzar una reconfiguración utilizando la señal SIGHUP.

Objetivos y restricciones de configuración

Al realizar cambios en una configuración, poold actúa en las indicaciones que proporciona. Estas indicaciones se especifican como una serie de objetivos y restricciones. poold utiliza las especificaciones para determinar el valor relativo de las diferentes posibilidades de configuración en relación con la configuración existente. poold luego cambia las asignaciones de recursos de la configuración actual para generar nuevas configuraciones candidatas.

Restricciones de la configuración

Las restricciones afectan al intervalo de posibles configuraciones al eliminar algunos de los posibles cambios que pueden realizarse en una configuración. Están disponibles las siguientes restricciones, que se especifican en la configuración de libpool.

• Las asignaciones de CPU mínima y máxima

• Los componentes asociados que no están disponibles para moverlos desde un conjunto

Consulte la página del comando man libpool(3LIB) y Propiedades de agrupaciones para obtener más información sobre las propiedades de las agrupaciones.

Propiedad pset.min y restricciones de la propiedad pset.max

Estas dos propiedades establecen los límites para la cantidad de procesadores que se pueden asignar a un conjunto, tanto el máximo como el mínimo. Consulte la Tabla 12–1 para obtener más información sobre estas propiedades.

Dentro de estas restricciones, los recursos de la partición están disponibles para su asignación a otras particiones de recursos de la misma instancia de Solaris. El acceso al recurso se obtiene vinculando una agrupación asociada con el conjunto de recursos. La vinculación se lleva a cabo durante el inicio de sesión o la realiza manualmente un administrador que tenga el privilegio PRIV_SYS_RES_CONFIG.

Restricción de la propiedad cpu.pinned

La propiedad cpu-pinned indica que las asignaciones de recursos dinámicos no deben mover una CPU específica del conjunto de procesadores en el que se encuentra. Puede configurar esta propiedad libpool para maximizar el uso de caché para una aplicación específica que se ejecuta dentro de un conjunto de procesadores.

Consulte la Tabla 12–1 para obtener más información sobre esta propiedad.

Restricción de la propiedad pool.importance

La propiedad pool.importance describe la importancia relativa de una agrupación según lo establecido por el administrador.

Objetivos de la configuración

Los objetivos se especifican de un modo similar a las restricciones. El conjunto completo de objetivos se describe en la Tabla 12–1.

Existen dos categorías de objetivos.

Dependientes de la carga de trabajo

Un objetivo dependiente de la carga de trabajo es un objetivo que varía según la naturaleza de la carga de trabajo que se ejecuta en el sistema. Un ejemplo es el objetivo de utilization. La cifra de utilización de un conjunto de recursos varía según la naturaleza de la carga de trabajo que hay activa en el conjunto.

Independientes de la carga de trabajo

Un objetivo independiente de la carga de trabajo es un objetivo que no varía según la naturaleza de la carga de trabajo que se ejecuta en el sistema. Un ejemplo es el objetivo de locality de la CPU. La medida de localidad evaluada para un conjunto de recursos no varía según la naturaleza de la carga de trabajo que está activa en el conjunto.

Puede definir tres tipos de objetivos.

Los objetivos se almacenan en las cadenas de propiedad de la configuración de libpool. Los nombres de propiedad son los siguientes:

• system.poold.objectives

• pset.poold.objectives

Los objetivos tienen la siguiente sintaxis:

• objectives = objective [; objective]*

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

Todos los objetivos adoptan un prefijo de importancia opcional. La importancia actúa como multiplicador del objetivo y, por tanto, aumenta el significado de su contribución a la evaluación de la función de objetivos. El valor puede estar entre 0 y INT64_MAX (9223372036854775807). Si no se especifica, el valor predeterminado de importancia es de 1.

Algunos tipos de elementos admiten más de un tipo de objetivo. Un ejemplo es pset. Puede especificar varios tipos de objetivos para estos elementos. También puede especificar varios objetivos de utilización en un único elemento pset.

Consulte Cómo definir los objetivos de configuración para ver algunos ejemplos de uso.

Objetivo de wt-load

El objetivo de wt-load favorece configuraciones que asocian asignaciones de recursos con utilizaciones de recursos. A un conjunto de recursos que utiliza más recursos se le asignan más recursos cuando este objetivo está activo. wt-load significa carga ponderada.

Este objetivo se utiliza cuando se está conforme con las restricciones que se han establecido utilizando las propiedades mínima y máxima, y se desea que el daemon manipule los recursos libremente dentro de dichas restricciones.

El objetivo locality

El objetivo locality influye en el impacto que tiene la localidad, medida por los datos de grupo de localidad (lgroup), en la configuración seleccionada. La latencia es otro modo de definir la localidad. lgroup describe los recursos de memoria y CPU. El sistema Solaris utiliza lgroup para determinar la distancia entre recursos, y el tiempo como medición. Para obtener más información sobre la abstracción del grupo de localidad, consulte Locality Groups Overview de Programming Interfaces Guide.

Este objetivo puede adoptar uno de los tres valores siguientes:

tight

Si se configura, se favorecen las configuraciones que maximizan la localidad de los recursos.

loose

Si se configura, se favorecen las configuraciones que minimizan la localidad de los recursos.

none

Si se configura, no se favorece ninguna configuración basándose en la localidad de los recursos. Se trata del valor predeterminado para el objetivo locality.

En general, el objetivo locality debe configurarse como tight. Sin embargo, para maximizar el ancho de banda de la memoria o minimizar el impacto de las operaciones de recursos dinámicos en un conjunto de recursos, puede configurar este objetivo como loose o dejar la configuración predeterminada de none.

Objetivo utilization

El objetivo utilization favorece configuraciones que asignan recursos a particiones que no cumplen el objetivo de utilización especificado.

Este objetivo se especifica utilizando operadores y valores. Los operadores son los siguientes:

<

El operador "menor que" indica que el valor especificado representa un valor de destino máximo.

>

El operador "mayor que" indica que el valor especificado representa un valor de destino mínimo.

~

El operador "similar" indica que el valor especificado es un valor de destino para el que se acepta cierta fluctuación.

Pset sólo puede tener configurado un objetivo de utilización para cada tipo de operador.

• Si se configura el operador ~, no es posible configurar los operadores < y >.

• Si se configuran los operadores < y >, no es posible configurar el operador ~. Tenga en cuenta que la configuración de los operadores < y > no puede contradecirse.

Puede definir los operadores < y > a la vez para crear un intervalo. Los valores se validarán para asegurarse de que no se solapen.

Ejemplo de objetivos de configuración

En el ejemplo siguiente, poold evaluará estos objetivos para pset:

• El valor de utilization debe estar entre 30 y 80 por ciento.

• El valor de locality debe maximizarse para el conjunto de procesadores.

• Los objetivos deben adoptar la importancia predeterminada de 1.

Ejemplo 12–1 Ejemplo de objetivos de poold

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

Consulte Cómo definir los objetivos de configuración para ver algunos ejemplos de uso adicionales.

Propiedades de poold

Hay cuatro categorías de propiedades:

• Configuración

• Restricción

• Objetivo

• Parámetro de objetivo

Funciones de poold que pueden configurarse

Puede configurar estos aspectos del comportamiento del daemon.

• Intervalo de supervisión

• Nivel de registro

• Ubicación de registro

Estas opciones se especifican en la configuración de las agrupaciones. También puede controlar el nivel de registro de la línea de comandos invocando poold.

Intervalo de supervisión de poold

Utilice el nombre de propiedad system.poold.monitor-interval para especificar un valor en milisegundos.

Información de registro de poold

En el registro se proporcionan tres categorías de información. Estas categorías se identifican en los registros:

• Configuración

• Supervisión

• Optimización

Utilice el nombre de propiedad system.poold.log-level para especificar el parámetro de registro. Si no se especifica esta propiedad, el nivel de registro predeterminado es NOTICE. Los niveles de parámetros son jerárquicos. La configuración de un nivel de registro de DEBUG causará que poold registre todos los mensajes definidos. El nivel INFO proporciona un equilibrio útil de la información para la mayoría de los administradores.

En la línea de comandos, puede utilizar el comando poold con la opción -l y un parámetro para especificar el nivel de información de registro generada.

Hay disponibles los siguientes parámetros:

• ALERT

• CRIT

• ERR

• WARNING

• NOTICE

• INFO

• DEBUG

Los niveles de parámetros se asignan directamente a sus equivalentes de syslog. Consulte Ubicación de registro para más información sobre el uso de syslog.

Para obtener más información sobre cómo configurar el registro de poold, consulte Cómo establecer el nivel de registro de poold.

Registro de información de configuración

Pueden generarse los siguientes tipos de mensajes:

ALERT

Indica problemas para acceder a la configuración de libpool u otro error importante no previsto de la función libpool. Cierra el daemon y requiere una acción inmediata por parte del administrador.

CRIT

Problemas debidos a errores no previstos. Cierra el daemon y requiere una acción inmediata por parte del administrador.

ERR

Indica problemas con los parámetros especificados por el usuario que controlan el funcionamiento, como objetivos de utilización conflictivos que no se pueden resolver para un conjunto de recursos. Requiere la intervención del administrador para corregir los objetivos. poold intenta emprender las acciones correctivas omitiendo los objetivos conflictivos, pero algunos errores hacen que se cierre el daemon.

WARNING

Advertencias relativas a la configuración de parámetros que, aunque son técnicamente correctos, podrían no ser adecuados para el entorno de ejecución específico. Un ejemplo es marcar todos los recursos de la CPU como asociados, lo que significa que poold no puede mover los recursos de la CPU entre conjuntos de procesadores.

DEBUG

Mensajes que contienen la información detallada que se necesita al depurar el procesamiento de la configuración. Normalmente esta información no la utilizan los administradores.

Supervisión del registro de información

Pueden generarse los siguientes tipos de mensajes:

CRIT

Problemas debidos a fallos de supervisión no previstos. Cierra el daemon y requiere una acción inmediata por parte del administrador.

ERR

Problemas debidos a un error de supervisión no previsto. Podrían requerir una acción correctiva por parte del administrador.

NOTICE

Mensajes sobre las transiciones de regiones de control de recursos.

INFO

Mensajes sobre las estadísticas de uso de los recursos.

DEBUG

Mensajes que contienen la información detallada que se necesita al depurar el procesamiento de supervisión. Normalmente esta información no la utilizan los administradores.

Registro de información de optimización

Pueden generarse los siguientes tipos de mensajes:

WARNING

Podrían aparecer mensajes sobre problemas a la hora de tomar las decisiones correctas. Algunos ejemplos podrían incluir conjuntos de recursos demasiado restringidos por sus valores mínimo y máximo o por el número de componentes asociados.

Podrían mostrarse mensajes sobre problemas a la hora de realizar una reasignación óptima a causa de limitaciones imprevistas. Algunos ejemplos podrían conllevar la eliminación del último procesador del conjunto de procesadores que contiene un consumidor de recursos vinculado.

NOTICE

Mensajes sobre configuraciones utilizables o configuraciones que no se implementarán porque podrían solaparse los historiales de decisiones.

INFO

Mensajes sobre configuraciones alternativas que se toman en consideración.

DEBUG

Mensajes que contienen la información detallada que se necesita al depurar el procesamiento de optimización. Normalmente esta información no la utilizan los administradores.

Ubicación de registro

La propiedad system.poold.log-location se utiliza para especificar la ubicación de la salida registrada de poold. Puede especificar una ubicación de SYSLOG para la salida de poold (consulte syslog(3C)).

Si no se especifica esta propiedad, la ubicación predeterminada de la salida registrada de poold es /var/log/pool/poold.

Esta propiedad no se utiliza cuando se invoca poold desde la línea de comandos. Se escriben entradas de registro en stderr en el terminal que ejecuta el comando.

Administración de registros con logadm

Si poold está activo, el archivo logadm.conf incluye una entrada para administrar el archivo predeterminado /var/log/pool/poold. La entrada es:

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

Consulte las páginas del comando man logadm(1M) y logadm.conf(4).

Cómo funciona la asignación de recursos dinámicos

En esta sección se describe el proceso y los factores que utiliza poold para asignar recursos dinámicamente.

Acerca de los recursos disponibles

Los recursos disponibles se consideran todos los recursos disponibles para utilizar en el ámbito del proceso poold. El ámbito de control es como máximo una única instancia de Solaris.

En un sistema con zonas activas, el ámbito de una instancia de ejecución de poold está limitado a la zona global.

Determinación de recursos disponibles

Las agrupaciones de recursos abarcan todos los recursos del sistema que están disponibles para que las aplicaciones los consuman.

Para una única instancia de Solaris en ejecución, debe asignarse un recurso de un único tipo, como una CPU, a una sola partición. Puede haber una o más particiones para cada tipo de recurso. Cada partición contiene un conjunto de recursos único.

Por ejemplo, un equipo con cuatro CPU y dos conjuntos de procesadores puede tener la siguiente configuración:

pset 0: 0 1

pset 1: 2 3

donde 0, 1, 2 y 3 después de los dos puntos representan los ID de CPU. Tenga en cuenta que los dos conjuntos de procesadores representan las cuatro CPU.

El mismo equipo no puede tener la siguiente configuración:

pset 0: 0 1

pset 1: 1 2 3

No puede tener esta configuración porque la CPU 1 no puede aparecer en más de un pset a la vez.

No se puede acceder a los recursos desde una partición que no sea la partición a la que pertenecen.

Para conocer los recursos disponibles, poold interroga la configuración de las agrupaciones activas para buscar las particiones. Se resumen todos los recursos de todas las particiones para determinar la cantidad total de recursos disponibles para cada tipo de recurso que se controla.

Esta cantidad de recursos es la cifra básica que utiliza poold en sus operaciones. Sin embargo, esta cifra tiene restricciones que limitan la flexibilidad que tiene poold para realizar asignaciones. Para obtener información sobre las restricciones disponibles, consulte Restricciones de la configuración.

Identificación de recursos insuficientes

El ámbito de control para poold se define como el conjunto de recursos disponibles para los que poold tiene la responsabilidad principal de la administración y partición eficaces. No obstante, otros mecanismos que tienen permiso para manipular los recursos de este ámbito de control pueden seguir afectando a una configuración. Si debe colocar la partición fuera del control mientras poold está activo, poold intenta restaurar el control mediante la manipulación sensata de los recursos disponibles. Si poold no puede localizar los recursos adicionales dentro de su ámbito, el daemon registra información sobre los recursos insuficientes.

Determinación del uso de recursos

poold dedica la mayor parte del tiempo a observar el uso de los recursos en su ámbito de control. Esta supervisión se lleva a cabo para verificar que se cumplan los objetivos que dependen de la carga de trabajo.

Por ejemplo, para los conjuntos de procesadores, todas las mediciones se realizan en todos los procesadores de un conjunto. El uso de recursos muestra la proporción de tiempo que el recurso está en uso durante el intervalo de ejemplo. El uso del recurso se muestra como un porcentaje de 0 a 100.

Identificación de infracciones del control

Se utilizan las directivas que se describen en Objetivos y restricciones de configuración para detectar el fallo de enfoque de un sistema a la hora de cumplir sus objetivos. Estos objetivos están relacionados directamente con la carga de trabajo.

Una partición que no cumple los objetivos especificados por el usuario es una infracción de control. Los dos tipos de infracciones de control son la infracción síncrona y la infracción asíncrona.

• Una infracción síncrona de un objetivo la detecta el daemon durante la supervisión de su carga de trabajo.

• Una infracción asíncrona de un objetivo tiene lugar independientemente de la acción de supervisión del daemon.

Los siguientes eventos ocasiones infracciones de objetivos asíncronas:

• Se añaden o eliminan recursos de un ámbito de control.

• Se reconfigura el ámbito de control.

• Se reinicia el controlador de recursos poold.

Se da por sentado que las contribuciones de los objetivos que no están relacionados con la carga de trabajo permanecen constantes entre las evaluaciones de la función de objetivos. Los objetivos que no están relacionados con la carga de trabajo sólo se vuelven a evaluar cuando se desencadena una reevaluación mediante una de las infracciones asíncronas.

Determinación de la acción correctiva apropiada

Cuando el controlador de recursos determina que un consumidor de recursos tiene recursos insuficientes, la respuesta inicial es que el aumento de los recursos mejorará el rendimiento.

Se examinan y evalúan configuraciones alternativas que cumplan los objetivos especificados en la configuración para el ámbito de control.

Este proceso se perfecciona con el tiempo a medida que se supervisa el desplazamiento de los recursos y se evalúa la capacidad de respuesta de cada partición de recurso. Se consulta el historial de decisiones para eliminar las reconfiguraciones que no aportaron mejoras para conseguir la función del objetivo. Se utiliza otra información, como nombres de procesos y cantidades, para evaluar todavía más la importancia de los datos históricos.

Si el daemon no puede emprender las acciones correctivas, la condición se registra. Para obtener más información, consulte Información de registro de poold.

Uso de poolstat para supervisar la función de agrupaciones y el uso de los recursos

La utilidad poolstat permite supervisar el uso de los recursos cuando las agrupaciones están activas en el sistema. Esta utilidad examina de forma iterativa todas las agrupaciones activas en un sistema y muestra estadísticas basándose en el modo de salida seleccionado. Las estadísticas de poolstat permiten determinar qué particiones de recursos se utilizan de forma intensiva. Puede analizar estas estadísticas para tomar decisiones sobre la reasignación de recursos cuando el sistema está bajo presión a causa de los recursos.

La utilidad poolstat incluye opciones que se pueden utilizar para examinar agrupaciones específicas y mostrar estadísticas relativas al conjunto de recursos.

Si se implementan zonas en el sistema y utiliza poolstat en una zona no global, se muestra información sobre los recursos asociados con la agrupación de la zona.

Para obtener información adicional sobre la utilidad poolstat, consulte la página del comando man poolstat(1M) Para obtener información sobre la tarea poolstat y su uso, consulte Uso de poolstat para registrar estadísticas para los recursos relacionados con las agrupaciones.

Salida de poolstat

En el formato de salida predeterminado, poolstat crea una línea de cabecera y luego muestra una línea para cada agrupación. Una línea de agrupación empieza con el ID y el nombre de la agrupación, seguido de una columna de datos estadísticos sobre el conjunto de procesadores asociado a la agrupación. Los conjuntos de recursos asociados a más de una agrupación se enumeran varias veces, una para cada agrupación.

Las cabeceras de columnas son:

id

ID de la agrupación.

pool

Nombre de la agrupación.

rid

ID del conjunto de recursos.

rset

Nombre del conjunto de recursos.

type

Tipo del conjunto de recursos.

min

Tamaño mínimo del conjunto de recursos.

max

Tamaño máximo del conjunto de recursos.

size

Tamaño actual del conjunto de recursos.

used

Cantidad del conjunto de recursos que está en uso.

Este uso se calcula como un porcentaje de la utilización del conjunto de recursos multiplicado por el tamaño del conjunto de recursos. Si se ha reconfigurado un recurso durante el último intervalo de muestra, es posible que no se muestre este valor. Un valor no registrado aparece como un guión (-).

load

Representación absoluta de la carga que se coloca en el conjunto de recursos.

Para más información sobre esta propiedad, consulte la página del comando man libpool(3LIB).

Puede especificar lo siguiente en la salida de poolstat:

• El orden de las columnas

• Las cabeceras que aparecen

Ajuste de los intervalos de funcionamiento de poolstat

Puede personalizar las operaciones que lleva a cabo poolstat. Puede configurar el intervalo de muestreo para el informe y especificar el número de veces que se repiten las estadísticas:

intervalo

Ajuste los intervalos para las operaciones periódicas que lleva a cabo poolstat. Todos los intervalos se especifican en segundos.

count

Especifique el número de veces que se repiten las estadísticas. De modo predeterminado, poolstat sólo muestra las estadísticas una vez.

Si no se especifican intervalo ni número, las estadísticas sólo se muestran una vez. Si se especifica intervalo pero no número, las estadísticas se muestran de modo indefinido.

Comandos utilizados con la función de agrupaciones de recursos

Los comandos descritos en la tabla siguiente proporcionan la interfaz administrativa principal para la función de agrupaciones. Para obtener información sobre el uso de estos comandos en un sistema con zonas activadas, consulte Agrupaciones de recursos utilizadas en zonas.

libpool proporciona una API de biblioteca (consulte la página del comando man libpool(3LIB) Los programas pueden utilizar la biblioteca para manipular las configuraciones de agrupaciones.

Capítulo 13 Creación y administración de agrupaciones de recursos (tareas)

En este capítulo se describe cómo configurar y administrar agrupaciones de recursos en el sistema.

Para obtener información esencial sobre las agrupaciones de recursos, consulte el Capítulo 12Agrupaciones de recursos (descripción general).

Administración de agrupaciones de recursos dinámicos (mapa de tareas)

Activación y desactivación de la función de agrupaciones

A partir de Solaris 10 11/06, puede activar y desactivar los servicios de las agrupaciones de recursos y agrupaciones de recursos dinámicos en el sistema utilizando el comando svcadm que se describe en la página del comando man svcadm(1M).

También puede utilizar el comando pooladm descrito en la página del comando man pooladm(1M) para realizar las tareas siguientes:

• Activar la función de agrupaciones para poder manipular las agrupaciones

• Desactivar la función de agrupaciones para que no se puedan manipular las agrupaciones

Cuando se actualiza un sistema, si la estructura de las agrupaciones de recursos está activada y existe el archivo /etc/pooladm.conf, se activa el servicio de agrupaciones y la configuración que contiene el archivo se aplica al sistema.

Solaris 10 11/06 y posteriores: Cómo activar el servicio de agrupaciones de recursos utilizando svcadm

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Active el servicio de agrupaciones de recursos.

   # svcadm enable system/pools:default

Solaris 10 11/06 y posteriores: Cómo desactivar el servicio de agrupaciones de recursos utilizando svcadm

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Desactive el servicio de agrupaciones de recursos.

   # svcadm disable system/pools:default

Solaris 10 11/06 y posteriores: Cómo activar el servicio de agrupaciones de recursos dinámicos utilizando svcadm

1. Conviértase en superusuario o asuma un rol que incluya el perfil de derechos de administración de servicios.

   Las funciones incluyen autorizaciones y comandos con privilegios. Para obtener información sobre cómo crear el rol y asignarlo a un usuario, consulte Configuring RBAC (Task Map) de System Administration Guide: Security ServicesManaging RBAC (Task Map) in System Administration Guide: Security Services.

2. Active el servicio de agrupaciones de recursos dinámicos.

   # svcadm enable system/pools/dynamic:default

Ejemplo 13–1 Dependencia del servicio de agrupaciones de recursos dinámicos del servicio de agrupaciones de recursos

Este ejemplo muestra que primero debe activar las agrupaciones de recursos si desea ejecutar las asignaciones de recursos dinámicos.

Existe una dependencia entre las agrupaciones de recursos y las agrupaciones de recursos dinámicos. La asignación de recursos dinámicos es ahora un servicio dependiente de las agrupaciones de recursos. La asignación de recursos dinámicos puede activarse y desactivarse de forma independiente de las agrupaciones de recursos.

A continuación se muestra que tanto las agrupaciones de recursos como las agrupaciones de recursos dinámicos están desactivadas:

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

Active las agrupaciones 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 el servicio de asignaciones de recursos dinámicos sigue estando desactivado.

Utilice la opción -x del comando svcs para determinar por qué está desconectado el servicio de asignaciones de recursos dinámicos:

# 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.

Active el servicio de agrupaciones de recursos para que se pueda ejecutar el servicio de asignaciones de recursos dinámicos:

# svcadm enable svc:/system/pools:default

Cuando se utiliza el comando svcs *pool*, el sistema muestra:

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

Ejemplo 13–2 Efecto en las agrupaciones de recursos dinámicos cuando el servicio de agrupaciones de recursos está desactivado

Si ambos servicios están activados y desactiva el servicio de agrupaciones de recursos:

# svcadm disable svc:/system/pools:default 

Cuando se utiliza el comando svcs *pool*, el sistema muestra:

# 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

Finalmente, el servicio de asignaciones de recursos dinámicos pasa a offline porque se ha desactivado el servicio de agrupaciones de recursos:

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

Determine por qué está desconectado el servicio de asignaciones de recursos dinámicos:

# 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.

Para que funcionen las asignaciones de recursos dinámicos, es necesario haber iniciado la agrupaciones de recursos. Por ejemplo, para iniciar las agrupaciones de recursos podría utilizarse el comando pooladm con la opción -e:

# pooladm -e

A continuación se muestra el comando svcs *pool*:

# 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 y posteriores: Cómo desactivar el servicio de agrupaciones de recursos dinámicos utilizando svcadm

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Desactive el servicio de agrupaciones de recursos dinámicos.

   # svcadm disable system/pools/dynamic:default

Cómo activar las agrupaciones de recursos utilizando pooladm

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Active la función de agrupaciones.

   # pooladm -e

Cómo desactivar las agrupaciones de recursos utilizando pooladm

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Desactive la función de agrupaciones.

   # pooladm -d

Configuración de agrupaciones

Cómo crear una configuración estática

Utilice la opción -s para /usr/sbin/pooladm con el fin de crear un archivo de configuración estática que coincida con la configuración dinámica actual. A menos que se especifique un nombre de archivo diferente, se utiliza la ubicación predeterminada /etc/pooladm.conf.

Confirme su configuración utilizando el comando pooladm con la opción -c. A continuación, utilice el comando pooladm con la opción -s para actualizar la configuración estática para que coincida con el estado de la configuración dinámica.

La nueva funcionalidad pooladm -s tiene prioridad sobre la funcionalidad anterior poolcfg -c discover a la hora de crear una configuración que coincida con la configuración dinámica.

Antes de empezar

Active las agrupaciones en el sistema.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Actualice el archivo de configuración estática para que coincida con la configuración dinámica actual.

   # pooladm -s

3. Visualice el contenido del archivo de configuración en un formato legible.

   Tenga en cuenta que la configuración contiene elementos predeterminados creados por el 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. Confirme la configuración en /etc/pooladm.conf.

   # pooladm -c

5. (Opcional) Para copiar la configuración dinámica en un archivo de configuración estática denominado /tmp/backup, escriba:

   # pooladm -s /tmp/backup

Cómo modificar una configuración

Para mejorar la configuración, cree un conjunto de procesadores denominado pset_batch y una agrupación denominada pool_batch. A continuación, asocie la agrupación con el conjunto de procesadores.

Tenga en cuenta que debe incluir entre comillas los argumentos de subcomandos que contengan espacios.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Cree el conjunto de procesadores pset_batch.

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

3. Cree la agrupación pool_batch.

   # poolcfg -c 'create pool pool_batch'

4. Asocie la agrupación con el conjunto de procesadores.

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

5. Visualice la configuración 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. Confirme la configuración en /etc/pooladm.conf.

   # pooladm -c

7. (Opcional) Para copiar la configuración dinámica en un archivo de configuración estática denominado /tmp/backup, escriba:

   # pooladm -s /tmp/backup

Cómo asociar una agrupación con una clase de planificación

Puede asociar una agrupación con una clase de planificación para que todos los procesos vinculados a la agrupación utilicen este programador. Para ello, configure la propiedad pool.scheduler con el nombre del programador. Este ejemplo asocia la agrupación pool_batch con el programador de reparto justo (FSS).

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener información sobre cómo crear el rol y asignarlo a un usuario, consulte "Managing RBAC (Task Map)" en System Administration Guide: Security Services.

2. Modifique la agrupación pool_batch que se asociará con FSS.

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

3. Visualice la configuración 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. Confirme la configuración en /etc/pooladm.conf:

   # pooladm -c

5. (Opcional) Para copiar la configuración dinámica en un archivo de configuración estática denominado /tmp/backup, escriba:

   # pooladm -s /tmp/backup

Cómo establecer restricciones de configuración

Las restricciones afectan a las posibles configuraciones al eliminar algunos de los posibles cambios que podrían realizarse en una configuración. Este procedimiento muestra cómo definir la propiedad cpu.pinned.

En los ejemplos siguientes, cpuid es un entero.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Modifique la propiedad cpu.pinned en la configuración estática o dinámica:

   • Modifique la configuración de tiempo de inicio (estática):

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

   • Modifique la configuración en ejecución (dinámica) sin modificar la configuración del tiempo de inicio:

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

Cómo definir los objetivos de configuración

Puede especificar objetivos que debe tener en cuenta poold al llevar a cabo la acción correctiva.

En el procedimiento siguiente, se configura el objetivo wt-load para que poold intente asociar la asignación de recursos con el uso de recursos. El objetivo locality está desactivado para poder alcanzar este objetivo de configuración.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Modifique el sistema tester para favorecer el objetivo wt-load.

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

3. Desactive el objetivo locality para el conjunto de procesadores predeterminado.

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

4. Desactive el objetivo locality para el conjunto de procesadores pset_batch.

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

5. Visualice la configuración 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. Confirme la configuración en /etc/pooladm.conf.

   # pooladm -c

7. (Opcional) Para copiar la configuración dinámica en un archivo de configuración estática denominado /tmp/backup, escriba:

   # pooladm -s /tmp/backup

Cómo establecer el nivel de registro de poold

Para especificar el nivel de información de registro que genera poold, defina la propiedad system.poold.log-level en la configuración de poold. La configuración de poold se realiza en la configuración de libpool. Para obtener mas información, consulte Información de registro de poold y las páginas del comando man poolcfg(1M) y libpool(3LIB).

También puede utilizar el comando poold en la línea de comandos para especificar el nivel de información de registro que genera poold.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Defina el nivel de registro utilizando el comando poold con la opción -l y un parámetro, por ejemplo, INFO.

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

   Para obtener información sobre los parámetros disponibles, consulte Información de registro de poold. El nivel de registro predeterminado es NOTICE.

Cómo utilizar los archivos de comando con poolcfg

El comando poolcfg con la opción -f puede obtener información de un archivo de texto que contenga argumentos de subcomando poolcfg para la opción -c. Este método resulta adecuado si desea establecer las operaciones que se llevarán a cabo. Cuando se procesan varios comandos, la configuración sólo se actualiza si todos los comandos son correctos. En el caso de las configuraciones complejas o de mayor tamaño, esta técnica puede ser más útil que las invocaciones por subcomandos.

Tenga en cuenta que los archivos de comando, el carácter # actúa como marca de comentario para el resto de la línea.

1. Cree el archivo 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. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener información sobre cómo crear el rol y asignarlo a un usuario, consulte "Managing RBAC" en System Administration Guide: Security Services.

3. Ejecute el comando:

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

Transferencia de recursos

Utilice el argumento de subcomando transfer para la opción -c de poolcfg con la opción -d para transferir recursos en el núcleo. La opción -d especifica que el comando actúe directamente en el núcleo y no obtenga información de un archivo.

El siguiente procedimiento mueve dos CPU del conjunto de procesadores pset1 al conjunto de procesadores pset2 del núcleo.

Cómo mover CPU entre conjuntos de procesadores

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Mueva dos CPU de pset1 a pset2.

   Las subcláusulas from y to pueden utilizarse en cualquier orden. Sólo se admite una subcláusula to y from por comando.

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

Ejemplo 13–3 Método alternativo para mover CPU entre conjuntos de procesadores

Si deben transferirse ID conocidos específicos de un tipo de recurso, se proporciona una sintaxis alternativa. Por ejemplo, el siguiente comando asigna dos CPU con los ID 0 y 2 al conjunto de procesadores pset_large:

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

Resolución de problemas

Si falla una transferencia porque no hay suficientes recursos para la solicitud o porque no se puede encontrar los ID especificados, el sistema emitirá un mensaje de error.

Activación y eliminación de configuraciones de agrupaciones

Utilice el comando pooladm para activar una configuración de agrupación concreta o para eliminar la configuración de agrupación activa. Consulte la página del comando man pooladm(1M) para obtener más información sobre este comando.

Cómo activar una configuración de agrupaciones

Para activar la configuración en el archivo de configuración predeterminado, /etc/pooladm.conf, invoque pooladm con la opción -c de confirmación de la configuración.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Confirme la configuración en /etc/pooladm.conf.

   # pooladm -c

3. (Opcional) Copie la configuración dinámica en un archivo de configuración estática, por ejemplo, /tmp/backup.

   # pooladm -s /tmp/backup

Cómo validar una configuración antes de confirmarla

Puede utilizar la opción -n con la opción -c para probar qué ocurrirá cuando tenga lugar la validación. La configuración no se confirmará realmente.

El siguiente comando intenta validar la configuración de /home/admin/newconfig. Se muestra cualquier condición de error, pero no se modifica la configuración.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Pruebe la validez de la configuración antes de confirmarla.

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

Cómo eliminar una configuración de agrupaciones

Para eliminar la configuración activa y devolver su estado predeterminado a todos los recursos asociados, como los conjuntos de procesadores, utilice la opción -x para eliminar la configuración.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Elimine la configuración activa.

   # pooladm -x

   La opción - x para pooladm elimina todos los elementos definidos por el usuario de la configuración dinámica. Todos los recursos vuelven a su estado predeterminado, y todos los vínculos de agrupaciones se sustituyen con un vínculo a la agrupación predeterminada.

Mezcla de clases de planificación en un conjunto de procesadores

Puede mezclar procesos en las clases TS e IA en el mismo conjunto de procesadores de forma segura. Si mezcla otras clases de planificación en un conjunto de procesadores, puede obtener resultados inesperados. Si el uso de pooladm -x crea clases de planificación mezcladas en un conjunto de procesadores, utilice el comando priocntl para mover los procesos en ejecución a una clase de planificación diferente. Consulte Cómo mover manualmente los procesos de la clase TS a la clase FSS. Consulte también la página del comando man priocntl(1).

Configuración de atributos de agrupaciones y vinculación a una agrupación

Puede configurar un atributo project.pool para asociar una agrupación de recursos con un proyecto.

Puede vincular un proceso en ejecución a una agrupación de dos modos:

• Puede utilizar el comando poolbind que se describe en el comando poolbind(1M) para vincular un proceso específico a una agrupación de recursos concreta.

• Puede utilizar el atributo project.pool en la base de datos project para identificar la vinculación de agrupaciones para una nueva tarea o sesión de inicio que se abre con el comando newtask. Consulte las páginas del comando man newtask(1), projmod(1M) y project(4).

Cómo vincular procesos a una agrupación

El procedimiento siguiente utiliza poolbind con la opción -p para vincular manualmente un proceso (en este caso, el shell activo) a una agrupación denominada ohare.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Vincule manualmente un proceso a una agrupación:

   # poolbind -p ohare $$

3. Compruebe la vinculación de la agrupación para el proceso utilizando poolbind con la opción -q.

   $ poolbind -q $$ 155509 ohare

   El sistema muestra el ID de proceso y la vinculación de la agrupación.

Cómo vincular tareas o proyectos a una agrupación

Para vincular tareas o proyectos a una agrupación, utilice el comando poolbind con la opción -i. El ejemplo siguiente vincula todos los procesos del proyecto airmiles a la agrupación laguardia.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Vincule todos los procesos del proyecto airmiles a la agrupación laguardia.

   # poolbind -i project -p laguardia airmiles

Cómo configurar el atributo project.pool para un proyecto

Puede definir el atributo project.pool para vincular los procesos de un proyecto a una agrupación de recursos.

1. Conviértase en superusuario o asuma un rol que incluya el perfil de administración de procesos.

   El rol de administrador del sistema incluye el perfil de administración de procesos. Para obtener más información sobre las funciones, consulte Using the Solaris Management Tools With RBAC (Task Map) de System Administration Guide: Basic Administration.

2. Añada un atributo project.pool a cada entrada de la base de datos project.

   # projmod -a -K project.pool=poolname project

Cómo utilizar los atributos project para vincular un proceso a una agrupación diferente

Supongamos que tiene una configuración con dos agrupaciones denominadas studio y backstage. El archivo /etc/project incluye lo siguiente:

user.paul:1024::::project.pool=studio
user.george:1024::::project.pool=studio
user.ringo:1024::::project.pool=backstage
passes:1027::paul::project.pool=backstage

Con esta configuración, los procesos que inicia el usuario paul están vinculados de forma predeterminada a la agrupación studio.

El usuario paul puede modificar la vinculación de la agrupación para los procesos que inicia. paul también puede utilizar newtask para vincular trabajos a la agrupación backstage, iniciando el proyecto passes.