[TUTO] Monitorer son système Linux
Modérateur : Francois
-
- Modérateur
- Messages : 790
- Enregistré le : dim. 16 nov. 2014 20:53
- Localisation : Charleroi - Belgique
[TUTO] Monitorer son système Linux
Bonjour à tous,
Ce post, est un sujet un peu spécial, c'est mon 100ème post, c'est la fête ...
Et je vais innover dans la présentation de mon sujet en tentant d'y insérer une navigation, ou du moins quelque chose qui y ressemble.
Cela vous donnera la possibilité de prendre les différentes informations avant la fin de l'écriture de cet article.
Cette nouveauté me donnera la possibilité d'augmenter le nombre de post ou de les modifier.
Les différentes commandes installées nativement sur le système :
ping
uptime
top
Les commandes intéressantes, mais pas encore installées sur le système :
htop
iftop
iotop
ethtool
Il existe également des systèmes de monitoring tel que :
Nagios
Incinga
Zabbix
Je ne les aborderai pas dans ce sujet.
Bonne soirée,
Ce post, est un sujet un peu spécial, c'est mon 100ème post, c'est la fête ...
Et je vais innover dans la présentation de mon sujet en tentant d'y insérer une navigation, ou du moins quelque chose qui y ressemble.
Cela vous donnera la possibilité de prendre les différentes informations avant la fin de l'écriture de cet article.
Cette nouveauté me donnera la possibilité d'augmenter le nombre de post ou de les modifier.
Les différentes commandes installées nativement sur le système :
ping
uptime
top
Les commandes intéressantes, mais pas encore installées sur le système :
htop
iftop
iotop
ethtool
Il existe également des systèmes de monitoring tel que :
Nagios
Incinga
Zabbix
Je ne les aborderai pas dans ce sujet.
Bonne soirée,
Modifié en dernier par maxty01 le mer. 25 févr. 2015 23:28, modifié 8 fois.
Il n'y a pas de question stupide, il n'y a que des imbéciles qui ne posent pas de question !
RaspBerry Pi : 1 x B+ Raspbian 1 x RPI2 MiniBian
Mieux me connaître ? Regarder mon LinkedIn
RaspBerry Pi : 1 x B+ Raspbian 1 x RPI2 MiniBian
Mieux me connaître ? Regarder mon LinkedIn
-
- Modérateur
- Messages : 790
- Enregistré le : dim. 16 nov. 2014 20:53
- Localisation : Charleroi - Belgique
[TUTO] Monitorer son système Linux - ping
Ping
Le ping, tout le monde connais, certes ...
Mais il est intéressant de connaître certaines subtilités afin de découvrir les différents problèmes qui peuvent survenir sur le réseau !
Ping permet de savoir si notre "pile réseau" fonctionne correctement :
C'est d'ailleurs une des raisons de l’existence du range 127.0.0.0/8.
Ping permet de savoir si nous sommes bien connecté sur notre réseau ...
Super, je ping correctement mon routeur.
Dans le cas ou vous avez aucun réponse :
Vérifier que vous avez reçu une MAC pour l'adresse que vous pinger :
Cela signifie simplement que l'équipement est joignable, mais ne répond pas au ping, typiquement, ce dernier est bloqué par un Firewall.
Par contre, si vous obtenez ce résultat :
Ceci signifie qu'aucun périphérique avec cette adresse n'est présent sur votre réseau.
Si vous obtenez cette erreur, et que vous êtes sur de l'adresse que vous essayez de pinger :
Vérifier vos paramètres réseaux.
Maintenant, vérifions si nous pouvons sortir de notre réseau grâce à notre routeur :
Si le ping est bloqué par un firewall nous obtenons ce résultat :
Si au contraire, vous obtenez ce résultat :
Cela signifie que votre système ne sais pas ou se trouve le réseau, typiquement, que la passerelle par défaut n'est pas configurée.
Le Test ultime, est le test des 4 paramètres réseaux afin d'obtenir internet :
L'adresse IP et le netmask pour dialoguer sur son réseau.
La passerelle par défaut pour sortir de son réseau.
Le DNS pour résoudre les noms de domaines en IP.
Le test :
C'est gagné.
Si vous obtenez ce résultat :
Vérifiez vos paramètres DNS dans le fichier /etc/resolv.conf
Si vous avez un problème réseau, vous pouvez effectuer ces différents tests dans le sens inverse de celui avec le quel je vous les ai présenté.
Le ping, tout le monde connais, certes ...
Mais il est intéressant de connaître certaines subtilités afin de découvrir les différents problèmes qui peuvent survenir sur le réseau !
Ping permet de savoir si notre "pile réseau" fonctionne correctement :
Code : Tout sélectionner
pi@raspberrypi ~ $ ping -c 4 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_req=1 ttl=64 time=0.181 ms
64 bytes from 127.0.0.1: icmp_req=2 ttl=64 time=0.165 ms
64 bytes from 127.0.0.1: icmp_req=3 ttl=64 time=0.148 ms
64 bytes from 127.0.0.1: icmp_req=4 ttl=64 time=0.151 ms
--- 127.0.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.148/0.161/0.181/0.015 ms
Ping permet de savoir si nous sommes bien connecté sur notre réseau ...
Code : Tout sélectionner
pi@raspberrypi ~ $ ping -c 4 192.168.0.254
PING 192.168.0.254 (192.168.0.254) 56(84) bytes of data.
64 bytes from 192.168.0.254: icmp_req=1 ttl=64 time=0.746 ms
64 bytes from 192.168.0.254: icmp_req=2 ttl=64 time=0.892 ms
64 bytes from 192.168.0.254: icmp_req=3 ttl=64 time=0.710 ms
64 bytes from 192.168.0.254: icmp_req=4 ttl=64 time=0.703 ms
--- 192.168.0.254 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.703/0.762/0.892/0.083 ms
Dans le cas ou vous avez aucun réponse :
Code : Tout sélectionner
pi@raspberrypi ~ $ ping -c 4 192.168.0.254
PING 192.168.0.254 (192.168.0.254) 56(84) bytes of data.
--- 192.168.0.254 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3008ms
Code : Tout sélectionner
pi@raspberrypi ~ $ arp -n 192.168.0.254
Address HWtype HWaddress Flags Mask Iface
192.168.0.254 ether ab:cd:ef:92:4f:c4 C eth0
Par contre, si vous obtenez ce résultat :
Code : Tout sélectionner
pi@raspberrypi ~ $ ping -c 4 192.168.0.150
PING 192.168.0.150 (192.168.0.150) 56(84) bytes of data.
From 192.168.0.1 icmp_seq=1 Destination Host Unreachable
From 192.168.0.1 icmp_seq=2 Destination Host Unreachable
From 192.168.0.1 icmp_seq=3 Destination Host Unreachable
From 192.168.0.1 icmp_seq=4 Destination Host Unreachable
--- 192.168.0.150 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3000ms
Si vous obtenez cette erreur, et que vous êtes sur de l'adresse que vous essayez de pinger :
Code : Tout sélectionner
pi@raspberrypi ~ $ ping 192.168.0.254
connect: Network is unreachable
Maintenant, vérifions si nous pouvons sortir de notre réseau grâce à notre routeur :
Code : Tout sélectionner
pi@raspberrypi ~ $ ping -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=53 time=32.0 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 32.087/32.087/32.087/0.000 ms
Code : Tout sélectionner
pi@raspberrypi ~ $ ping -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
Code : Tout sélectionner
pi@raspberrypi ~ $ ping 8.8.8.8
connect: Network is unreachable
Le Test ultime, est le test des 4 paramètres réseaux afin d'obtenir internet :
L'adresse IP et le netmask pour dialoguer sur son réseau.
La passerelle par défaut pour sortir de son réseau.
Le DNS pour résoudre les noms de domaines en IP.
Le test :
Code : Tout sélectionner
pi@raspberrypi ~ $ ping -c 4 www.google.be
PING www.google.be (74.125.133.94) 56(84) bytes of data.
64 bytes from 74.125.133.94: icmp_req=1 ttl=44 time=43.0 ms
64 bytes from 74.125.133.94: icmp_req=2 ttl=44 time=43.0 ms
64 bytes from 74.125.133.94: icmp_req=3 ttl=44 time=43.1 ms
64 bytes from 74.125.133.94: icmp_req=4 ttl=44 time=42.7 ms
--- www.google.be ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 42.770/43.011/43.171/0.147 ms
Si vous obtenez ce résultat :
Code : Tout sélectionner
pi@raspberrypi ~ $ ping -c 4 www.google.be
ping: unknown host www.google.be
Si vous avez un problème réseau, vous pouvez effectuer ces différents tests dans le sens inverse de celui avec le quel je vous les ai présenté.
Il n'y a pas de question stupide, il n'y a que des imbéciles qui ne posent pas de question !
RaspBerry Pi : 1 x B+ Raspbian 1 x RPI2 MiniBian
Mieux me connaître ? Regarder mon LinkedIn
RaspBerry Pi : 1 x B+ Raspbian 1 x RPI2 MiniBian
Mieux me connaître ? Regarder mon LinkedIn
-
- Modérateur
- Messages : 790
- Enregistré le : dim. 16 nov. 2014 20:53
- Localisation : Charleroi - Belgique
[TUTO] Monitorer son système Linux - uptime
uptime
Uptime, est un petit outils qui permet de connaître l'uptime d'un système Linux.
Mais ce n'est pas tout, il permet de connaître la charge système, et c'est sur cela que nous allons nous concentrer.
Décortiquons un peu la sortie de la commande :
23:40:37 : l'heure du système. Oui, il est tard.
up 36 days, 7:36 : cela fait 36 jours, 7 heures et 36 minutes que mon RPI est "au boulot".
1 user : un utilisateur est connecté sur le système.
load average: 0.37, 0.19, 0.16 : le load1, le load5 et le load15 du système.
Le Load Average est un savant calcul de différents paramètres systèmes tel que le CPU, RAM, I/O, NET, ... bref un mélange de différentes unités
Le Load Average ne possède pas d'unité, il est donc à l’appréciation de l'utilisateur, ou plutôt de l'administrateur système.
En Général, j'estime que un Load de 1.00 est équivalant à une charge de 100% pour un mono CPU mono core.
Mais au vue de limites du RPI, je redescendrai la barre à +/- 0.75 pour estimé que ce dernier est à 100%.
Pour un serveur, ayant de plus grandes capacités, il n'est pas rare de voir des Load Average atteindre 4.00, 8.00 voir 16.00, sans qu'aucun ralentissement ne ressente par l'utilisateur.
Il existe 3 Load Average qui se différencie par le "Temps".
Le Load1 est basé sur 1 minute, la valeur varie assez rapidement et fortement.
Le Load5 est basé sur 5 minutes, la valeur varie plus lentement et modérément.
Le Load15 est basé sur 15 minutes, la valeur varie très lentement et doucement.
En gros, si vous observez un Load de 1.00 sur votre RPI, dis-vous que vous avez un goulot d'étranglement dans votre système.
Uptime, est un petit outils qui permet de connaître l'uptime d'un système Linux.
Mais ce n'est pas tout, il permet de connaître la charge système, et c'est sur cela que nous allons nous concentrer.
Code : Tout sélectionner
pi@raspberrypi ~ $ uptime
23:40:37 up 36 days, 7:36, 1 user, load average: 0.37, 0.19, 0.16
23:40:37 : l'heure du système. Oui, il est tard.
up 36 days, 7:36 : cela fait 36 jours, 7 heures et 36 minutes que mon RPI est "au boulot".
1 user : un utilisateur est connecté sur le système.
load average: 0.37, 0.19, 0.16 : le load1, le load5 et le load15 du système.
Le Load Average est un savant calcul de différents paramètres systèmes tel que le CPU, RAM, I/O, NET, ... bref un mélange de différentes unités
Le Load Average ne possède pas d'unité, il est donc à l’appréciation de l'utilisateur, ou plutôt de l'administrateur système.
En Général, j'estime que un Load de 1.00 est équivalant à une charge de 100% pour un mono CPU mono core.
Mais au vue de limites du RPI, je redescendrai la barre à +/- 0.75 pour estimé que ce dernier est à 100%.
Pour un serveur, ayant de plus grandes capacités, il n'est pas rare de voir des Load Average atteindre 4.00, 8.00 voir 16.00, sans qu'aucun ralentissement ne ressente par l'utilisateur.
Il existe 3 Load Average qui se différencie par le "Temps".
Le Load1 est basé sur 1 minute, la valeur varie assez rapidement et fortement.
Le Load5 est basé sur 5 minutes, la valeur varie plus lentement et modérément.
Le Load15 est basé sur 15 minutes, la valeur varie très lentement et doucement.
En gros, si vous observez un Load de 1.00 sur votre RPI, dis-vous que vous avez un goulot d'étranglement dans votre système.
Il n'y a pas de question stupide, il n'y a que des imbéciles qui ne posent pas de question !
RaspBerry Pi : 1 x B+ Raspbian 1 x RPI2 MiniBian
Mieux me connaître ? Regarder mon LinkedIn
RaspBerry Pi : 1 x B+ Raspbian 1 x RPI2 MiniBian
Mieux me connaître ? Regarder mon LinkedIn
- vague nerd
- Modérateur
- Messages : 1473
- Enregistré le : mar. 14 oct. 2014 11:42
- Localisation : France !
Re: [TUTO] Monitorer son système Linux
Bonjour.
En tout cas, merci de votre contribution.
EDIT : Ne vous inquiétez pas de la pollution de votre thread. Si des discutions ont lieues, on pourra les déplacer, par exemple en fin de thread.
Sinon, pourquoi ne pas avoir fait plusieurs threads, 1 pour le sommaire et 1 pour chaque commande ou groupe de commande ? Ça vous aurait simplifié la gestion des retours (retour sur 1 commande, et non sur 1 commande parmi d'autres), et même la simple lecture. Qu'en pensez-vous ?
Cdt.
C'est malin, vous m'avez fait replonger dans zabbix !Zabbix
Je ne les aborderai pas dans ce sujet.
En tout cas, merci de votre contribution.
EDIT : Ne vous inquiétez pas de la pollution de votre thread. Si des discutions ont lieues, on pourra les déplacer, par exemple en fin de thread.
Sinon, pourquoi ne pas avoir fait plusieurs threads, 1 pour le sommaire et 1 pour chaque commande ou groupe de commande ? Ça vous aurait simplifié la gestion des retours (retour sur 1 commande, et non sur 1 commande parmi d'autres), et même la simple lecture. Qu'en pensez-vous ?
Cdt.
Cordialement,
Vague Nerd
Vague Nerd
-
- Modérateur
- Messages : 790
- Enregistré le : dim. 16 nov. 2014 20:53
- Localisation : Charleroi - Belgique
Re: [TUTO] Monitorer son système Linux
Bonsoir,
En fait, j'ai très peu d'expérience avec Zabbix, au boulot, c'est un collègue qui le gère.
Personnellement, j'ai plus facile avec Nagios et ses dérivés tel que icinga.
En ce qui concerne la proposition de multi threads, c'est une bonne idée de programmation ... Pardon ! C'est pas le bon sujet ...
En ce qui concerne la proposition de multi threads, en effet c'est une bonne idée, mais avant je vais terminer ce sujet avant de tester cette solution.
Par contre, j'avais vu un moment, l'option "verrouiller le sujet", enfin j'ai pensé que je l'avais rêvé puisque je ne l'ai pas retrouvé...
PS : pour la suite du sujet, il faudra attendre ... patience donc.
Bonne soirée,
En fait, j'ai très peu d'expérience avec Zabbix, au boulot, c'est un collègue qui le gère.
Personnellement, j'ai plus facile avec Nagios et ses dérivés tel que icinga.
En ce qui concerne la proposition de multi threads, c'est une bonne idée de programmation ... Pardon ! C'est pas le bon sujet ...
En ce qui concerne la proposition de multi threads, en effet c'est une bonne idée, mais avant je vais terminer ce sujet avant de tester cette solution.
Par contre, j'avais vu un moment, l'option "verrouiller le sujet", enfin j'ai pensé que je l'avais rêvé puisque je ne l'ai pas retrouvé...
PS : pour la suite du sujet, il faudra attendre ... patience donc.
Bonne soirée,
Il n'y a pas de question stupide, il n'y a que des imbéciles qui ne posent pas de question !
RaspBerry Pi : 1 x B+ Raspbian 1 x RPI2 MiniBian
Mieux me connaître ? Regarder mon LinkedIn
RaspBerry Pi : 1 x B+ Raspbian 1 x RPI2 MiniBian
Mieux me connaître ? Regarder mon LinkedIn
-
- Modérateur
- Messages : 790
- Enregistré le : dim. 16 nov. 2014 20:53
- Localisation : Charleroi - Belgique
[TUTO] Monitorer son système Linux - top
top
top est un outil de monitoring qui permet de connaître en temps "réel" la santé de son Linux.
Je vous l'avoue, ce n'est pas mon outil préféré, mais il a l'avantage d'être présent sur la majorité des Linux et des Unix.
J'ai une fois eu la surprise de le voir sur un Mac.
Voici à quoi il ressemble :
Prenons la première partie :
Cette partie permet d'avoir une vue globale du système.
Décortiquons un peu cette partie :
Cette ligne nous donnes exactement les mêmes informations que la commande uptime.
Je vous invite à (re)lire mon article sur cette commande.
Jetons un oeil sur le seconde ligne :
Cette seconde ligne nous informe sur le nombre de processus s’exécutant sur le système.
Nous savons, grâce à elle, que nous avons actuellement 64 Processus sur le système.
Nous savons qu'il n'y en a qu'un qui tourne.
Pour le RPI, nous n'aurons toujours 1, très rarement plus, car le RPI est un mono CPU mono Core.
Il n'est, par contre, pas rare de voir plus lorsque nous somme sur un système plus évolué.
Nous savons que 63 processus sont "endormi", ou plus précisément, attendent un créneau afin de pouvoir d’exécuté.
Si on regarde bien, 64 - 1 = 63 ... le compte y est !
Et pour finir, nous savons que nous avons 0 stoppé et 0 zombie.
Si vous découvrez qu'il y a des zombies sur votre système, au lieu de sortir la hache et le kit de survie ...
Posez-vous (ou plutpôt, pausez-NOUS) la question "pourquoi ai-je des processus zombie sur mon système?" nous y regarderons ensemble.
Analysons la troisième ligne :
Cette ligne nous donne les informations sur l'utilisation du CPU.
Comme on le sait tous, le CPU du RPI est limité, il serai agréable de préserver cette précieuse ressource.
Nous pouvons voir que :
3,3% est utilisé par les processus utilisateur.
5,6% est utilisé par le système.
0,0% est utilisé par les processus "privilégié/prioritaire".
89,7% est en "attente".
0,0% est utilisé pour les ressources d'entrée/sortie, typiquement, l'accès disque, réseau, mémoire, ...
0,0% est utilisé pour les interruptions systèmes.
1,3% est utilisé pour les interruptions logicielles.
0,0% est utilisé par un invité virtualisé, ce genre de cas est difficile avec un RPI.
Que nous apprend la quatrième ligne :
Elle nous donne des informations sur l'utilisation de la mémoire.
Nous avons :
382840 Ko utilisable par le système (~374 Mo)
348880 Ko utilisé par le système (~341 Mo)
33960 Ko libre pour le système (~33 Mo)
76972 Ko utilisé pour le buffering (~75 Mo), elle également comptabilisée dans la mémoire utilisée !
Et Mais ! On a pas nos 512 Mo (oui, c'est un B+) ...
Normale ! N'oubliez pas que le système réserve 128 Mo pour le GPU !
On fait le compte : 374 + 128 = 502 Mo. CQFD ! Et oui, les fabriquants de puce ne fournisse que très rarement la place promise.
Et la dernière ligne :
Elle nous informe sur l'état d'utilisation de la SWAP.
Nous savons que :
102396 Ko sont utilisables (~100 Mo)
0 Ko sont utilisés
102396 Ko sont libres (~100 Mo)
Petite astuce : Le dernier chiffre est relié à l'utilisation de la RAM.
Comme le Buffering, il y a une Cache créée par le système qui est également comptabilisée dans la mémoire utilisée !
Ici, nous avons 231580 Ko utilisée pour le Cache (~226 Mo).
Intéressons nous à la seconde partie de top :
Dans cette partie, nous avons les informations des principaux processus du système, le tout en colonne :
PID : est le Process IDentifier.
USER : est le propriétaire du processus.
PR: est la priorité d'ordonnancement du processus.
NI : est la priorité du processus.
VIRT : est la mémoire "virtuelle" utilisée.
RES : est la mémoire non swappée utilisée.
SHR : est la mémoire partagée utilisée.
S : est le statut du processus, c'est ici que l'on vois si c'est un zombie.
%CPU : est le pourcentage de CPU consommé par le processus.
%MEM : est le pourcentage de mémoire consommée par le processus.
TIME+ : est le temps en seconde CPU consommé par le processus.
COMMANDE : la commande du processus.
Ici nous pouvons voir que le processus 2710 de l'utilisateur pi consomme 6.9% de CPU et 3.1% de RAM,
Que celui-ci à consommé l’équivalent de 2632 Secondes de CPU et que sa commande est VLC.
A bientôt pour la suite.
top est un outil de monitoring qui permet de connaître en temps "réel" la santé de son Linux.
Je vous l'avoue, ce n'est pas mon outil préféré, mais il a l'avantage d'être présent sur la majorité des Linux et des Unix.
J'ai une fois eu la surprise de le voir sur un Mac.
Voici à quoi il ressemble :
Code : Tout sélectionner
top - 21:37:36 up 39 days, 5:33, 1 user, load average: 0.08, 0.11, 0.13
Tasks: 64 total, 1 running, 63 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.3 us, 5.6 sy, 0.0 ni, 89.7 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st
KiB Mem: 382840 total, 348880 used, 33960 free, 76972 buffers
KiB Swap: 102396 total, 0 used, 102396 free, 231580 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2710 pi 20 0 43804 11m 8704 S 6.9 3.1 2631:51 vlc
3 root 20 0 0 0 0 S 1.6 0.0 477:28.77 ksoftirqd/0
14308 pi 20 0 4700 1432 1036 R 0.7 0.4 0:00.37 top
1 root 20 0 2148 720 616 S 0.3 0.2 2:16.18 init
30 root 1 -19 0 0 0 S 0.3 0.0 296:19.20 VCHIQ-0
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
...
Code : Tout sélectionner
top - 21:37:36 up 39 days, 5:33, 1 user, load average: 0.08, 0.11, 0.13
Tasks: 64 total, 1 running, 63 sleeping, 0 stopped, 0 zombie
%Cpu(s): 3.3 us, 5.6 sy, 0.0 ni, 89.7 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st
KiB Mem: 382840 total, 348880 used, 33960 free, 76972 buffers
KiB Swap: 102396 total, 0 used, 102396 free, 231580 cached
Décortiquons un peu cette partie :
Code : Tout sélectionner
top - 21:37:36 up 39 days, 5:33, 1 user, load average: 0.08, 0.11, 0.13
Je vous invite à (re)lire mon article sur cette commande.
Jetons un oeil sur le seconde ligne :
Code : Tout sélectionner
Tasks: 64 total, 1 running, 63 sleeping, 0 stopped, 0 zombie
Nous savons, grâce à elle, que nous avons actuellement 64 Processus sur le système.
Nous savons qu'il n'y en a qu'un qui tourne.
Pour le RPI, nous n'aurons toujours 1, très rarement plus, car le RPI est un mono CPU mono Core.
Il n'est, par contre, pas rare de voir plus lorsque nous somme sur un système plus évolué.
Nous savons que 63 processus sont "endormi", ou plus précisément, attendent un créneau afin de pouvoir d’exécuté.
Si on regarde bien, 64 - 1 = 63 ... le compte y est !
Et pour finir, nous savons que nous avons 0 stoppé et 0 zombie.
Si vous découvrez qu'il y a des zombies sur votre système, au lieu de sortir la hache et le kit de survie ...
Posez-vous (ou plutpôt, pausez-NOUS) la question "pourquoi ai-je des processus zombie sur mon système?" nous y regarderons ensemble.
Analysons la troisième ligne :
Code : Tout sélectionner
%Cpu(s): 3.3 us, 5.6 sy, 0.0 ni, 89.7 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st
Comme on le sait tous, le CPU du RPI est limité, il serai agréable de préserver cette précieuse ressource.
Nous pouvons voir que :
3,3% est utilisé par les processus utilisateur.
5,6% est utilisé par le système.
0,0% est utilisé par les processus "privilégié/prioritaire".
89,7% est en "attente".
0,0% est utilisé pour les ressources d'entrée/sortie, typiquement, l'accès disque, réseau, mémoire, ...
0,0% est utilisé pour les interruptions systèmes.
1,3% est utilisé pour les interruptions logicielles.
0,0% est utilisé par un invité virtualisé, ce genre de cas est difficile avec un RPI.
Que nous apprend la quatrième ligne :
Code : Tout sélectionner
KiB Mem: 382840 total, 348880 used, 33960 free, 76972 buffers
Nous avons :
382840 Ko utilisable par le système (~374 Mo)
348880 Ko utilisé par le système (~341 Mo)
33960 Ko libre pour le système (~33 Mo)
76972 Ko utilisé pour le buffering (~75 Mo), elle également comptabilisée dans la mémoire utilisée !
Et Mais ! On a pas nos 512 Mo (oui, c'est un B+) ...
Normale ! N'oubliez pas que le système réserve 128 Mo pour le GPU !
On fait le compte : 374 + 128 = 502 Mo. CQFD ! Et oui, les fabriquants de puce ne fournisse que très rarement la place promise.
Et la dernière ligne :
Code : Tout sélectionner
KiB Swap: 102396 total, 0 used, 102396 free, 231580 cached
Nous savons que :
102396 Ko sont utilisables (~100 Mo)
0 Ko sont utilisés
102396 Ko sont libres (~100 Mo)
Petite astuce : Le dernier chiffre est relié à l'utilisation de la RAM.
Comme le Buffering, il y a une Cache créée par le système qui est également comptabilisée dans la mémoire utilisée !
Ici, nous avons 231580 Ko utilisée pour le Cache (~226 Mo).
Intéressons nous à la seconde partie de top :
Code : Tout sélectionner
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2710 pi 20 0 43804 11m 8704 S 6.9 3.1 2631:51 vlc
PID : est le Process IDentifier.
USER : est le propriétaire du processus.
PR: est la priorité d'ordonnancement du processus.
NI : est la priorité du processus.
VIRT : est la mémoire "virtuelle" utilisée.
RES : est la mémoire non swappée utilisée.
SHR : est la mémoire partagée utilisée.
S : est le statut du processus, c'est ici que l'on vois si c'est un zombie.
%CPU : est le pourcentage de CPU consommé par le processus.
%MEM : est le pourcentage de mémoire consommée par le processus.
TIME+ : est le temps en seconde CPU consommé par le processus.
COMMANDE : la commande du processus.
Ici nous pouvons voir que le processus 2710 de l'utilisateur pi consomme 6.9% de CPU et 3.1% de RAM,
Que celui-ci à consommé l’équivalent de 2632 Secondes de CPU et que sa commande est VLC.
A bientôt pour la suite.
Il n'y a pas de question stupide, il n'y a que des imbéciles qui ne posent pas de question !
RaspBerry Pi : 1 x B+ Raspbian 1 x RPI2 MiniBian
Mieux me connaître ? Regarder mon LinkedIn
RaspBerry Pi : 1 x B+ Raspbian 1 x RPI2 MiniBian
Mieux me connaître ? Regarder mon LinkedIn
- vague nerd
- Modérateur
- Messages : 1473
- Enregistré le : mar. 14 oct. 2014 11:42
- Localisation : France !
Re: [TUTO] Monitorer son système Linux
Bonjour. Merci de nouveau.
Une petite remarque :
Cdt.
Une petite remarque :
C'est la valeur par défaut, mais c'est configurable.N'oubliez pas que le système réserve 128 Mo pour le GPU !
Cdt.
Cordialement,
Vague Nerd
Vague Nerd
-
- Raspinaute
- Messages : 136
- Enregistré le : sam. 18 oct. 2014 19:09
Re: [TUTO] Monitorer son système Linux
Il serai donc intéressant de nous dire commentvague nerd a écrit :Bonjour. Merci de nouveau.
Une petite remarque :C'est la valeur par défaut, mais c'est configurable.N'oubliez pas que le système réserve 128 Mo pour le GPU !
Cdt.
- vague nerd
- Modérateur
- Messages : 1473
- Enregistré le : mar. 14 oct. 2014 11:42
- Localisation : France !
Re: [TUTO] Monitorer son système Linux
Ca se passe dans le /boot/config.txt avec des commandes comme
Mais ce n'est pas l'objet du thread !
Cdt.
Code : Tout sélectionner
gpu_mem=16
Cdt.
Cordialement,
Vague Nerd
Vague Nerd
-
- Modérateur
- Messages : 790
- Enregistré le : dim. 16 nov. 2014 20:53
- Localisation : Charleroi - Belgique
Re: [TUTO] Monitorer son système Linux
htop
htop est un top amélioré et surtout coloré, l'information est plus visible, plus lisible ...
Je peux épeingler certaines des améliorations aportées par htop :
Configuration aisée
Gestion de la souris, y compris avec un putty
tri en live
recherche de processus
Information claire
...
Avant toutes explications sur htop, il faut l'installer sur votre pi :
Et le lancer :
Attention, dans cette partie de l'article, je ne reviendrai pas sur l'explication des différents paramètres exposée, ses derniers sont identiques à top.
Ce ne sera pas un Tuto, mais une présentation de l'outil.
Voici htop lancé : Attention, j'ai modifié une partie de l'affichage pour mes besoins.
Voici mes différents htop pour vous donner une comparaison :
mon portable en mode configuration des indicateurs du dessus (meters) : Oui, c'est une petite bête, lol. [mode ventare : OFF]
Dans ce mode, vous pouvez choisir les différentes informations que vous pouvez afficher.
Mon Hyperviseur KVM en mode config des informations du "dessous" : Dans ce mode, vous pouvez choisir les informations sur les threads qui seront affichées.
Je me permets de vous faire remarquer certains points:
Le premier, tout le monde l'aura remarqué, la couleur est différentes ... aussi configurable.
Le second, l'apparition d'un paramètre en plus, le "gu :", le "guest", qui donne l'utilisation du CPU par les VM hostées sur ce serveur.
La configuration peut se faire via (F2)
Avec htop, vous pouvez également :
chercher un processus (F3)
filtrer vos processus (F4)
afficher les processus en mode "tree" (F5)
trier vos processus, selon la colonne choisie (F6)
stopper un processus (F9)
surligner un ou plusieurs processus (barre d'espace)
Tous ces menu sont accessible via un clique de la souris, essayez !
Essayez-le, vous serai conquis.
htop est un top amélioré et surtout coloré, l'information est plus visible, plus lisible ...
Je peux épeingler certaines des améliorations aportées par htop :
Configuration aisée
Gestion de la souris, y compris avec un putty
tri en live
recherche de processus
Information claire
...
Avant toutes explications sur htop, il faut l'installer sur votre pi :
Code : Tout sélectionner
pi@raspberrypi ~ $ sudo aptitude install htop
Code : Tout sélectionner
pi@raspberrypi ~ $ htop
Ce ne sera pas un Tuto, mais une présentation de l'outil.
Voici htop lancé : Attention, j'ai modifié une partie de l'affichage pour mes besoins.
Voici mes différents htop pour vous donner une comparaison :
mon portable en mode configuration des indicateurs du dessus (meters) : Oui, c'est une petite bête, lol. [mode ventare : OFF]
Dans ce mode, vous pouvez choisir les différentes informations que vous pouvez afficher.
Mon Hyperviseur KVM en mode config des informations du "dessous" : Dans ce mode, vous pouvez choisir les informations sur les threads qui seront affichées.
Je me permets de vous faire remarquer certains points:
Le premier, tout le monde l'aura remarqué, la couleur est différentes ... aussi configurable.
Le second, l'apparition d'un paramètre en plus, le "gu :", le "guest", qui donne l'utilisation du CPU par les VM hostées sur ce serveur.
La configuration peut se faire via (F2)
Avec htop, vous pouvez également :
chercher un processus (F3)
filtrer vos processus (F4)
afficher les processus en mode "tree" (F5)
trier vos processus, selon la colonne choisie (F6)
stopper un processus (F9)
surligner un ou plusieurs processus (barre d'espace)
Tous ces menu sont accessible via un clique de la souris, essayez !
Essayez-le, vous serai conquis.
Il n'y a pas de question stupide, il n'y a que des imbéciles qui ne posent pas de question !
RaspBerry Pi : 1 x B+ Raspbian 1 x RPI2 MiniBian
Mieux me connaître ? Regarder mon LinkedIn
RaspBerry Pi : 1 x B+ Raspbian 1 x RPI2 MiniBian
Mieux me connaître ? Regarder mon LinkedIn