Comment surveiller l'utilisation / la performance de la memory dans SunOS / Solaris?

La semaine dernière, nous avons décidé d'append des machines SunOS ( uname -a = SunOS bbs-sam-belair 5.10 Generic_127128-11 i86pc i386 i86pc ) dans notre instance de Munin en cours d'exécution. Tout d'abord, les machines sont des appareils préconfigurés, de sorte que je souhaite éviter de toucher trop le système sans la supervision du fournisseur de services.

Mais l'ajout à Munin a été assez simple en écrivant un petit service-socket (si quelqu'un est intéressé, je l'ai mis sur github: https://github.com/munin-monitoring/consortingb/tree/master/tools/pypmmn )

Hier, j'ai mis en place / adapté les plugins requirejs pour nos machines. Et les questions commencent ici:

Tout d'abord, je n'ai pas trouvé de moyen de déterminer les valeurs détaillées de l'utilisation de la memory. Je reçois la memory totale en exécutant prtconf | grep Memory prtconf | grep Memory , et la memory libre en utilisant vmstat . Travailler set un plugin munin, me donne le graphique suivant:

Graphique de la mémoire SunOS

C'est assez peu informel. Comparez cela avec le plugin par défaut pour les nœuds linux qui présente beaucoup plus de détails:

Comparaison: un graphe de mémoire Linux

Plus important encore, cela me montre la quantité de memory utilisée par les applications.

Alors, première question: Est-il possible d'get des informations détaillées sur la memory de SunOS avec les outils système par défaut (c'est-à-dire ne pas utiliser le top )?


Sur le prochain puzzle: en voyant les charts, j'ai remarqué une activité dans les charts "Paging in / out", même si le graphe de memory contient encore une memory inutilisée :

PING INPaging OUT

Après une enquête plus approfondie, j'ai découvert que df rapporte que /tmp est monté sur swap . En train de forer sur le Web, j'ai compris que df affichera swap , mais en fait, il est monté comme un tmpfs . Maintenant, je ne sais pas si cela explique l'activité de swap.

Le plugin Munin par défaut pour kstat -p -c misc -m cpu_stat utilise kstat -p -c misc -m cpu_stat pour get ces valeurs. Je trouve déjà étrange que cela utilise le module cpu_stat . Alors, peut-être, je simplement mal interpréter les charts de «pagination»?

Deuxième question: Les charts de pagination indiquent-ils que les parties de la memory sont paginées sur le disque? Ou l'activité provoquée par les opérations de file dans /tmp ?

première question: Est-il possible d'get des informations détaillées sur la memory sur SunOS avec les outils système par défaut (c'est-à-dire ne pas utiliser le haut)?

Il est certainement possible d'get des statistics de memory détaillées et plus avec les outils standard de Solaris (SunOS n'est que le nom du kernel aujourd'hui). En plus de l' echo ::memstat | mdb -k déjà mentionné echo ::memstat | mdb -k echo ::memstat | mdb -k , vous pouvez avoir des statistics de memory par process et par user avec prstat -a et par zone avec prstat -Z .

Le kernel fournit également de nombreuses statistics via l'interface kstat (munin les utilise).

Par exemple, si vous souhaitez afficher la RAM totale, la partie utilisée par le kernel, par le cache ZFS (partie de la memory utilisée par le kernel) et la memory libre, vous pouvez exécuter cette command:

 kstat -T d -p :::physmem :::pp_kernel zfs:::size :::pagesfree 1 3 

Si vous cherchez l'utilisation de la memory virtuelle, utilisez la command swap -s .

Deuxième question: Les charts de pagination indiquent-ils que les parties de la memory sont paginées sur le disque? Ou l'activité provoquée par les opérations de file dans / tmp?

Aucune de ces réponses. Une telle activité ne signifie pas nécessairement un manque de RAM et de battement de page. Au contraire, votre graphique montre que la valeur sr rest à 0. Cela signifie que le scanner de page n'a pas d'activité et donc que vous avez suffisamment de RAM installée. L'activité de pagination est simplement due à la lecture et à l'écriture de files mappés en memory. Pas d'inquiétudes à avoir. Les files sur / tmp ne sont présents que dans la RAM (dans votre cas), de sorte qu'aucune pagination ne se produise lors de l'access.

Veillez à ce que Solaris utilise le terme swap pour nommer la partie du disque utilisée pour stocker les pages memory qui sont renvoyées de la RAM ou pour nommer l'espace entier de la memory virtuelle, c'est-à-dire la zone d'échange plus la partie de la RAM qui n'est pas verrouillée là-bas.

Pas aussi détaillé que votre exemple Linux, mais vous pouvez utiliser la macro :: memstat dans mdb :

 # echo ::memstat | mdb -k Page Summary Pages MB %Tot ------------ ---------------- ---------------- ---- Kernel 178001 1390 69% Anon 52748 412 21% Exec and libs 1905 14 1% Page cache 16115 125 6% Free (cachelist) 6654 51 3% Free (freelist) 1452 11 1% Total 256875 2006 Physical 255662 1997 

Kernel : memory utilisée pour les atsortingbutions de kernelx non utilisables

Anon : memory anonyme (tas de process, stack, partage de mappages de memory, etc., etc.)

Exec et libs : memory utilisée pour les files mappés comme les exécutables et les bibliothèques

Cache de la page : quantité de cache de la page non-mappée, y compris datatables stockées dans / tmp

Gratuit (cachelist) : quantité de cache de page sur la list gratuite, la majorité utilisée par les caches du système de files

Gratuit (freelist) : quantité de memory qui est en réalité vraiment gratuite

Les deux livres sur Solaris Internals (Solaris Internals, 2ème édition et Solaris Performance and Tools) de McDougall et Mauro sont extrêmement utiles pour comprendre Solaris et comment l'observer.