cerhu > linux.debian.user.french

roger.tarani (02/01/2019, 17h20)
Bonjour
et meilleurs voeux à tous !

je crée un nouveau sujet juste pour la sortie d'hibernation qui n'est pas résolue (le pb FF est réglé).

En résumé :
Stretch, 8 Go de RAM, 8 Go de SWAP, un disque largement inoccupé.
RAM occupée à 48% et SWAP à 34% juste en sortie d'hibernation.

La mise en veille et sortie de veille sont immédiates.
Mais la sortie d'hibernation est laborieuse (voir détails dans l'ancien message que j'ai repris ici).

Jusqu'à il y a quelques mois, la sortie d'hibernation était rapide (je n'ai pas mesuré mais disons 1 mn, et ensuite la machine était disponible).
La dernière sortie d'hibernation a du prendre environ le même temps que l'avant-dernière (6-8 mn), avec une réactivité clavier-souris un peu supérieure. Il faut au total

Voici, ci-dessous les dernières mesures de 'w' avant et en sortie d'hibernation :
le tload est très élevé.

Avant mise en hibernation

$ w
10:35:28 up 8 days, 13:54, 6 users, load average: 0.21, 0.26, 0.29
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
dev :0 :0 24Dec18 ?xdm? 31:00m 0.23s x-session-manag
dev pts/0 :0 24Dec18 7days 2.22s 2.22s bash
dev pts/9 :0 25Dec18 7days 0.05s 0.00s tmux attach-ses
dev pts/11 mosh- Thu20 5days 0.32s 0.32s -bash
dev pts/12 192.168.27.68- 10:34 10:21m 0.90s 2:41 mosh-servernew
dev pts/15 192.168.27.68- 10:34 1.00s 0.10s 0.00s w

En sortie d'hibernation (avec toujours un peu de latence, pour copier-coller le présent texte, mais acceptable)

$ w
16:13:07 up 37 days, 4:43, 5 users, load average: 0.88, 6.76, 5.40
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
dev tty7 :0 26Nov18 37days 9:18m 1.66s /usr/lib/gnome-session/gnome-session-binary
dev pts/3 tmux(21173).%11 Mon02 2days 24.68s 0.00s /bin/sh -c test
dev pts/7 tmux(21173).%6 Mon02 5:36m 9.12s 9.04s mosh-client
dev pts/8 tmux(21173).%7 Mon02 2days 15:46 15:46 htop
dev pts/10 tmux(21173).%10 Mon02 2days 0.09s 0.09s -bash
+18mn

16:31:52 up 37 days, 5:02, 5 users, load average: 0.86, 1.04, 2.30
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
dev tty7 :0 26Nov18 37days 9:20m 1.66s /usr/lib/gnome-session/gnome-session-binary
dev pts/3 tmux(21173).%11 Mon02 2days 25.25s 0.00s /bin/sh -c test
dev pts/7 tmux(21173).%6 Mon02 5:55m 9.31s 9.23s mosh-client
dev pts/8 tmux(21173).%7 Mon02 2days 16:06 16:06 htop
dev pts/10 tmux(21173).%10 Mon02 2days 0.09s 0.09s -bash

Que dois-je vérifier d'autre pour trouver la cause de cette lenteur incroyable ?
Merci.

PRECEDENT MESSAGE

Bonjour

Le lun. 31 déc. 2018 16:19, <roger.tarani> a écrit :

Bonjour,

La configuration avec FF tient bien. Je n'ai plus de problème.

Je ne refais pas un message séparé
MAIS je viens de faire un essai de mise en hibernation et de sortie.

Waouh...
1 mn d'écran noir
3 mn de souris clavier muets
6-8 mn avec un temps de réponse des fenêtres de 20+, puis 10,puis 5 s
à +15 mn, j'ai retrouvé une machine réactive.

La SWAP est de 8 Go pour 8 Go de RAM.
RAM employée à 50%
SWAP employée à 30%

Éric Dégenètais a écrit :
Assez naïvement, ce type de configuration m'a toujours posé question. La machine démarre et se retrouve à devoir sortir 4Go du swap pour retrouver son working set pré-hibernation. Je me demande quels mécanismes existent (c'est une vraie question, je ne suis pas ironique) pour que la machine ne soit pas dans la même panade qu'une machine sauvagement sous-dimensionnée qui croule sous le swap...

