Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 26/01/2016, à 10:54

nbi

deux sessions graphiques et programmes en arrière plan

Salut,

pas sûr de poster où il faut mais je n'ai pas trouvé mieux.

Au boulot, j'utilise un PC que je partage avec une seconde personne de temps en temps. comme on doit lancer des calculs matlab assez lourds, on ouvre tous deux une session et on bascule avec Ctrl+Alt+F7 et Ctrl+Alt+F8. LE soucis, c'est que les programmes qu'on lance semblent s'arrêter au bout d'un moment si l'on change de session. Ils ne redémarrent que lorsque l'on reprend la main.

j'ai vérifié avec un htop et effectivement le cpu est au plus bas par moment. (ce n'est pas immédiat). je précise également que ce sont des programmes gourmand en ram et pas toujours systématique.

une idée ?

merci !

Dernière modification par nbi (Le 26/01/2016, à 11:00)

Hors ligne

#2 Le 26/01/2016, à 16:22

carreti

Re : deux sessions graphiques et programmes en arrière plan

Hello,


Je ne suis pas sûr de comprendre le problème ou du moins son énoncé, mais j'ai peut être une solution :
Lancer les commandes en nohup, c'est normalement ce que l'on fait pour détacher une commande de la session en cours (pour ssh en cas de coupure réseau par exemple, pour que la commande continue à tourner ...) ...

https://fr.wikipedia.org/wiki/Nohup

Sinon cela peut aussi être aussi une histoire de "nice" ... Une option de la ligne de compilation, du kernel ou autre qui donnerait plus de temps CPU à l'application de "premier plan" ...
mais je ne vois pas trop comment le diagnostiquer simplement ...

Dernière modification par carreti (Le 26/01/2016, à 16:24)


Utilisateur et administrateur de Linux et d'Unix (depuis le siècle dernier) et plus précisément ces dernières années de  Linux Gentoo et de Windows 10 ...
Je cherche du boulot sur Paris et RP Ouest en administration système ou mieux dans la tierce maintenance applicative, middleware, base de données, flux ...

Hors ligne

#3 Le 26/01/2016, à 17:40

nbi

Re : deux sessions graphiques et programmes en arrière plan

Merci pour ton aide,
je n'avais pas pensé à "nice". je viens de tenter de changer le nice d'un processus qui s'était mis en veille. il est reparti de suite. à voir si ça tient dans le temps. j'essaierai aussi nohup voir si ça fonctionne mais ça ne m'arrange pas dans le sens où le programme affiche des graphiques au cours des calculs.

nbi

Hors ligne

#4 Le 27/01/2016, à 15:27

nbi

Re : deux sessions graphiques et programmes en arrière plan

re,
bon ben, ça ne règle pas le problème. le processus s'est remis à 1% de CPU, j'ai à nouveau changé le nice, mais le programme n'est pas reparti à 100%, il a fallu que je change de session encore une fois... grrrr

Dernière modification par nbi (Le 27/01/2016, à 15:28)

Hors ligne

#5 Le 27/01/2016, à 17:46

carreti

Re : deux sessions graphiques et programmes en arrière plan

Intéressant comme problème. Ça pourrait aussi venir des control groups apparemment ... mais j'ai jamais été confronté à cela, ni au besoin de mettre en place ce genre de politique, ni donc a en subir "les effets de bords" ...

Une page qui explique simplement les différences entre nice et cgroups par l'exemple avec top : http://blog.scoutapp.com/articles/2014/ … nd-cgroups

... mais cela doit venir encore d'autre chose pour que cela agisse uniquement quand vous changez de session ...

Sinon il existe des outils comme pidstat de la suite sysstat (sudo apt-get install sysstat) qui permettrait de surveiller la commutation de contexte (context switch). http://www.leonardoborda.com/blog/how-t … ntudebian/

Un peu de doc de fond : http://careers.directi.com/display/tu/U … timization

Une solution DIY mais si personne propose mieux ...

Dernière modification par carreti (Le 27/01/2016, à 17:54)


Utilisateur et administrateur de Linux et d'Unix (depuis le siècle dernier) et plus précisément ces dernières années de  Linux Gentoo et de Windows 10 ...
Je cherche du boulot sur Paris et RP Ouest en administration système ou mieux dans la tierce maintenance applicative, middleware, base de données, flux ...

Hors ligne

#6 Le 02/02/2016, à 14:55

nbi

Re : deux sessions graphiques et programmes en arrière plan

merci, je vais regarder tout ça et voir si je m'en sors. sinon, va falloir qu'on bosse autrement, mais bon je ne voulais pas brusquer mon chef ^^

Hors ligne

#7 Le 03/02/2016, à 14:15

nbi

Re : deux sessions graphiques et programmes en arrière plan

re,
alors, j'ai trouvé ce qui fait que ça s'arrête, mais pas pourquoi ça le fait :
comme je le pensais, c'est l'affichage des graphiques pendant le calcul qui met la zone. je ne sais pas pourquoi, mais si je n'affiche aucun graph, alors le calcul se poursuit sans problème. j'imagine qu'il y a un problême de gestion graphique lorsque la session graphique n'est pas active.

Hors ligne

#8 Le 03/02/2016, à 19:32

carreti

Re : deux sessions graphiques et programmes en arrière plan

Hello,

c'est bien ça avance ...

L'audit avec systat / sar l'aurait probablement révélé ...

http://www.leonardoborda.com/blog/how-t … ntudebian/

Si le programme qui tourne n'a pas accès a X, ça pose forcement problème lorsqu'il en a besoin. Une chance qu'il se mette en attente, il pourrait carrément planter.
Voir si en jouant avec xauth ou autre, si les "graphiques" ne peuvent pas utiliser n'importe quelle session X ouverte ...

Chez moi connecté sur un autre utilisateur, si je fais "su" nom d'un autre utilisateur (dont la session est en attente) dans konsole, puis que je lance : export $(dbus-launch), je peux lancer kate (par exemple) depuis la konsole dont ce n'est pas la session X. Donc ton programme passerait lancé comme ça ...
Après ça demande d'avoir une session en ligne de commande ouverte sur une autre session qui n'est pas la sienne ...

J'ai essayé de faire le test inverse avec un utilisateur non-logué et là ça n'a pas fonctionné. Il faudrait récupérer la session de l'utilisateur logué, son display, son magic-cookie et "xauther" tout ça dans le .Xauthority de l'utilisateur qui veut utiliser le X de l'utilisateur logué, mais ça demande de sudoer par moment et ce n'est pas si simple ... 

*** EDIT ***

Sinon je pense que "sux" peut aussi être adapté à la situation :
... dans la session du collègue logué dans une console lancer :

sux ton_login -c 'commande-de-compilation'

( Si sux n'est pas installé )

sudo apt-get install sux

Cela permet de récupérer les droits X du compte "ton_login", juste pour lancer la commande "commande-de-compilation" depuis l'environnement d'un autre utilisateur ...

Dernière modification par carreti (Le 04/02/2016, à 08:27)


Utilisateur et administrateur de Linux et d'Unix (depuis le siècle dernier) et plus précisément ces dernières années de  Linux Gentoo et de Windows 10 ...
Je cherche du boulot sur Paris et RP Ouest en administration système ou mieux dans la tierce maintenance applicative, middleware, base de données, flux ...

Hors ligne