Liste des causes possibles de problèmes de performance sur des machines (Unix)

 

B. LISAN

4/9/05

 

Quels sont les causes de ces "embouteillages" sur les machines UNIX ?

 

Voici une première liste de causes possibles de goulots d'étranglements :

 

1) manque de ressources : manque de CPU, de ressource mémoire, de disque etc ... :

 

a) manque de CPU (des conflits de CPU peuvent être, très souvent, la source de goulots d'étranglement).

 

Note : Si l'on observe une utilisation élevée de CPU de façon constante, sur une certaine période de temps [1], cela peut indiquer une insuffisance de ressource CPU pour toutes les applications.

 

b) manque de mémoire RAM (une partie significative peut être passée dans le traitement des "défauts de page" (à la limite dans les situations de "trashing", le système passe son temps à gérer la mémoire virtuelle, sans aucun travail réel effectué ... ).

c) manque de swap (de mémoire virtuelle _ processus très consommateur de mémoire et ne la libérant pas).

d) non libération de ressources mémoires : segments mémoires (ipcs), sémaphores, mémoires partagées ... non libérées (liées à certaines applications ou progiciels qui ne les libèrent jamais _ par exemples, process java, weblogic ...).

 

2) problèmes de fragmentation disque importante.

 

2bis) problèmes de répartition des disques sur les contrôleurs disque disponibles.

(cas d'un seul disque avec un seul contrôleur).

 

3)  problème d'étranglement réseau.

 

4) Programme en attente d’une ressource (qui ne viendra jamais).

Suite à la disparition d’un processus, d’un time-out …

 

=> Solutions possibles :

 

a) conflits CPU :

 

a.1) favoriser certaines tâches par rapport à d'autres, en répartissant les ressources CPU par le biais de priorité de processus (utiliser pour cela la commande "nice" [2]).

 

a.2) si une demande CPU est supérieure de l'offre CPU de la machine => déplacer une partie de la charge système sur une autre machine moins chargée (voire vers une machine dédiée), exécuter certaines tâches consommatrice dans les heures creuses, via un système batch (traitement par lot ... _ On peut utiliser au minimum les commandes "at", "batch" [3]) ou sur un serveur dédié (serveur de mail, serveur MySQL ...)

 

a.3) modifier la méthode d'ordonnancement (par Ctrl-M etc ...), pour allouer les ressources en fonctions des tâches et des horaires.

     Par exemple, si à une heure donnée, il y a 2 gros processus consommant en même temps beaucoup de ressource mémoire, faire que l'une des tâche ait une priorité "nice" plus basse que l'autre.

 

a.5) autre solution plus coûteuse :augmenter la mémoire RAM.

 

a.6) voire avec certaines précautions (et après une analyse rigoureuse du phénomène),

 

- libérer les segments mémoire ipc, mémoire partagées (message queues ...), sémaphores _ ceux non libérés par des processus applicatifs ou progiciels (type weblogic, webmethode, java etc. ...) _ , par un processus "cron" lancé régulièrement.

 

- Sinon, il reste les reboots hebdomadaires, les WE, qui ne font jamais de mal aux machines LINUX.

 

b) Pour les problèmes de fragmentation disque,

 

- il existe des programmes de "restructuration" de fichier,

 

- et il en existe d'autres pour créer d'importants volumes d'espace contigu,

 

b.1) sinon, il faut ou faudrait répartir les fichiers les plus utilisés sur plusieurs disques (et aussi plusieurs contrôleurs).

 

b.2) dans tous les cas, surveiller la mémoire (par une "crontab" de l'utilisateur "root") avec des outil de surveillance (utilisant par exemple les commandes vmstat, sar, df, du, etc ...) [4], et envoyer des alertes à l'administrateur (j'aurais besoin alors éventuellement d'examiner la "crontab" "root", actuelle, de la machine),

 

c) voire faire que les traitements du programme incriminé aillent plus vite ou gèrent mieux la mémoire, par exemple, en réécrivant le traitement ou le programme en C (le C étant, par exemple, plus rapide que le PERL, ou le PL/SQL ou le PHP etc …) ...

Toutefois, concernant cette dernière solution, les inconvénients, et les risques de cette re-programmation du traitement en C étant :

- le manque de temps pour tout re-développer (si on a des délais trop courts),

- voire des problèmes d'interfaçage entre le programme C et la base utilisée et consultée, par ce programme _ sur cette machine, il y a juste les compilateurs 'cc" et "gcc"

et on ne sait pas s'ils possèdent des "include" d'interfaçage avec la base).

 

d) Solution des problèmes d’étranglements réseau :

 

Note : Une commande permettrait de détecter ces étranglements réseau :

sar -n DEV | EDEV | SOCK | FULL : qui fait un rapport des statistiques du réseau.

 

(En cas de blocages de l’envoie de mails (avec sendmail), vérifier aussi  le nombre de mail en attente de la commande mail : 

ls/var/spool/mail | wc -l ).

 

Benjamin LISAN

___________________________________________________________________________

 

Annexes :

 

[1]

Par exemple, si l'on voir avec "top" un taux de CPU utilisateur > 50 % pendant 30 mn :

 

