D'aucuns se souviendront peut-être de mon post
<slrnp6f268.mph.hugolino@Minty.Rock-n-Roll.org> du 23/01/2018 ici-même
ou je couinais d'une charge machine importante sur un PC qui ne fait
rien (il ne me sert que de serveur de sauvegarde, aussi ssh pour
l'administrer et serveur apache hors WAN, qui ne reçoit aucun hit).
J'ai remarqué que ce PC sous Linux Mint 18.3 à jour, qui ne fait
tourner que X.org et Cinnamon et un terminator avec un top consomme de
plus en plus de mémoire.
Et quand la mémoire est pleine et commence à taper dans le swap, alors
on observe des pics de charge toute les "un peu moins de deux heures".
Là, je viens de fermer et rouvrir ma session et 'free' raconte:
total utilisé libre partagé tamp/cache disponible
Mem: 3829952 608700 2017832 87944 1203420 2839012
Partition d'échange: 3998716 87920 3910796
'w' affiche:
22:43:39 up 9 days, 23:36, 5 users, load average: 0,07, 0,11, 0,17
UTIL. TTY DE LOGIN@ IDLE JCPU PCPU QUOI
hugo tty9 :0 21:38 9jours 10.18s 0.23s cinnamon-session
hugo pts/0 :0 21:39 1:04m 13.65s 13.58s top
hugo pts/1 :0 21:39 1:04m 0.10s 0.10s /bin/bash
hugo pts/2 :0 21:39 25:04 0.23s 8.24s /usr/bin/python /
hugo pts/3 192.168.1.24 22:41 0.00s 0.04s 0.00s w
D'ici deux jours (pendant lesquels je me toucherai pas à ce PC), je
posterai ici le résultat de ces deux commandes.
Mais d'ici-là, n'y aurait-il pas des pistes à investiguer pour expliquer
que la mémoire disponible diminue, et surtout que la charge augmente
jusqu'à rendre le PC inutilisable ?
Merci
--
> Vous pouvez toujours nous publier votre photo, que je puisse dire si vous
> représentez l'esthétique que l'étranger imagine de l'homme français
Vous parlez là à SM/Doom/Chibre<tulavu@moncul>. Précisez bien que vous
voulez une photo du visage.
Le Sat, 28 Apr 2018 22:47:49 +0200 Hugolino a écrit :
Yo! D'aucuns se souviendront peut-être de mon post du 23/01/2018 ici-même ou je couinais d'une charge machine importante sur un PC qui ne fait rien (il ne me sert que de serveur de sauvegarde, aussi ssh pour l'administrer et serveur apache hors WAN, qui ne reçoit aucun hit). J'ai remarqué que ce PC sous Linux Mint 18.3 à jour, qui ne fait tourner que X.org et Cinnamon et un terminator avec un top consomme de plus en plus de mémoire. Et quand la mémoire est pleine et commence à taper dans le swap, alors on observe des pics de charge toute les "un peu moins de deux heures". Là, je viens de fermer et rouvrir ma session et 'free' raconte: total utilisé libre partagé tamp/cache disponible Mem: 3829952 608700 2017832 87944 1203420 2839012 Partition d'échange: 3998716 87920 3910796 'w' affiche: 22:43:39 up 9 days, 23:36, 5 users, load average: 0,07, 0,11, 0,17 UTIL. TTY DE LOGIN@ IDLE JCPU PCPU QUOI hugo tty9 :0 21:38 9jours 10.18s 0.23s cinnamon-session hugo pts/0 :0 21:39 1:04m 13.65s 13.58s top hugo pts/1 :0 21:39 1:04m 0.10s 0.10s /bin/bash hugo pts/2 :0 21:39 25:04 0.23s 8.24s /usr/bin/python / hugo pts/3 192.168.1.24 22:41 0.00s 0.04s 0.00s w D'ici deux jours (pendant lesquels je me toucherai pas à ce PC), je posterai ici le résultat de ces deux commandes. Mais d'ici-là, n'y aurait-il pas des pistes à investiguer pour expliquer que la mémoire disponible diminue, et surtout que la charge augmente jusqu'à rendre le PC inutilisable ? Merci
top et Maj+M, pour voir (plus ou moins) la mémoire consommée par les différents processus et leur évolution au cours du temps ? Un script qui surveille la charge du processeur et, quand elle est élevée, stocke le résultat de top (pour la charge processeur) dans un fichier pour analyse ?
Le Sat, 28 Apr 2018 22:47:49 +0200
Hugolino <hugolino@free.fr> a écrit :
Yo!
D'aucuns se souviendront peut-être de mon post
<slrnp6f268.mph.hugolino@Minty.Rock-n-Roll.org> du 23/01/2018 ici-même
ou je couinais d'une charge machine importante sur un PC qui ne fait
rien (il ne me sert que de serveur de sauvegarde, aussi ssh pour
l'administrer et serveur apache hors WAN, qui ne reçoit aucun hit).
J'ai remarqué que ce PC sous Linux Mint 18.3 à jour, qui ne fait
tourner que X.org et Cinnamon et un terminator avec un top consomme de
plus en plus de mémoire.
Et quand la mémoire est pleine et commence à taper dans le swap, alors
on observe des pics de charge toute les "un peu moins de deux heures".
Là, je viens de fermer et rouvrir ma session et 'free' raconte:
total utilisé libre partagé tamp/cache
disponible Mem: 3829952 608700 2017832
87944 1203420 2839012 Partition d'échange: 3998716
87920 3910796
'w' affiche:
22:43:39 up 9 days, 23:36, 5 users, load average: 0,07, 0,11, 0,17
UTIL. TTY DE LOGIN@ IDLE JCPU PCPU QUOI
hugo tty9 :0 21:38 9jours 10.18s 0.23s
cinnamon-session hugo pts/0 :0 21:39 1:04m
13.65s 13.58s top hugo pts/1 :0 21:39 1:04m
0.10s 0.10s /bin/bash hugo pts/2 :0 21:39
25:04 0.23s 8.24s /usr/bin/python / hugo pts/3
192.168.1.24 22:41 0.00s 0.04s 0.00s w
D'ici deux jours (pendant lesquels je me toucherai pas à ce PC), je
posterai ici le résultat de ces deux commandes.
Mais d'ici-là, n'y aurait-il pas des pistes à investiguer pour
expliquer que la mémoire disponible diminue, et surtout que la charge
augmente jusqu'à rendre le PC inutilisable ?
Merci
top et Maj+M, pour voir (plus ou moins) la mémoire consommée par les
différents processus et leur évolution au cours du temps ?
Un script qui surveille la charge du processeur et, quand elle est
élevée, stocke le résultat de top (pour la charge processeur) dans un
fichier pour analyse ?
Le Sat, 28 Apr 2018 22:47:49 +0200 Hugolino a écrit :
Yo! D'aucuns se souviendront peut-être de mon post du 23/01/2018 ici-même ou je couinais d'une charge machine importante sur un PC qui ne fait rien (il ne me sert que de serveur de sauvegarde, aussi ssh pour l'administrer et serveur apache hors WAN, qui ne reçoit aucun hit). J'ai remarqué que ce PC sous Linux Mint 18.3 à jour, qui ne fait tourner que X.org et Cinnamon et un terminator avec un top consomme de plus en plus de mémoire. Et quand la mémoire est pleine et commence à taper dans le swap, alors on observe des pics de charge toute les "un peu moins de deux heures". Là, je viens de fermer et rouvrir ma session et 'free' raconte: total utilisé libre partagé tamp/cache disponible Mem: 3829952 608700 2017832 87944 1203420 2839012 Partition d'échange: 3998716 87920 3910796 'w' affiche: 22:43:39 up 9 days, 23:36, 5 users, load average: 0,07, 0,11, 0,17 UTIL. TTY DE LOGIN@ IDLE JCPU PCPU QUOI hugo tty9 :0 21:38 9jours 10.18s 0.23s cinnamon-session hugo pts/0 :0 21:39 1:04m 13.65s 13.58s top hugo pts/1 :0 21:39 1:04m 0.10s 0.10s /bin/bash hugo pts/2 :0 21:39 25:04 0.23s 8.24s /usr/bin/python / hugo pts/3 192.168.1.24 22:41 0.00s 0.04s 0.00s w D'ici deux jours (pendant lesquels je me toucherai pas à ce PC), je posterai ici le résultat de ces deux commandes. Mais d'ici-là, n'y aurait-il pas des pistes à investiguer pour expliquer que la mémoire disponible diminue, et surtout que la charge augmente jusqu'à rendre le PC inutilisable ? Merci
top et Maj+M, pour voir (plus ou moins) la mémoire consommée par les différents processus et leur évolution au cours du temps ? Un script qui surveille la charge du processeur et, quand elle est élevée, stocke le résultat de top (pour la charge processeur) dans un fichier pour analyse ?
Jo Engo
Le Sat, 28 Apr 2018 22:47:49 +0200, Hugolino a écrit :
des pistes à investiguer pour expliquer que la mémoire disponible diminue
Je n'ai pas ça dans ma besace, par contre htop t'indiquera qui utilise la mémoire (top aussi, mais l'interface d'htop est plus chouette) -- Les femmes sont de deux sortes: celles qui commandent et celles qui n'obéissent pas. -+- Georges Courteline -+-
Le Sat, 28 Apr 2018 22:47:49 +0200, Hugolino a écrit :
des pistes à investiguer pour expliquer que la mémoire disponible
diminue
Je n'ai pas ça dans ma besace, par contre htop t'indiquera qui utilise la
mémoire (top aussi, mais l'interface d'htop est plus chouette)
--
Les femmes sont de deux sortes:
celles qui commandent et celles qui n'obéissent pas.
-+- Georges Courteline -+-
Le Sat, 28 Apr 2018 22:47:49 +0200, Hugolino a écrit :
des pistes à investiguer pour expliquer que la mémoire disponible diminue
Je n'ai pas ça dans ma besace, par contre htop t'indiquera qui utilise la mémoire (top aussi, mais l'interface d'htop est plus chouette) -- Les femmes sont de deux sortes: celles qui commandent et celles qui n'obéissent pas. -+- Georges Courteline -+-
Jo Engo
Le Sun, 29 Apr 2018 07:33:05 +0000, Jo Engo a écrit :
Je n'ai pas ça dans ma besace, par contre htop t'indiquera qui utilise la mémoire (top aussi, mais l'interface d'htop est plus chouette)
wich htop || sudo apt install htop htop --sort-key=PERCENT_MEM (par contre je n'ai pas réussi à sortir les n premières lignes mais bon àmha les 2 premières te donneront un renseignement précieux.) -- J'aime les hommes qui ont de l'avenir et les femmes qui ont un passé. -+- Oscar Wilde -+-
Le Sun, 29 Apr 2018 07:33:05 +0000, Jo Engo a écrit :
Je n'ai pas ça dans ma besace, par contre htop t'indiquera qui utilise
la mémoire (top aussi, mais l'interface d'htop est plus chouette)
wich htop || sudo apt install htop
htop --sort-key=PERCENT_MEM
(par contre je n'ai pas réussi à sortir les n premières lignes mais bon
àmha les 2 premières te donneront un renseignement précieux.)
--
J'aime les hommes qui ont de l'avenir et les femmes qui ont un passé.
-+- Oscar Wilde -+-
Le Sun, 29 Apr 2018 07:33:05 +0000, Jo Engo a écrit :
Je n'ai pas ça dans ma besace, par contre htop t'indiquera qui utilise la mémoire (top aussi, mais l'interface d'htop est plus chouette)
wich htop || sudo apt install htop htop --sort-key=PERCENT_MEM (par contre je n'ai pas réussi à sortir les n premières lignes mais bon àmha les 2 premières te donneront un renseignement précieux.) -- J'aime les hommes qui ont de l'avenir et les femmes qui ont un passé. -+- Oscar Wilde -+-
Marc SCHAEFER
Hugolino wrote:
Mais d'ici-là, n'y aurait-il pas des pistes à investiguer pour expliquer que la mémoire disponible diminue, et surtout que la charge augmente jusqu'à rendre le PC inutilisable ?
Sur les machines que je veux surveiller, j'aime bien installer munin. Ca donne des graphes utiles, notamment pour la répartition de l'utilisation de la mémoire (occupée, cache, libre-gaspillée), la charge CPU, les I/O waits (avant-dernière colonne de `vmstat 5'), la performance disque, etc. D'un autre côté, un simple `vmstat 5' laissé un bon moment en marche donnera déjà des indices.
Hugolino <hugolino@free.fr> wrote:
Mais d'ici-là, n'y aurait-il pas des pistes à investiguer pour expliquer
que la mémoire disponible diminue, et surtout que la charge augmente
jusqu'à rendre le PC inutilisable ?
Sur les machines que je veux surveiller, j'aime bien installer munin.
Ca donne des graphes utiles, notamment pour la répartition de l'utilisation
de la mémoire (occupée, cache, libre-gaspillée), la charge CPU, les
I/O waits (avant-dernière colonne de `vmstat 5'), la performance
disque, etc.
D'un autre côté, un simple `vmstat 5' laissé un bon moment
en marche donnera déjà des indices.
Mais d'ici-là, n'y aurait-il pas des pistes à investiguer pour expliquer que la mémoire disponible diminue, et surtout que la charge augmente jusqu'à rendre le PC inutilisable ?
Sur les machines que je veux surveiller, j'aime bien installer munin. Ca donne des graphes utiles, notamment pour la répartition de l'utilisation de la mémoire (occupée, cache, libre-gaspillée), la charge CPU, les I/O waits (avant-dernière colonne de `vmstat 5'), la performance disque, etc. D'un autre côté, un simple `vmstat 5' laissé un bon moment en marche donnera déjà des indices.
Francois Lafont
Bonjour, On 04/28/2018 10:47 PM, Hugolino wrote:
D'ici deux jours (pendant lesquels je me toucherai pas à ce PC), je posterai ici le résultat de ces deux commandes.
Un petit outil que je trouve pas mal c'est atop. En gros c'est un top mais, sur Debian tout au moins, il est accompagné d'un daemon qui lance un atop (une sorte de top donc) toutes les N secondes (N est parfaitement paramétrable et je crois que c'est 300 secondes par défaut soit 5 minutes) et le résultat est ensuite stocké dans un log binaire. Du coup tu as une sorte de « photo atop » toutes les N secondes de ton système (avec une rétention de un mois je crois, toujours sur Debian). Par exemple sur une Debian, j'ai ça : ~$ ls -lt /var/log/atop/ | head total 46728 -rw-r--r-- 1 root root 878215 Apr 29 11:30 atop_20180429 -rw-r--r-- 1 root root 0 Apr 29 00:00 daily.log -rw-r--r-- 1 root root 1423254 Apr 29 00:00 atop_20180428 -rw-r--r-- 1 root root 2101106 Apr 28 00:00 atop_20180427 -rw-r--r-- 1 root root 1609835 Apr 27 00:00 atop_20180426 -rw-r--r-- 1 root root 1556174 Apr 26 00:00 atop_20180425 -rw-r--r-- 1 root root 1485714 Apr 25 00:00 atop_20180424 -rw-r--r-- 1 root root 1541866 Apr 24 00:00 atop_20180423 -rw-r--r-- 1 root root 1439835 Apr 23 00:00 atop_20180422 Le truc sympa, c'est que ces logs binaires sont lisibles avec la commande atop elle-même et tu peux faire « défiler les photos atop » pour te refaire le film en quelques sortes. _Des fois_, ça peut aider à voir à quel moment les choses sont parties en cacahuète et quel process est responsable etc. On peut diminuer l'intervalle entre les « photos atop » mais attention car du coup les logs binaires seront plus gros. Mais il y a de la marge : avec N = 300s sur une rétention de un mois, l'espace utilisé par ces logs n'excède pas les 50MB. À+ -- François Lafont
Bonjour,
On 04/28/2018 10:47 PM, Hugolino wrote:
D'ici deux jours (pendant lesquels je me toucherai pas à ce PC), je
posterai ici le résultat de ces deux commandes.
Un petit outil que je trouve pas mal c'est atop. En gros c'est un top
mais, sur Debian tout au moins, il est accompagné d'un daemon qui lance
un atop (une sorte de top donc) toutes les N secondes (N est parfaitement
paramétrable et je crois que c'est 300 secondes par défaut soit 5 minutes)
et le résultat est ensuite stocké dans un log binaire. Du coup tu as une
sorte de « photo atop » toutes les N secondes de ton système (avec une
rétention de un mois je crois, toujours sur Debian).
Le truc sympa, c'est que ces logs binaires sont lisibles avec la
commande atop elle-même et tu peux faire « défiler les photos atop »
pour te refaire le film en quelques sortes. _Des fois_, ça peut aider
à voir à quel moment les choses sont parties en cacahuète et quel
process est responsable etc.
On peut diminuer l'intervalle entre les « photos atop » mais attention
car du coup les logs binaires seront plus gros. Mais il y a de la
marge : avec N = 300s sur une rétention de un mois, l'espace utilisé
par ces logs n'excède pas les 50MB.
D'ici deux jours (pendant lesquels je me toucherai pas à ce PC), je posterai ici le résultat de ces deux commandes.
Un petit outil que je trouve pas mal c'est atop. En gros c'est un top mais, sur Debian tout au moins, il est accompagné d'un daemon qui lance un atop (une sorte de top donc) toutes les N secondes (N est parfaitement paramétrable et je crois que c'est 300 secondes par défaut soit 5 minutes) et le résultat est ensuite stocké dans un log binaire. Du coup tu as une sorte de « photo atop » toutes les N secondes de ton système (avec une rétention de un mois je crois, toujours sur Debian). Par exemple sur une Debian, j'ai ça : ~$ ls -lt /var/log/atop/ | head total 46728 -rw-r--r-- 1 root root 878215 Apr 29 11:30 atop_20180429 -rw-r--r-- 1 root root 0 Apr 29 00:00 daily.log -rw-r--r-- 1 root root 1423254 Apr 29 00:00 atop_20180428 -rw-r--r-- 1 root root 2101106 Apr 28 00:00 atop_20180427 -rw-r--r-- 1 root root 1609835 Apr 27 00:00 atop_20180426 -rw-r--r-- 1 root root 1556174 Apr 26 00:00 atop_20180425 -rw-r--r-- 1 root root 1485714 Apr 25 00:00 atop_20180424 -rw-r--r-- 1 root root 1541866 Apr 24 00:00 atop_20180423 -rw-r--r-- 1 root root 1439835 Apr 23 00:00 atop_20180422 Le truc sympa, c'est que ces logs binaires sont lisibles avec la commande atop elle-même et tu peux faire « défiler les photos atop » pour te refaire le film en quelques sortes. _Des fois_, ça peut aider à voir à quel moment les choses sont parties en cacahuète et quel process est responsable etc. On peut diminuer l'intervalle entre les « photos atop » mais attention car du coup les logs binaires seront plus gros. Mais il y a de la marge : avec N = 300s sur une rétention de un mois, l'espace utilisé par ces logs n'excède pas les 50MB. À+ -- François Lafont
Sergio
Le 29/04/2018 à 09:50, Marc SCHAEFER a écrit :
Sur les machines que je veux surveiller, j'aime bien installer munin. Ca donne des graphes utiles, notamment pour la répartition de l'utilisation de la mémoire (occupée, cache, libre-gaspillée), la charge CPU, les I/O waits (avant-dernière colonne de `vmstat 5'), la performance disque, etc.
Et on ne dira pas merci à la traduction française qui fout toutes les colonnes en l'air: $ vmstat 5 procs ----------mémoire---------- -échange- -----io---- -système- ------cpu----- r b swpd libre tampon cache si so bi bo in cs us sy id wa st 1 0 0 7962228 1602660 4674592 0 0 108 86 868 276 25 7 68 1 0 2 0 0 7962212 1602668 4674604 0 0 0 13 626 941 2 1 97 0 0 ... -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 29/04/2018 à 09:50, Marc SCHAEFER a écrit :
Sur les machines que je veux surveiller, j'aime bien installer munin.
Ca donne des graphes utiles, notamment pour la répartition de l'utilisation
de la mémoire (occupée, cache, libre-gaspillée), la charge CPU, les
I/O waits (avant-dernière colonne de `vmstat 5'), la performance
disque, etc.
Et on ne dira pas merci à la traduction française qui fout toutes les colonnes en l'air:
$ vmstat 5
procs ----------mémoire---------- -échange- -----io---- -système- ------cpu-----
r b swpd libre tampon cache si so bi bo in cs us sy id wa st
1 0 0 7962228 1602660 4674592 0 0 108 86 868 276 25 7 68 1 0
2 0 0 7962212 1602668 4674604 0 0 0 13 626 941 2 1 97 0 0
...
--
Serge http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Sur les machines que je veux surveiller, j'aime bien installer munin. Ca donne des graphes utiles, notamment pour la répartition de l'utilisation de la mémoire (occupée, cache, libre-gaspillée), la charge CPU, les I/O waits (avant-dernière colonne de `vmstat 5'), la performance disque, etc.
Et on ne dira pas merci à la traduction française qui fout toutes les colonnes en l'air: $ vmstat 5 procs ----------mémoire---------- -échange- -----io---- -système- ------cpu----- r b swpd libre tampon cache si so bi bo in cs us sy id wa st 1 0 0 7962228 1602660 4674592 0 0 108 86 868 276 25 7 68 1 0 2 0 0 7962212 1602668 4674604 0 0 0 13 626 941 2 1 97 0 0 ... -- Serge http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Pascal Hambourg
Le 29/04/2018 à 11:55, Sergio a écrit :
Et on ne dira pas merci à la traduction française qui fout toutes les colonnes en l'air: $ vmstat 5 procs ----------mémoire---------- -échange- -----io---- -système- ------cpu----- r b swpd libre tampon cache si so bi bo in cs us sy id wa st 1 0 0 7962228 1602660 4674592 0 0 108 86 868 276 25 7 68 1 0 2 0 0 7962212 1602668 4674604 0 0 0 13 626 941 2 1 97 0 0
Je n'ai pas l'impression que le décalage soit dû à la traduction car la disposition des colonnes de l'en-tête est identique en VO chez moi. Je pense plutôt que les largeurs de colonnes n'ont tout simplement pas été prévues pour des nombres aussi grands. Tu peux afficher les valeurs en Mo (-Sm) ou Mio (-SM) pour rétablir l'alignement.
Le 29/04/2018 à 11:55, Sergio a écrit :
Et on ne dira pas merci à la traduction française qui fout toutes les
colonnes en l'air:
$ vmstat 5
procs ----------mémoire---------- -échange- -----io---- -système- ------cpu-----
r b swpd libre tampon cache si so bi bo in cs us sy id wa st
1 0 0 7962228 1602660 4674592 0 0 108 86 868 276 25 7 68 1 0
2 0 0 7962212 1602668 4674604 0 0 0 13 626 941 2 1 97 0 0
Je n'ai pas l'impression que le décalage soit dû à la traduction car la
disposition des colonnes de l'en-tête est identique en VO chez moi. Je
pense plutôt que les largeurs de colonnes n'ont tout simplement pas été
prévues pour des nombres aussi grands. Tu peux afficher les valeurs en
Mo (-Sm) ou Mio (-SM) pour rétablir l'alignement.
Et on ne dira pas merci à la traduction française qui fout toutes les colonnes en l'air: $ vmstat 5 procs ----------mémoire---------- -échange- -----io---- -système- ------cpu----- r b swpd libre tampon cache si so bi bo in cs us sy id wa st 1 0 0 7962228 1602660 4674592 0 0 108 86 868 276 25 7 68 1 0 2 0 0 7962212 1602668 4674604 0 0 0 13 626 941 2 1 97 0 0
Je n'ai pas l'impression que le décalage soit dû à la traduction car la disposition des colonnes de l'en-tête est identique en VO chez moi. Je pense plutôt que les largeurs de colonnes n'ont tout simplement pas été prévues pour des nombres aussi grands. Tu peux afficher les valeurs en Mo (-Sm) ou Mio (-SM) pour rétablir l'alignement.
Hugolino
Le 29-04-2018, Yliur a écrit :
top et Maj+M, pour voir (plus ou moins) la mémoire consommée par les différents processus et leur évolution au cours du temps ?
Le processus qui bouffe la mémoire, je le connais : c'est cinammon.
Un script qui surveille la charge du processeur et, quand elle est élevée, stocke le résultat de top (pour la charge processeur) dans un fichier pour analyse ?
Je vais lancer atop comme conseillé par un autre contribruiteur. -- Il n'y a que trois sortes de gens : ceux qui savent compter et ceux qui ne savent pas. Hugo (né il y a 1 704 658 709 secondes)
Le 29-04-2018, Yliur <yliur@free.fr> a écrit :
top et Maj+M, pour voir (plus ou moins) la mémoire consommée par les
différents processus et leur évolution au cours du temps ?
Le processus qui bouffe la mémoire, je le connais : c'est cinammon.
Un script qui surveille la charge du processeur et, quand elle est
élevée, stocke le résultat de top (pour la charge processeur) dans un
fichier pour analyse ?
Je vais lancer atop comme conseillé par un autre contribruiteur.
--
Il n'y a que trois sortes de gens : ceux qui savent compter et ceux qui
ne savent pas.
Hugo (né il y a 1 704 658 709 secondes)
top et Maj+M, pour voir (plus ou moins) la mémoire consommée par les différents processus et leur évolution au cours du temps ?
Le processus qui bouffe la mémoire, je le connais : c'est cinammon.
Un script qui surveille la charge du processeur et, quand elle est élevée, stocke le résultat de top (pour la charge processeur) dans un fichier pour analyse ?
Je vais lancer atop comme conseillé par un autre contribruiteur. -- Il n'y a que trois sortes de gens : ceux qui savent compter et ceux qui ne savent pas. Hugo (né il y a 1 704 658 709 secondes)
pierre www.aribaut.com
Le 01/05/2018 à 21:49, Hugolino a écrit :
Le 29-04-2018, Yliur a écrit :
top et Maj+M, pour voir (plus ou moins) la mémoire consommée par les différents processus et leur évolution au cours du temps ?
Le processus qui bouffe la mémoire, je le connais : c'est cinammon.
Cela ne se produit pas avec Xfce ou Mate ? -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 01/05/2018 à 21:49, Hugolino a écrit :
Le 29-04-2018, Yliur <yliur@free.fr> a écrit :
top et Maj+M, pour voir (plus ou moins) la mémoire consommée par les
différents processus et leur évolution au cours du temps ?
Le processus qui bouffe la mémoire, je le connais : c'est cinammon.
Cela ne se produit pas avec Xfce ou Mate ?
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
top et Maj+M, pour voir (plus ou moins) la mémoire consommée par les différents processus et leur évolution au cours du temps ?
Le processus qui bouffe la mémoire, je le connais : c'est cinammon.
Cela ne se produit pas avec Xfce ou Mate ? -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Hugolino
Le 29-04-2018, Francois Lafont a écrit :
On 04/28/2018 10:47 PM, Hugolino wrote:
D'ici deux jours (pendant lesquels je me toucherai pas à ce PC), je posterai ici le résultat de ces deux commandes.
Trois jours plus tard : 'free' raconte : total utilisé libre partagé tamp/cache disponible Mem: 3829952 3256544 224940 70428 348468 232196 Partition d'échange: 3998716 597988 3400728
Un petit outil que je trouve pas mal c'est atop. En gros c'est un top mais, sur Debian tout au moins, il est accompagné d'un daemon qui lance un atop (une sorte de top donc) toutes les N secondes (N est parfaitement paramétrable et je crois que c'est 300 secondes par défaut soit 5 minutes) et le résultat est ensuite stocké dans un log binaire. Du coup tu as une sorte de « photo atop » toutes les N secondes de ton système (avec une rétention de un mois je crois, toujours sur Debian). Par exemple sur une Debian, j'ai ça : ~$ ls -lt /var/log/atop/ | head total 46728 -rw-r--r-- 1 root root 878215 Apr 29 11:30 atop_20180429 -rw-r--r-- 1 root root 0 Apr 29 00:00 daily.log -rw-r--r-- 1 root root 1423254 Apr 29 00:00 atop_20180428 -rw-r--r-- 1 root root 2101106 Apr 28 00:00 atop_20180427 -rw-r--r-- 1 root root 1609835 Apr 27 00:00 atop_20180426 -rw-r--r-- 1 root root 1556174 Apr 26 00:00 atop_20180425 -rw-r--r-- 1 root root 1485714 Apr 25 00:00 atop_20180424 -rw-r--r-- 1 root root 1541866 Apr 24 00:00 atop_20180423 -rw-r--r-- 1 root root 1439835 Apr 23 00:00 atop_20180422 Le truc sympa, c'est que ces logs binaires sont lisibles avec la commande atop elle-même et tu peux faire « défiler les photos atop » pour te refaire le film en quelques sortes. _Des fois_, ça peut aider à voir à quel moment les choses sont parties en cacahuète et quel process est responsable etc.
C'est exactement ce qu'il me fallait: 'atop -m' donne : ATOP - Dottore 2018/05/01 22:04:13 ------ 10s elapsed PRC | sys 0.44s | user 0.33s | #proc 250 | #zombie 0 | #exit 2 | CPU | sys 4% | user 4% | irq 0% | idle 391% | wait 1% | cpu | sys 2% | user 3% | irq 0% | idle 95% | cpu002 w 0% | cpu | sys 3% | user 0% | irq 0% | idle 97% | cpu001 w 0% | cpu | sys 0% | user 0% | irq 0% | idle 100% | cpu000 w 0% | cpu | sys 0% | user 0% | irq 0% | idle 99% | cpu003 w 1% | CPL | avg1 0.08 | avg5 0.14 | avg15 0.17 | csw 2885 | intr 1943 | <ces deux lignes suivantes en rouge qui selon la page de man signale un problème> MEM | tot 3.7G | free 217.9M | cache 213.2M | buff 38.5M | slab 89.0M | SWP | tot 3.8G | free 3.2G | | vmcom 5.8G | vmlim 5.6G | DSK | sda | busy 1% | read 0 | write 20 | avio 5.40 ms | NET | transport | tcpi 6 | tcpo 5 | udpi 4 | udpo 12 | NET | network | ipi 27 | ipo 26 | ipfrw 0 | deliv 24 | NET | wlp5s0 ---- | pcki 14 | pcko 12 | si 1 Kbps | so 3 Kbps | NET | lo ---- | pcki 12 | pcko 12 | si 0 Kbps | so 0 Kbps | PID MINFLT MAJFLT VSTEXT VSIZE RSIZE VGROW RGROW RUID EUID MEM CMD 1/1 12923 7948 0 9K 5.0G 2.8G 64K 20K hugo hugo 78% cinnamon 12489 0 0 2286K 344.9M 27520K 0K 0K root root 1% Xorg 29947 173 0 148K 25564K 5124K 8712K 660K root root 0% atop 13558 0 0 95K 42092K 2796K 0K 0K hugo hugo 0% top 974 0 0 3734K 265.1M 504K 0K 0K root root 0% php-fpm7.0 8 0 0 0K 0K 0K 0K 0K root root 0% rcu_sched 321 0 0 0K 0K 0K 0K 0K root root 0% jbd2/sda6-8 1029 0 0 0K 0K 0K 0K 0K root root 0% nfsd 14238 0 0 0K 0K 0K 0K 0K root root 0% kworker/1:3 28420 0 0 0K 0K 0K 0K 0K root root 0% kworker/u16:2 28821 0 0 0K 0K 0K 0K 0K root root 0% kworker/u16:1 29950 0 0 0K 0K 0K 0K 0K root root 0% kworker/1:1 29949 196 0 0K 0K 0K 0K 0K hugo - 0% <sensors> 29951 199 0 0K 0K 0K 0K 0K hugo - 0% <sensors> Donc sur mes 4 Go de RAM, trois jours seulement après avoir relancé la session cinnamon, elle occupe plus de 3 Go (et je sais par expérience que lorsque cette session tapera dans le swap, la charge commencera a augmenter pour rendre le PC difficilement utilisable (demain donc si la croissance de l'occupation mémoire est linéaire au cours du temps). Merci pour cet outil. Question : j'ai lancé un "/etc/init.d/atop start" après l'installation, ça va suffire à me remplir /var/log/atop ? J'ai laissé un délai de 300 dans /etc/default/atop, mais ça n'a pas l'air de me créer un fichier toutes les 5 minutes: # ll total 64 64 -rw-r--r-- 1 root root 65047 mar. 01/05/2018 22:11:03 atop_20180501 0 -rw-r--r-- 1 root root 0 mar. 01/05/2018 22:11:03 daily.log 22:20:25 /var/log/atop # -- Un vibromasseur ne vous téléphone pas pour votre anniversaire. Un vibromasseur ne vous envoie pas de fleurs. Et vous ne pouvez pas le présenter à votre mère. Hugo (né il y a 1 704 660 421 secondes)
Le 29-04-2018, Francois Lafont <francois.lafont@nospam.invalid> a écrit :
On 04/28/2018 10:47 PM, Hugolino wrote:
D'ici deux jours (pendant lesquels je me toucherai pas à ce PC), je
posterai ici le résultat de ces deux commandes.
Trois jours plus tard :
'free' raconte :
total utilisé libre partagé tamp/cache disponible
Mem: 3829952 3256544 224940 70428 348468 232196
Partition d'échange: 3998716 597988 3400728
Un petit outil que je trouve pas mal c'est atop. En gros c'est un top
mais, sur Debian tout au moins, il est accompagné d'un daemon qui lance
un atop (une sorte de top donc) toutes les N secondes (N est parfaitement
paramétrable et je crois que c'est 300 secondes par défaut soit 5 minutes)
et le résultat est ensuite stocké dans un log binaire. Du coup tu as une
sorte de « photo atop » toutes les N secondes de ton système (avec une
rétention de un mois je crois, toujours sur Debian).
Le truc sympa, c'est que ces logs binaires sont lisibles avec la
commande atop elle-même et tu peux faire « défiler les photos atop »
pour te refaire le film en quelques sortes. _Des fois_, ça peut aider
à voir à quel moment les choses sont parties en cacahuète et quel
process est responsable etc.
C'est exactement ce qu'il me fallait:
'atop -m' donne :
ATOP - Dottore 2018/05/01 22:04:13 ------ 10s elapsed
PRC | sys 0.44s | user 0.33s | #proc 250 | #zombie 0 | #exit 2 |
CPU | sys 4% | user 4% | irq 0% | idle 391% | wait 1% |
cpu | sys 2% | user 3% | irq 0% | idle 95% | cpu002 w 0% |
cpu | sys 3% | user 0% | irq 0% | idle 97% | cpu001 w 0% |
cpu | sys 0% | user 0% | irq 0% | idle 100% | cpu000 w 0% |
cpu | sys 0% | user 0% | irq 0% | idle 99% | cpu003 w 1% |
CPL | avg1 0.08 | avg5 0.14 | avg15 0.17 | csw 2885 | intr 1943 |
<ces deux lignes suivantes en rouge qui selon la page de man signale un
problème>
MEM | tot 3.7G | free 217.9M | cache 213.2M | buff 38.5M | slab 89.0M |
SWP | tot 3.8G | free 3.2G | | vmcom 5.8G | vmlim 5.6G |
DSK | sda | busy 1% | read 0 | write 20 | avio 5.40 ms |
NET | transport | tcpi 6 | tcpo 5 | udpi 4 | udpo 12 |
NET | network | ipi 27 | ipo 26 | ipfrw 0 | deliv 24 |
NET | wlp5s0 ---- | pcki 14 | pcko 12 | si 1 Kbps | so 3 Kbps |
NET | lo ---- | pcki 12 | pcko 12 | si 0 Kbps | so 0 Kbps |
Donc sur mes 4 Go de RAM, trois jours seulement après avoir relancé la
session cinnamon, elle occupe plus de 3 Go (et je sais par expérience
que lorsque cette session tapera dans le swap, la charge commencera a
augmenter pour rendre le PC difficilement utilisable (demain donc si la
croissance de l'occupation mémoire est linéaire au cours du temps).
Merci pour cet outil.
Question : j'ai lancé un "/etc/init.d/atop start" après l'installation,
ça va suffire à me remplir /var/log/atop ?
J'ai laissé un délai de 300 dans /etc/default/atop, mais ça n'a pas
l'air de me créer un fichier toutes les 5 minutes:
# ll
total 64
64 -rw-r--r-- 1 root root 65047 mar. 01/05/2018 22:11:03 atop_20180501
0 -rw-r--r-- 1 root root 0 mar. 01/05/2018 22:11:03 daily.log
22:20:25 r00t@Dottore /var/log/atop #
--
Un vibromasseur ne vous téléphone pas pour votre anniversaire.
Un vibromasseur ne vous envoie pas de fleurs.
Et vous ne pouvez pas le présenter à votre mère.
Hugo (né il y a 1 704 660 421 secondes)
D'ici deux jours (pendant lesquels je me toucherai pas à ce PC), je posterai ici le résultat de ces deux commandes.
Trois jours plus tard : 'free' raconte : total utilisé libre partagé tamp/cache disponible Mem: 3829952 3256544 224940 70428 348468 232196 Partition d'échange: 3998716 597988 3400728
Un petit outil que je trouve pas mal c'est atop. En gros c'est un top mais, sur Debian tout au moins, il est accompagné d'un daemon qui lance un atop (une sorte de top donc) toutes les N secondes (N est parfaitement paramétrable et je crois que c'est 300 secondes par défaut soit 5 minutes) et le résultat est ensuite stocké dans un log binaire. Du coup tu as une sorte de « photo atop » toutes les N secondes de ton système (avec une rétention de un mois je crois, toujours sur Debian). Par exemple sur une Debian, j'ai ça : ~$ ls -lt /var/log/atop/ | head total 46728 -rw-r--r-- 1 root root 878215 Apr 29 11:30 atop_20180429 -rw-r--r-- 1 root root 0 Apr 29 00:00 daily.log -rw-r--r-- 1 root root 1423254 Apr 29 00:00 atop_20180428 -rw-r--r-- 1 root root 2101106 Apr 28 00:00 atop_20180427 -rw-r--r-- 1 root root 1609835 Apr 27 00:00 atop_20180426 -rw-r--r-- 1 root root 1556174 Apr 26 00:00 atop_20180425 -rw-r--r-- 1 root root 1485714 Apr 25 00:00 atop_20180424 -rw-r--r-- 1 root root 1541866 Apr 24 00:00 atop_20180423 -rw-r--r-- 1 root root 1439835 Apr 23 00:00 atop_20180422 Le truc sympa, c'est que ces logs binaires sont lisibles avec la commande atop elle-même et tu peux faire « défiler les photos atop » pour te refaire le film en quelques sortes. _Des fois_, ça peut aider à voir à quel moment les choses sont parties en cacahuète et quel process est responsable etc.
C'est exactement ce qu'il me fallait: 'atop -m' donne : ATOP - Dottore 2018/05/01 22:04:13 ------ 10s elapsed PRC | sys 0.44s | user 0.33s | #proc 250 | #zombie 0 | #exit 2 | CPU | sys 4% | user 4% | irq 0% | idle 391% | wait 1% | cpu | sys 2% | user 3% | irq 0% | idle 95% | cpu002 w 0% | cpu | sys 3% | user 0% | irq 0% | idle 97% | cpu001 w 0% | cpu | sys 0% | user 0% | irq 0% | idle 100% | cpu000 w 0% | cpu | sys 0% | user 0% | irq 0% | idle 99% | cpu003 w 1% | CPL | avg1 0.08 | avg5 0.14 | avg15 0.17 | csw 2885 | intr 1943 | <ces deux lignes suivantes en rouge qui selon la page de man signale un problème> MEM | tot 3.7G | free 217.9M | cache 213.2M | buff 38.5M | slab 89.0M | SWP | tot 3.8G | free 3.2G | | vmcom 5.8G | vmlim 5.6G | DSK | sda | busy 1% | read 0 | write 20 | avio 5.40 ms | NET | transport | tcpi 6 | tcpo 5 | udpi 4 | udpo 12 | NET | network | ipi 27 | ipo 26 | ipfrw 0 | deliv 24 | NET | wlp5s0 ---- | pcki 14 | pcko 12 | si 1 Kbps | so 3 Kbps | NET | lo ---- | pcki 12 | pcko 12 | si 0 Kbps | so 0 Kbps | PID MINFLT MAJFLT VSTEXT VSIZE RSIZE VGROW RGROW RUID EUID MEM CMD 1/1 12923 7948 0 9K 5.0G 2.8G 64K 20K hugo hugo 78% cinnamon 12489 0 0 2286K 344.9M 27520K 0K 0K root root 1% Xorg 29947 173 0 148K 25564K 5124K 8712K 660K root root 0% atop 13558 0 0 95K 42092K 2796K 0K 0K hugo hugo 0% top 974 0 0 3734K 265.1M 504K 0K 0K root root 0% php-fpm7.0 8 0 0 0K 0K 0K 0K 0K root root 0% rcu_sched 321 0 0 0K 0K 0K 0K 0K root root 0% jbd2/sda6-8 1029 0 0 0K 0K 0K 0K 0K root root 0% nfsd 14238 0 0 0K 0K 0K 0K 0K root root 0% kworker/1:3 28420 0 0 0K 0K 0K 0K 0K root root 0% kworker/u16:2 28821 0 0 0K 0K 0K 0K 0K root root 0% kworker/u16:1 29950 0 0 0K 0K 0K 0K 0K root root 0% kworker/1:1 29949 196 0 0K 0K 0K 0K 0K hugo - 0% <sensors> 29951 199 0 0K 0K 0K 0K 0K hugo - 0% <sensors> Donc sur mes 4 Go de RAM, trois jours seulement après avoir relancé la session cinnamon, elle occupe plus de 3 Go (et je sais par expérience que lorsque cette session tapera dans le swap, la charge commencera a augmenter pour rendre le PC difficilement utilisable (demain donc si la croissance de l'occupation mémoire est linéaire au cours du temps). Merci pour cet outil. Question : j'ai lancé un "/etc/init.d/atop start" après l'installation, ça va suffire à me remplir /var/log/atop ? J'ai laissé un délai de 300 dans /etc/default/atop, mais ça n'a pas l'air de me créer un fichier toutes les 5 minutes: # ll total 64 64 -rw-r--r-- 1 root root 65047 mar. 01/05/2018 22:11:03 atop_20180501 0 -rw-r--r-- 1 root root 0 mar. 01/05/2018 22:11:03 daily.log 22:20:25 /var/log/atop # -- Un vibromasseur ne vous téléphone pas pour votre anniversaire. Un vibromasseur ne vous envoie pas de fleurs. Et vous ne pouvez pas le présenter à votre mère. Hugo (né il y a 1 704 660 421 secondes)