J'ai un vague souvenir qu'il faudrait en SWAP 1,5 fois la RAM. C'est quoi la règle ?

J'ai une JVM installée pour faire tourner quelques pgm Java.

Pendant tout ce temps là, la machine ne tourne pas à plein régime pour des trucs comme des scripts dans le navigateur.
htop ou System monitor, quand j'arrive à y accéder ne m'indique rien d'anormal (par rapport à mon niveau de compétence modeste)
Rien d'extraordinaire, sauf load average apparemment élevé (2coeurs)
$ nproc
2

$ uptime
16:05:16 up 35 days, 4:35, 5 users, load average: 1.77, 2.31, 4.98

$ uptime
16:16:16 up 35 days, 4:46, 5 users, load average: 0.74, 0.93, 2.83

mesures sur 1/5/15 mn

On voit bien qu'il y a eu la queue au portillon... mais pourquoi ?

Que faut-il vérifier d'autre pour en savoir plus et corriger ça ?

Merci

----- Original Message -----
From: "Jérémy Prego" <jeremy>
To: debian-user-french
Sent: Saturday, December 29, 2018 12:14:13 PM
Subject: Re: Firefox : mise à jour + blocage

Le 29/12/2018 à 11:30, roger.tarani a écrit :
> December 28, 2018 8:58:06 PM, Gaëtan Perrier a écrit :
>>> J'ai fait un kill de ff, j'ai déplacé le répertoire de profil, j'ai
>>> redémarré, j'ai eu un refus,

>> Si FF ne démarre pas en l'absence de profil s'est vraiment étrange ...
>> Ça correspond à un premier démarrage après une installation.


Bonjour,
oui mais non. si j'ai biens compris, Roger a renomer / déplacer le
xxx.default qui se trouve dans .mozilla/firefox. je pense que ce n'est
pas la bonne méthode quand on dit "supprimer / renommer" le profile. à
la place, je renommerai le .mozilla...

> Jerem


