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
Reply to: