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.
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
Oops : 600 aurais-je du écrire...
l'air de me créer un fichier toutes les 5 minutes:
10 minutes donc...
# 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 #
C'est bon, le fichier est bien mis à jour toutes les 10 minutes. Reste à savoir comment "lire" l'état de la mémoire toutes les 1à minutes.... la page de man (en anglais) me m'aide pas vraiment. --
T'as pas les chevilles qui enflent des fois ? Associer perl et "bon programmeur" c'est original.
Merde, ça s'est vu :) Pfff, vous devenez de plus en plus difficiles à coincer les gars :)
Le 01-05-2018, Hugolino <hugolino@free.fr> a écrit :
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
Oops : 600 aurais-je du écrire...
l'air de me créer un fichier toutes les 5 minutes:
10 minutes donc...
# 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 #
C'est bon, le fichier est bien mis à jour toutes les 10 minutes.
Reste à savoir comment "lire" l'état de la mémoire toutes les 1à
minutes.... la page de man (en anglais) me m'aide pas vraiment.
--
T'as pas les chevilles qui enflent des fois ? Associer perl et "bon
programmeur" c'est original.
Merde, ça s'est vu :) Pfff, vous devenez de plus en plus difficiles à
coincer les gars :)
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
Oops : 600 aurais-je du écrire...
l'air de me créer un fichier toutes les 5 minutes:
10 minutes donc...
# 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 #
C'est bon, le fichier est bien mis à jour toutes les 10 minutes. Reste à savoir comment "lire" l'état de la mémoire toutes les 1à minutes.... la page de man (en anglais) me m'aide pas vraiment. --
T'as pas les chevilles qui enflent des fois ? Associer perl et "bon programmeur" c'est original.
Merde, ça s'est vu :) Pfff, vous devenez de plus en plus difficiles à coincer les gars :)
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.
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.
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.
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. -- En informatique, ne pas installer Windows c'est déjà s'y connaître...
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.
--
En informatique, ne pas installer Windows c'est déjà s'y connaître...
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. -- En informatique, ne pas installer Windows c'est déjà s'y connaître...
Hugolino
Le 01-05-2018, Hugolino a écrit :
C'est bon, le fichier est bien mis à jour toutes les 10 minutes. Reste à savoir comment "lire" l'état de la mémoire toutes les 1à minutes.... la page de man (en anglais) me m'aide pas vraiment.
Même en anglais la page de man est claire : 't' pour voir le log suivant, "T" pour voir le précédent. Ça roxe. -- People claim that the UNIX learning curve is steep, but at least you only have to climb it once.
Le 01-05-2018, Hugolino <hugolino@free.fr> a écrit :
C'est bon, le fichier est bien mis à jour toutes les 10 minutes.
Reste à savoir comment "lire" l'état de la mémoire toutes les 1à
minutes.... la page de man (en anglais) me m'aide pas vraiment.
Même en anglais la page de man est claire : 't' pour voir le log
suivant, "T" pour voir le précédent.
Ça roxe.
--
People claim that the UNIX learning curve is steep, but at least you
only have to climb it once.
C'est bon, le fichier est bien mis à jour toutes les 10 minutes. Reste à savoir comment "lire" l'état de la mémoire toutes les 1à minutes.... la page de man (en anglais) me m'aide pas vraiment.
Même en anglais la page de man est claire : 't' pour voir le log suivant, "T" pour voir le précédent. Ça roxe. -- People claim that the UNIX learning curve is steep, but at least you only have to climb it once.
Jo Engo
Le Tue, 01 May 2018 22:20:56 +0200, Hugolino a écrit :
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:
Si j'ai bien suivi le film, atop ne crée pas un fichier à chaque fois mais chaque heure, et il le remplit avec plusieurs appels. -- L'infini est insaisissable par la connaissance scientifique. -+- Proclus, Commentaire à Euclide -+-
Le Tue, 01 May 2018 22:20:56 +0200, Hugolino a écrit :
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:
Si j'ai bien suivi le film, atop ne crée pas un fichier à chaque fois
mais chaque heure, et il le remplit avec plusieurs appels.
--
L'infini est insaisissable par la connaissance scientifique.
-+- Proclus, Commentaire à Euclide -+-
Le Tue, 01 May 2018 22:20:56 +0200, Hugolino a écrit :
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:
Si j'ai bien suivi le film, atop ne crée pas un fichier à chaque fois mais chaque heure, et il le remplit avec plusieurs appels. -- L'infini est insaisissable par la connaissance scientifique. -+- Proclus, Commentaire à Euclide -+-