> Je n'ai pas encore mis la machine en hibernation. Juste des mises en veille. RAS pour l'instant Je peux toujours ouvrir un lien dans FF depuis le terminal par exemple.
> Dans le passé, j'ai du faire des kill du ps firefox car il y avait trop d'onglets et/ou des scripts qui bloquaient. Voire même éteindre la machine car je n'avais plus aucun contrôle (au mieux, un clic fenêtre avaut un effet quelques mn plus tard ! donc pas d'accèsaux process; et non plus aux autres tty).
> Ce qui m'embête, comme je l'ai dit plus tôt, c'est que la machine sortie d'hibernation ne montrait pas d'utilisation CPU et RAM effarante.
> A ce propos, comment tester si une configuration FF est conforme (à ce qui est prévu par l'éditeur) ?
> Et comment agir lorsqu'une machine Linux est figée (10-30 mn voire plus) ? Peut-on accéder à une sorte de console de secours, à un canot de sauvetage, une 'panic room' (si elle existe) ?
> Stopper la machine en coupant l'alimentation me pose problème


Éric Dégenètais
roger.tarani (05/01/2019, 12h00)
Bonjour

Le test de sortie d'hibernation SANS FF ouvert est simple et concluant : lasortie est immédiate.
FF est le coupable le plus probable.

Il faut vérifier qu'il n'a pas de complices.

Du coup, à part fermer FF avant chaque hibernation, que faut-il vérifier pour régler ce problème ?
Si je réinstalle ce monstre de FF, comment vérifier que c'est correct ?

Alternative : et pourquoi pas un navigateur plus simple et moins gourmand ?

Merci

----- Original Message -----
From: roger tarani <roger.tarani>
To: Liste Debian <debian-user-french>
Sent: Wed, 02 Jan 2019 16:10:28 +0100 (CET)
Subject: Sortie d'hibernation hyper longue - Stretch

Bonjour
et meilleurs voeux à tous !

je crée un nouveau sujet juste pour la sortie d'hibernation qui n'est pas résolue (le pb FF est réglé).

En résumé :
Stretch, 8 Go de RAM, 8 Go de SWAP, un disque largement inoccupé.
RAM occupée à 48% et SWAP à 34% juste en sortie d'hibernation.

La mise en veille et sortie de veille sont immédiates.
Mais la sortie d'hibernation est laborieuse (voir détails dans l'ancien message que j'ai repris ici).

Jusqu'à il y a quelques mois, la sortie d'hibernation était rapide (je n'ai pas mesuré mais disons 1 mn, et ensuite la machine était disponible).
La dernière sortie d'hibernation a du prendre environ le même temps que l'avant-dernière (6-8 mn), avec une réactivité clavier-souris un peu supérieure. Il faut au total

Voici, ci-dessous les dernières mesures de 'w' avant et en sortie d'hibernation :
le tload est très élevé.

Avant mise en hibernation

$ w
10:35:28 up 8 days, 13:54, 6 users, load average: 0.21, 0.26, 0.29
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
dev :0 :0 24Dec18 ?xdm? 31:00m 0.23s x-session-manag
dev pts/0 :0 24Dec18 7days 2.22s 2.22s bash
dev pts/9 :0 25Dec18 7days 0.05s 0.00s tmux attach-ses
dev pts/11 mosh- Thu20 5days 0.32s 0.32s -bash
dev pts/12 192.168.27.68- 10:34 10:21m 0.90s 2:41 mosh-server new
dev pts/15 192.168.27.68- 10:34 1.00s 0.10s 0.00s w

En sortie d'hibernation (avec toujours un peu de latence, pour copier-coller le présent texte, mais acceptable)

$ w
16:13:07 up 37 days, 4:43, 5 users, load average: 0.88, 6.76, 5.40
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
dev tty7 :0 26Nov18 37days 9:18m 1.66s /usr/lib/gnome-session/gnome-session-binary
dev pts/3 tmux(21173).%11 Mon02 2days 24.68s 0.00s /bin/sh -c test
dev pts/7 tmux(21173).%6 Mon02 5:36m 9.12s 9.04s mosh-client
dev pts/8 tmux(21173).%7 Mon02 2days 15:46 15:46 htop
dev pts/10 tmux(21173).%10 Mon02 2days 0.09s 0.09s -bash
+18mn

16:31:52 up 37 days, 5:02, 5 users, load average: 0.86, 1.04, 2.30
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
dev tty7 :0 26Nov18 37days 9:20m 1.66s /usr/lib/gnome-session/gnome-session-binary
dev pts/3 tmux(21173).%11 Mon02 2days 25.25s 0.00s /bin/sh -c test
dev pts/7 tmux(21173).%6 Mon02 5:55m 9.31s 9.23s mosh-client
dev pts/8 tmux(21173).%7 Mon02 2days 16:06 16:06 htop
dev pts/10 tmux(21173).%10 Mon02 2days 0.09s 0.09s -bash

Que dois-je vérifier d'autre pour trouver la cause de cette lenteur incroyable ?
Merci.

PRECEDENT MESSAGE

Bonjour

Le lun. 31 déc. 2018 16:19, <roger.tarani> a écrit :

Bonjour,

La configuration avec FF tient bien. Je n'ai plus de problème.

Je ne refais pas un message séparé
MAIS je viens de faire un essai de mise en hibernation et de sortie.

Waouh...
1 mn d'écran noir
3 mn de souris clavier muets
6-8 mn avec un temps de réponse des fenêtres de 20+, puis 10, puis 5 s
à +15 mn, j'ai retrouvé une machine réactive.

La SWAP est de 8 Go pour 8 Go de RAM.
RAM employée à 50%
SWAP employée à 30%

Éric Dégenètais a écrit :
Assez naïvement, ce type de configuration m'a toujours posé question. La machine démarre et se retrouve à devoir sortir 4Go du swap pour retrouver son working set pré-hibernation. Je me demande quels mécanismes existent (c'est une vraie question, je ne suis pas ironique) pour que la machine ne soit pas dans la même panade qu'une machine sauvagement sous-dimensionnée qui croule sous le swap...

J'ai un vague souvenir qu'il faudrait en SWAP 1,5 fois la RAM. C'est quoi la règle ?

J'ai une JVM installée pour faire tourner quelques pgm Java.

Pendant tout ce temps là, la machine ne tourne pas à plein régime pour des trucs comme des scripts dans le navigateur.
htop ou System monitor, quand j'arrive à y accéder ne m'indique rien d'anormal (par rapport à mon niveau de compétence modeste)
Rien d'extraordinaire, sauf load average apparemment élevé (2 coeurs)
$ nproc
2

$ uptime
16:05:16 up 35 days, 4:35, 5 users, load average: 1.77, 2.31, 4.98

$ uptime
16:16:16 up 35 days, 4:46, 5 users, load average: 0.74, 0.93, 2.83

mesures sur 1/5/15 mn

On voit bien qu'il y a eu la queue au portillon... mais pourquoi ?

Que faut-il vérifier d'autre pour en savoir plus et corriger ça ?

Merci

----- Original Message -----
From: "Jérémy Prego" <jeremy>
To: debian-user-french
Sent: Saturday, December 29, 2018 12:14:13 PM
Subject: Re: Firefox : mise à jour + blocage

Le 29/12/2018 à 11:30, roger.tarani a écrit :
> December 28, 2018 8:58:06 PM, Gaëtan Perrier a écrit :
>>> J'ai fait un kill de ff, j'ai déplacé le répertoire de profil, j'ai
>>> redémarré, j'ai eu un refus,

>> Si FF ne démarre pas en l'absence de profil s'est vraiment étrange ...
>> Ça correspond à un premier démarrage après une installation.


Bonjour,
oui mais non. si j'ai biens compris, Roger a renomer / déplacer le
xxx.default qui se trouve dans .mozilla/firefox. je pense que ce n'est
pas la bonne méthode quand on dit "supprimer / renommer" le profile. à
la place, je renommerai le .mozilla...

> Jerem


> Je n'ai pas encore mis la machine en hibernation. Juste des mises en veille. RAS pour l'instant Je peux toujours ouvrir un lien dans FF depuis le terminal par exemple.
> Dans le passé, j'ai du faire des kill du ps firefox car il y avait trop d'onglets et/ou des scripts qui bloquaient. Voire même éteindre la machine car je n'avais plus aucun contrôle (au mieux, un clic fenêtre avaut un effet quelques mn plus tard ! donc pas d'accès aux process; et non plus aux autres tty).
> Ce qui m'embête, comme je l'ai dit plus tôt, c'est que la machine sortie d'hibernation ne montrait pas d'utilisation CPU et RAM effarante..
> A ce propos, comment tester si une configuration FF est conforme (àce qui est prévu par l'éditeur) ?
> Et comment agir lorsqu'une machine Linux est figée (10-30 mn voire plus) ? Peut-on accéder à une sorte de console de secours, àun canot de sauvetage, une 'panic room' (si elle existe) ?
> Stopper la machine en coupant l'alimentation me pose problème


Éric Dégenètais
daniel huhardeaux (05/01/2019, 14h30)
Le 05/01/2019 à 10:52, roger.tarani a écrit :
> Bonjour


Bonjour

> Le test de sortie d'hibernation SANS FF ouvert est simple et concluant : la sortie est immédiate.
> FF est le coupable le plus probable.


J'hiberne avec FF et 20 onglets ouverts + Chromium avec 10 onglets,
retour immédiat.
[..]
roger.tarani (05/01/2019, 15h10)
Moi aussi, avant (avant quoi je ne sais pas).
Mais depuis quelques mois, la sortie d'hibernation est subitemment devenue très longue.

Comme dans le cas suivant :
[..]

Michael Schmid dit en juin 2017 dans cet article :
In recent hibernation implementations, when resuming, only the minimal parts for the kernel to work are written back to memory from the swap; the restis then loaded by the user-space applications themselves, as soon as it isneeded.

While this makes the system behave sluggishly at first, it nevertheless takes less total time to have it operating fluently, as pieces of memory that are not interesting for what you are currently doing must not be moved backyet.

Est-ce qu'il y aurait eu une màj de Stretch il y a quelques mois qui aurait pu causer ça ?

Quoi testeer pour savoir si c'est uniquement un pb causé par FF ou si c'est aussi lié aux composants Debian installés ?

J'ai cherché sur le net mais pas encore trouvé.

----- Original Message -----
From: "daniel huhardeaux" <no-spam>
To: debian-user-french
Sent: Saturday, January 5, 2019 1:20:27 PM
Subject: Re: Sortie d'hibernation hyper longue - Stretch

Le 05/01/2019 à 10:52, roger.tarani a écrit :
> Bonjour


Bonjour

> Le test de sortie d'hibernation SANS FF ouvert est simple et concluant : la sortie est immédiate.
> FF est le coupable le plus probable.


J'hiberne avec FF et 20 onglets ouverts + Chromium avec 10 onglets,
retour immédiat.
[..]
Eric Degenetais (05/01/2019, 16h10)
Le sam. 5 janv. 2019 14:06, <roger.tarani> a écrit :

[..]
> it is needed.
> While this makes the system behave sluggishly at first, it nevertheless
> takes less total time to have it operating fluently, as pieces of memory
> that are not interesting for what you are currently doing must not be moved
> back yet.
> Est-ce qu'il y aurait eu une màj de Stretch il y a quelques mois qui
> aurait pu causer ça ?

On en arrive donc à la situation que je décrivais dans mon interprétation
naïve : le système se retrouve donc complètement à la rue comme s'il venait
de prendre une surcharge massive. Ça marche sans doute pour une petite
configuration, en pratique sur mon poste de développement je préfère
éteindre et rebooter par la suite. En fait de "sluggish at the beginning",
le système ne s'en remet jamais.
Si je veux juste une pause je fais du suspend to ram.
[..]
roger.tarani (05/01/2019, 22h00)
suspend to ram : oui, mais ça n'est pas une hibernation.
Mais au fait, combien de temps ça tient sur un portable ?

Comment expliques-tu que soudainement l'hibernation ait un tel comportement?

----- Original Message -----
From: "Eric Degenetais" <edegenetais>
To: debian-user-french
Cc: "ML Debian User French" <debian-user-french>
Sent: Saturday, January 5, 2019 3:07:44 PM
Subject: Re: Sortie d'hibernation hyper longue - Stretch

Le sam. 5 janv. 2019 14:06, < roger.tarani > a écrit :

Moi aussi, avant (avant quoi je ne sais pas).
Mais depuis quelques mois, la sortie d'hibernation est subitemment devenue très longue.

Comme dans le cas suivant :
[..]

Michael Schmid dit en juin 2017 dans cet article :
In recent hibernation implementations, when resuming, only the minimal parts for the kernel to work are written back to memory from the swap; the restis then loaded by the user-space applications themselves, as soon as it isneeded.

While this makes the system behave sluggishly at first, it nevertheless takes less total time to have it operating fluently, as pieces of memory that are not interesting for what you are currently doing must not be moved backyet.

Est-ce qu'il y aurait eu une màj de Stretch il y a quelques mois qui aurait pu causer ça ?

On en arrive donc à la situation que je décrivais dans mon interprétation naïve : le système se retrouve donc complètement à la rue comme s'il venait de prendre une surcharge massive. Ça marche sans doute pour une petite configuration, en pratique sur mon poste de développement je préfère éteindre et rebooter par la suite. En fait de "sluggish at the beginning", le système ne s'en remet jamais.
Si je veux juste une pause je fais du suspend to ram.

Quoi testeer pour savoir si c'est uniquement un pb causé par FF ou si c'est aussi lié aux composants Debian installés ?

J'ai cherché sur le net mais pas encore trouvé.

----- Original Message -----
From: "daniel huhardeaux" < no-spam >
To: debian-user-french
Sent: Saturday, January 5, 2019 1:20:27 PM
Subject: Re: Sortie d'hibernation hyper longue - Stretch

Le 05/01/2019 à 10:52, roger.tarani a écrit :
> Bonjour


Bonjour

> Le test de sortie d'hibernation SANS FF ouvert est simple et concluant : la sortie est immédiate.
> FF est le coupable le plus probable.


J'hiberne avec FF et 20 onglets ouverts + Chromium avec 10 onglets,
retour immédiat.

[..]
> Bonjour,
> oui mais non. si j'ai biens compris, Roger a renomer / déplacer le
> xxx.default qui se trouve dans .mozilla/firefox. je pense que ce n'est
> pas la bonne méthode quand on dit "supprimer / renommer" le profile.à
> la place, je renommerai le .mozilla...
> Éric Dégenètais


Éric Dégenètais
Stephane Ascoet (07/01/2019, 10h40)
Le 05/01/2019 à 20:53, roger.tarani a écrit :
> suspend to ram : oui, mais ça n'est pas une hibernation.


Ah bon? Pour moi les deux ont tout le temps ete synonymes?!
Stephane Ascoet (07/01/2019, 10h40)
Le 05/01/2019 à 20:53, roger.tarani a écrit :
> suspend to ram : oui, mais ça n'est pas une hibernation.


Ah oui non tu as raison, l'hibernation c'est "suspend to disk". Mais
Eric n'avait pas fait de confusion, en gros son message dit, pour
caricaturer, que l'hibernation c'est pourri et qu'il prefere la veille
classique(ACPI S3, qui n'est pas toujours si classique que ca car les
resultats peuvent etre catastrophiques sur les machines recalcitrantes)
Eric Degenetais (07/01/2019, 15h20)
Le lun. 7 janv. 2019 à 09:39, Stephane Ascoet
<stephane.ascoet> a écrit :
> Le 05/01/2019 à 20:53, roger.tarani a écrit :
> Ah oui non tu as raison, l'hibernation c'est "suspend to disk". Mais
> Eric n'avait pas fait de confusion, en gros son message dit, pour
> caricaturer, que l'hibernation c'est pourri et qu'il prefere la veille
> classique(ACPI S3, qui n'est pas toujours si classique que ca car les
> resultats peuvent etre catastrophiques sur les machines recalcitrantes)
> --
> Cordialement, Stephane Ascoet


Disons, pour adoucir un peu la chose, que pour mon usage et sur les
machines dont je dispose, j'obtiens de meilleurs résutats avec suspend
to RAM pour les périodes courtes, et carrément poweroff suivi de
reboot quand c'est pour longtemps.
Sachant que ce n'est pas gravé dans le marbre si on me fournit un jour
une solution au fait que la machine se réveille systématiquement en
vrac de l'hibernation dès que les applications en cours consomment
beaucoup de RAM. La solution pouvant être une nouvelle version de l'OS
qui ne présente pas cet inconvénient, ou la publication de guidelines
pour améliorer le fonctionnement. Mais comme je ne vois pas trop ce
que l?hibernation me rapporte de plus qu'un powercycle complet (le
démarrage, aujoud'hui, c'est assez rapide pour mon usage), je ne suis
pas très motivé pour chercher ce qui ne va pas.

