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.