Comment mesurer les latences / goulets d'étranglement sous Linux

[Adrien Poupin]

Bonjour à tous,
Je voudrais faire quelques petites mesures sur les goulets d'étranglement de mon système :

• Comment mesurer les goulets d'étranglement logiciels (avec valgrind et autres je suppose) ;
• Comment mesurer les goulets d'étranglement matériels.
  

Si le load average mesure en moyenne le nombre de processus qui attendent, cela ne reflète pas ce qu'ils attendent. Parfois c'est un accès disque ou un accès à l'un des éléments matériels, parfois c'est simplement la vitesse du processeur qui est limitante.

Si j'ai bien compris, dès qu'il s'agit du processeur et de la mémoire on peut faire un profiling avec valgrind, mais je suppose qu'il n'y a pas que ça. Par exemple, je cherche à connaître les raisons principales pour lesquelles le démarrage de tel programme prend du temps, etc. : par exemple, est-ce que c'est l'accès disque, le bus qui est trop lent, le CPU, ...

Je sépare le logiciel et le hardware, mais les deux m'intéressent !

Si vous connaissez des outils utiles, je suis preneur !

--
Adrien
-------------------------------------------

[Sébastien NOBILI]

Le mardi 21 mai 2013 � 18:37, Adrien Poupin a �crit :
> Si j'ai bien compris, d�s qu'il s'agit du processeur et de la m�moire on

> peut faire un profiling avec valgrind, mais je suppose qu'il n'y a pas

> que �a. Par exemple, je cherche � conna�tre les raisons principales pour
> lesquelles le d�marrage de /tel/ programme prend du temps, etc. : par
> exemple, est-ce que c'est l'acc�s disque, le bus qui est trop lent, le
> CPU, ...

Avant d'aller analyser l'int�rieur du code avec valgrind, tu peux d�j� regarder
les appels syst�me d'un programme avec strace :
strace -p `pidof <nom_du_processus>`

Tu pourras avoir besoin d'aller voir dans /proc la liste des descripteurs de
fichiers ouverts :
ls -l /proc/`pidof <nom_du_processus>`/fd

C'est souvent amplement suffisant pour diagnostiquer l'origine d'un probl�me.

Seb

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-f...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listm...@lists.debian.org
Archive: http://lists.debian.org/20130521174...@serveur.nob900.homeip.net

[Adrien Poupin]

Le 21/05/2013 19:46, Sébastien NOBILI a écrit :

Le mardi 21 mai 2013 à 18:37, Adrien Poupin a écrit :

Si j'ai bien compris, dès qu'il s'agit du processeur et de la mémoire on
peut faire un profiling avec valgrind, mais je suppose qu'il n'y a pas
que ça. Par exemple, je cherche à connaître les raisons principales pour
lesquelles le démarrage de /tel/ programme prend du temps, etc. : par
exemple, est-ce que c'est l'accès disque, le bus qui est trop lent, le
CPU, ...

Avant d'aller analyser l'intérieur du code avec valgrind, tu peux déjà regarder
les appels système d'un programme avec strace :
    strace -p `pidof <nom_du_processus>`

Tu pourras avoir besoin d'aller voir dans /proc la liste des descripteurs de
fichiers ouverts :
    ls -l /proc/`pidof <nom_du_processus>`/fd

C'est souvent amplement suffisant pour diagnostiquer l'origine d'un problème.

Seb

Bonjour,
Merci de ta réponse. Je vais regarder ça. J'ai aussi vu qu'il existait un outil perf, ça m'a l'air moult intéressant tout ça...

--
Adrien
--

[jerome moliere]

Bonjour,

Je pense que tu devrais jeter un oeil aux tresors reveles par la commande lsof.

Elle devrait te plaire je pense..

Jerome

[Belaïd MOUNSI]

Les commandes ps, top, htop, iotop, lsof peuvent t'aider

[Belaïd MOUNSI]

Les commandes ps, top, htop, iotop, lsof peuvent t'aider