D'une manière générale sur un poste de travail, ça ne me gêne en aucun
cas de l'éteindre quand je m'en absente une heure ou plus, vu que dans
ce cas elle ne me sert pas ... L'hibernation pouvant être
éventuellement un dernier recours quand on travaille avec un portable
et qu'on tombe à cours de batterie.

Cordialement
______________
Éric Dégenètais
roger.tarani (07/01/2019, 17h00)
En résumé, on a :
veille : suspend to ram
hibernation : suspend to disk

Il n'y a rien d'autre, je crois.
Existe-t-il un mode qui permettrait de réduire la capacité de calcul de la machine ?
on baisse la fréq du processeur, on suspend tous les services non vitaux, on baisse la luminosité de l'écran, etc.

Je te rejoins sur l'intérêt limité de l'hibernation compte tenu de la rapidité d'un démarrage normal et du risque de plantageen sortie d'hibernation.
La raison de mon utilisation de l'hibernation est simple : j'ai un environnement avec plein de trucs et de réglages et je ne maîtrise pas complètement l'enregistrement et donc la reprise de cette configuration avec tous ces trucs.
Du coup, ça me prend du temps de tout ouvrir correctement à chaque démarrage (après lancement automatique des applications habituels).

D'ailleurs, comment faites-vous pour traiter ce problème d'enregistrerla config au poil et de la retrouver au démarrage ?
Comme ça, plus de problème d'hibernation qui n'est plus un sujet !