# top

...

CPU states : 67.7% user, 14.7% system, 0.0 nice, 17,6% idle

..

 

Avec "vmstat intervalle [nombre]" . Par exemple, "vmstat 5 4" :

.... cpu

...  us sy id

...  63 11 16

...  72 28  0

...  78 22 0

...  63 37 0

 

Avec "sar 5 a " :

%usr %sys .... %idle

  79    7          0

  91    3          0

  98    1          0

  99    1          0

Avec

%usr : temps utilisateur

%sys : temps system

%idle : temps d'inactivité.

___________________________________________________________________________

 

[2] syntaxe (sous RedHat) : nice -n ajustement big_job   (big_job étant la commande a exécuter avec une priorité plus basse.  nice ajoute la valeur "ajustement" à la priorité de la commande, plutôt que la valeur 10 par défaut.  La priorité peut être ajustée avec nice dans l'intervalle -20 (le plus prioritaire) à 19 (le moins prioritaire).

 

Note : On vérifie la priorité réelle du processus big_job, ave le contenu de la colonne "PRI" de "ps -l" (l'option "-l" de la commande "ps" existe sur tous les UNIX y compris RedHat).

 

ps -l

  F S   UID   PID  PPID  C PRI  NI ADDR    SZ WCHAN  TTY          TIME CMD

100 S 10195  2199  2198  0  74   0    -   611 wait4  pts/10   00:00:00 bash

000 R 10195  5820  2199  0  79   0    -   801 -      pts/10   00:00:00 ps

___________________________________________________________________________

 

[3] at [-V] [-q queue] [-f file] [-mldbv] TIME

    at -c job [job...

    atq [-V] [-q queue]

    atrm [-V] job [job...]

    batch [-V] [-q queue] [-f file] [-mv] [TIME]

___________________________________________________________________________

 

 

 

[4]

 

a) comme "vmstat" :

 

Les colonnes à surveiller, avec "vmstat" (voir exemple ci-dessous, en fin de ce mail [6]) :

 

Colonnes Processus :

r: Nombre de processus en compétition pour le temps CPU (Nombre de processus prêt à l'exécution).

 b: Nombre de processus dormants, qu’on peut interrompre (interruptibles), (nombre de processus bloqués en attente d'entrées-sorties).

 

Colonnes Mémoire:

swpd: Quantité de mémoire virtuelle utilisée (ko) [Ndt: mémoire disponible - mémoire utilisé + swap utilisé ]

free: Quantité de mémoire [Ndt: physique !] libre (ko).

buff: Quantité de mémoire utilisée comme tampons d'E/S (ko).

 

Colonnes  Swap :

si: Quantité de mémoire paginé lue depuis un disque en ko/s.

so: Quantité de mémoire paginé transférée sur disque en ko/s (si > 0, le système swap ou pagine).

 

b) comme "sar"  avec les options :

-B : faire un rapport des statistiques des paginations.

 

Les colonnes à surveiller, avec "sar" : en particulier, la colonne : pgpgout/s : nombre total de blocks, que le system pagine vers le disque par seconde.

On compare les données de pagination, avec les résultats de la commande "free" qui donne a) la quantité de mémoire, l'utilisation courante de la mémoire et l'espace de pagination

(voir un exemple de cette commande en fin de ce mail [5]).

 

c) comme l'outil GNU "monitor" à installer et compiler sur la machine.

___________________________________________________________________________

 

[5]

 

free

                      total    used      free  shared    buffers     cached

Mem:                2064796 2047556     17240       0     208576    1396360

-/+ buffers/cache:           442620   1622176

Swap:               1024088  277272    746816

 

Note: "free" affiche les quantités totales de mémoire et de zone de swap libres et utilisées dans le système, ainsi que la mémoire partagée et les buffers utilisés par le noyau.

 

Options de "free" :

-b : affiche les quantités en octets, l'option -k en kilo-octets (affichage par défaut), et -m en méga-octets.

-t : affiche une ligne contenant le total de la mémoire du système.

-o : empêche l'affichage de la ligne des buffers. Sans cette option,  free soustrait/additionne la mémoire des buffers des quantités de mémoire utilisée/libre (respectivement).

-s  : active  un  affichage  continu toutes les nb_sec secondes.  En fait vous pouvez indiquer une valeur décimale pour nb_sec, puisque sleep(3) est utilisé pour obtenir un délai avec une résolution en micro-secondes.

___________________________________________________________________________

 

[6]

 

Exemple :

 

vmstat 5

   procs              memory    swap    io     system         cpu

 r  b  w   swpd   free   buff  cache  si so  bi  bo   in    cs  us  sy  id

 0  0  0 277272  11588 201980 1422412  0  0   4   0    0     1   1   1   4

 0  0  0 277272  11544 201988 1422400  0  0  46   6  128   292   0   1  99

 1  0  0 277272  11596 201992 1422384  0  0  51   2  147   299   0   1  98

 0  0  0 277272  11596 201992 1422376  0  0  51   4  149   294   0   2  98

 2  0  0 277272  11596 201992 1422368  0  0   0   2  109   280   1   7  92