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 :
https://superuser.com/questions/918106/debian-extremely-slow-resume-after-hibernate
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 rest is then loaded by the user-space applications themselves, as soon as 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.
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@tootai.net>
To: debian-user-french@lists.debian.org
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@free.fr 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.
>
> 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@free.fr>
> To: Liste Debian <debian-user-french@lists.debian.org>
> 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@free.fr> 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@pregonetwork.net>
> To: debian-user-french@lists.debian.org
> Sent: Saturday, December 29, 2018 12:14:13 PM
> Subject: Re: Firefox : mise à jour + blocage
>
> Le 29/12/2018 à 11:30, roger.tarani@free.fr 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
Éric Dégenètais