Merci

----- Original Message -----
From: "Eric Degenetais" <edegenetais>
To: debian-user-french
Cc: "ML Debian User French" <debian-user-french>
Sent: Monday, January 7, 2019 2:15:18 PM
Subject: Re: Sortie d'hibernation hyper longue - Stretch

Le lun. 7 janv. 2019 à 09:39, Stephane Ascoet
<stephane.ascoet> a écrit :
> Le 05/01/2019 à 20:53, roger.tarani a écrit :
> Ah oui non tu as raison, l'hibernation c'est "suspend to disk". Mais
> Eric n'avait pas fait de confusion, en gros son message dit, pour
> caricaturer, que l'hibernation c'est pourri et qu'il prefere la veille
> classique(ACPI S3, qui n'est pas toujours si classique que ca car les
> resultats peuvent etre catastrophiques sur les machines recalcitrantes)
> --
> Cordialement, Stephane Ascoet


Disons, pour adoucir un peu la chose, que pour mon usage et sur les
machines dont je dispose, j'obtiens de meilleurs résutats avec suspend
to RAM pour les périodes courtes, et carrément poweroff suivi de
reboot quand c'est pour longtemps.
Sachant que ce n'est pas gravé dans le marbre si on me fournit un jour
une solution au fait que la machine se réveille systématiquement en
vrac de l'hibernation dès que les applications en cours consomment
beaucoup de RAM. La solution pouvant être une nouvelle version de l'OS
qui ne présente pas cet inconvénient, ou la publication de guidelines
pour améliorer le fonctionnement. Mais comme je ne vois pas trop ce
que l?hibernation me rapporte de plus qu'un powercycle complet (le
démarrage, aujoud'hui, c'est assez rapide pour mon usage), je ne suis
pas très motivé pour chercher ce qui ne va pas.

