Discussion :

[Aminos]

Bonjour,
Je dois modifier la priorite des process d'un software d'ordonnancement, pour ameliorer la gestion du dit ordonnanceur qui n'a pas toujours la main pour lancer des jobs à la minute pret, surtout quand il y a surcharge sur les processeurs du serveur (8 processeurs).
On m'a recommandé de donner la priorité -15 aux process de ce soft est ce que cela ne risque pas de causer des degats quelque part??
Merci pour vos reponses j'en ai besoin d'urgence.

[jlliagre]

On m'a recommandé de donner la priorité -15 aux process de ce soft est ce que cela ne risque pas de causer des degats quelque part??

Non, mais ça n'aura probablement pas d'effet significatif non plus.

Si tu veux que ton processus soit réellement prioritaire, passe le en temps réel ou équivalent. Il faudrait que tu dises de quel Unix il s'agit pour savoir si c'est faisable.

[Aminos]

Bonjour,
Merci pour ta reponse.
Pour l'unix il s'agit de TRU64.
Merci encore, j'aimerais aussi avoir le plus de details possible.

[jlliagre]

Désolé, je ne connais pas Tru64.

[gangsoleil]

Bonjour,

Non, mais ça n'aura probablement pas d'effet significatif non plus.

Si tu veux que ton processus soit réellement prioritaire, passe le en temps réel ou équivalent. Il faudrait que tu dises de quel Unix il s'agit pour savoir si c'est faisable.

Attention, ce genre de modification n'est pas sans danger !

Le fait de modifier la priorité d'un processus (ce qui se fait via les commandes "nice" ou "renice") introduit des problèmes dans l'ordonnancement des processus.
Les risques principaux sont des risques de famine : si le processus priorétisé demande trop de CPU, et que celui-ci lui est accordé, alors les autres processus ne pourront plus passer de temps sur les CPU.

Si ceci n'est pas forcément vrai pour la repriorétisation des processus (via nice), car il existe des mécanismes de contrôle de non-famine, ceci est particulièrement vrai pour le cas du temps réel : si ton process part en boucle, la seule solution est l'arrêt électrique de la machine (testé et désapprouvé).

[jlliagre]

Attention, ce genre de modification n'est pas sans danger !

Danger limité puis qu'il s'agit d'un ordonnanceur. Un processus qui a peu de risque de contenir du code "lourd".

Le fait de modifier la priorité d'un processus (ce qui se fait via les commandes "nice" ou "renice")

Pas tout à fait. nice et renice ne modifient pas mais influent la priorité d'un processus. Ils ne font que demander au noyau de privilégier (ou défavoriser) le processus cible.
Sous Solaris, la commande priocntl permet de mettre un processus dans une classe de scheduling adéquate (Real-Time ou Fixed Priority) puis de modifier sa priorité absolue.
Sous Tru64, je ne sais pas ce qu'on peut trouver d'équivalent.

introduit des problèmes dans l'ordonnancement des processus.
Les risques principaux sont des risques de famine : si le processus priorétisé demande trop de CPU, et que celui-ci lui est accordé, alors les autres processus ne pourront plus passer de temps sur les CPU.

Pas avec un scheduler standard, mais c'est un risque majeur avec un scheduler temps réel, à ne pas mettre entre toutes les mains donc ...

Si ceci n'est pas forcément vrai pour la repriorétisation des processus (via nice), car il existe des mécanismes de contrôle de non-famine, ceci est particulièrement vrai pour le cas du temps réel : si ton process part en boucle, la seule solution est l'arrêt électrique de la machine (testé et désapprouvé).

Oui, c'est une expérience que tout les gens qui ont travaillé avec des O/S temps réel ont eu un jour ou l'autre. Son origine n'est pas l'O/S mais un bug dans l'application prioritaire. On peut s'en sortir si on a pris soin de laisser un shell (et les daemons en dessous) au même niveau de priorité absolue que le processus temps réel.

En fait, je pense que ce qu'il faudrait à Aminos, c'est un Fair Share Scheduler qui permettrait d'accorder plus de poids à son ordonnanceur sans risquer de deadlocks, mais là aussi je connais bien sous Solaris mais aucune idée de son éventuelle disponibilité sous Tru64.