D'une manière générale sur un poste de travail, ça ne me gêne en aucun
cas de l'éteindre quand je m'en absente une heure ou plus, vu que dans
ce cas elle ne me sert pas ... L'hibernation pouvant être
éventuellement un dernier recours quand on travaille avec un portable
et qu'on tombe à cours de batterie.

Cordialement
______________
Éric Dégenètais
Stephane Ascoet (08/01/2019, 09h30)
Le 07/01/2019 à 15:49, roger.tarani a écrit :
> En résumé, on a :
> veille : suspend to ram
> hibernation : suspend to disk
> Il n'y a rien d'autre, je crois.


Bonjour, oh que si! C'est meme un vrai capharnaum! Il y a les modes ACPI
de S0 a S4, les modes du processeur, les vieux modes de mise en veille
APM, l'extinction des disques dur et eventuels peripheriques exotiques...

> Existe-t-il un mode qui permettrait de réduire la capacité de calcul de la machine ?


En permanence les micro-circuits inutilises sont mis en veille. Le
systeme peut aussi carrement diminuer sa vitesse, ca se produit en
particulier en cas de surchauffe.

> on baisse la fréq du processeur, on suspend tous les services non vitaux, on baisse la luminosité de l'écran, etc.


Pour le premier voir ci-dessus. Pour le second je ne connais pas. Pour
le troisieme ca doit pouvoir se regler sur les ordinateurs portables,
sur les fixes je n'ai jamais vu.

> La raison de mon utilisation de l'hibernation est simple : j'ai un environnement avec plein de trucs et de réglages et je ne maîtrise pas complètement l'enregistrement et donc la reprise de cette configuration avec tous ces trucs.
> Du coup, ça me prend du temps de tout ouvrir correctement à chaque démarrage (après lancement automatique des applications habituels).
> D'ailleurs, comment faites-vous pour traiter ce problème d'enregistrer la config au poil et de la retrouver au démarrage ?


Ben j'ai du mal a imaginer ce dont tu parles. Mais pour ma part aussi
j'exige un environnement qui me convienne a merveille et c'est pour ca
qu'utiliser un systeme non-Posix est devenu inimaginable pour moi, que
je suis retif a Systemd et tous les gros centrales nucleaires qu'on ne
controle pas completement. Quasiment tout peut se configurer dans les
fichiers qui vont bien, au pire quand ce n'est pas possible je cree des
scripts. Il me reste toutefois des millions de choses a ameliorer
la-dessus, j'y passe deja sans doute trop de temps et n'aurais pas assez
de ma vie...
Discussions similaires
Longue hibernation

Freeze sur sortie d'hibernation

Sortie d'hibernation


Fuseau horaire GMT +2. Il est actuellement 00h09. | Privacy Policy