Discussion :

[Antoun]

Bonjour à tous,

Je suis chargé de faire des optimisations sur un SGBD multidimensionnel (Oracle Essbase), qui est hébergé sur une machine virtuelle en AIX, qui serait sur du "SunOS 5.10". Habituellement, je travaille sur des environnement Windows et je ne connais rien à Unix, donc je bloque sur les trucs de base

J'aurais besoin de connaître la taille totale de la mémoire vive de la VM. Je m'y suis connecté avec putty, et apparemment j'utilise du Korn Shell (en tout cas les messages d'erreur commencent par ksh:). J'ai pas mal ramé et fini par tomber sur la commande vmstat, qui me donne le résultat suivant :

kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr m0 m1 m3 m4 in sy cs us sy id
0 0 0 26884368 10162160 52 73 235 0 0 0 0 5 21 1 0 147 45084 220 6 3 91

Par contre je galère beaucoup pour interpréter ce résultat... j'aurais tendance à comprendre que la mémoire totale est swap + free, soit 37 047 080 ko, mais je doute beaucoup de ce résultat...

Comment faut-il interpréter le résultat de vmstat ? Y a-t-il une autre commande que serait plus appropriée ?

Question subsidiaire : je vais ensuite avoir besoin de savoir combien de CPU sont disponibles... Je suis tombé sur la commande mpstat, donc on me dit qu'elle donne des statistiques par CPU, donc je dis que le nombre de lignes va me donner le nombre de CPU... Sauf que j'ai un serveur où, d'un instant à l'autre, le nombre de lignes renvoyées par le mpstat varie de 1 à 3 ! Je sens que je bute sur un truc du genre les CPU réelles et virtuelles, mais j'aurais bien besoin de quelques éclaircissements...

[frp31]

si tu as "top" comme commande sur ta VM c'est pratique tu as l'instantané ... "q" pour quitter bien sur.

si tu as beaucoup de chance tu as peut être la commande "free" ...

sinon tu as peut etre ptrdiag comme commande ou encore ptrcong

[jlliagre]

Je suis chargé de faire des optimisations sur un SGBD multidimensionnel (Oracle Essbase), qui est hébergé sur une machine virtuelle en AIX, qui serait sur du "SunOS 5.10".

Pas possible, AIX ne peut pas héberger une VM SunOS 5.10 (= Solaris 10), l'inverse n'est pas possible non plus.

Que te dis:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

uname -a

?

S'il y a écrit SunOS, il faudrait déplacer ce thread dans le forum Solaris.

Pour connaître la taille totale de la RAM, essaie dans ce cas:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

prtconf|head -5

et pour les CPU:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

psrinfo -v | grep -v virtual | uniq -c

Quel que soit l'OS, tu as 10 GO de RAM libre et 27 GO de mémoire virtuelle disponible.

[gangsoleil]

Bonjour,

Sous AIX (c'est a dire si uname -a te repond AIX), tu as les commandes suivantes :
Pour la RAM :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
prtconf | grep -i memory

Pour le CPU :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
prtconf | grep -i Processor

[Antoun]

Merci pour toutes vos réponses, et mes excuses pour les quelques jours de silence : j'étais chez un autre client et je ne pouvais rien tester.

Voici le résultat du uname... Je crois qu'il va falloir déplacer

SunOS mrub001 5.10 Generic_147440-12 sun4u sparc SUNW,SPARC-Enterprise

Je n'ai ni top, ni free, ni ptrdiag, ni ptrcong.

Voici le résultat du prtconf sur mon premier serveur :

antoun@serveur1# prtconf|head -5
prtconf: devinfo facility not available
System Configuration: Oracle Corporation sun4u
Memory size: 32768 Megabytes
System Peripherals (Software Nodes):

Cela veut vraiment dire que j'ai 32 Go de RAM ? ou il y a des subtilités qui feraient que j'ai virtuellement 32 mais réellement 1 ou 2 ?

Pour les CPU, voici le psrinfo du serveur 1 :

antoun@serveur1# psrinfo -v | grep -v virtual | uniq -c
1 on-line since 06/10/2012 23:26:07.
1 The sparcv9 processor operates at 2400 MHz,
1 and has a sparcv9 floating point processor.
1 on-line since 06/10/2012 23:26:07.
1 The sparcv9 processor operates at 2400 MHz,
1 and has a sparcv9 floating point processor.

J'ai un second serveur, dont je souhaite vérifier qu'il est iso-config avec le premier, qui me donne ceci comme psrinfo :

$ /usr/sbin/psrinfo -v | grep -v virtual | uniq -c
1 on-line since 06/10/2012 23:26:07.
1 The sparcv9 processor operates at 2400 MHz,
1 and has a sparcv9 floating point processor.

A première vue, j'aurais dit que c'était iso, mais à la revoyure, je me demande si le doublon sur le serveur 1 veut dire qu'il aurait deux CPU tandis que le serveur 2 n'en aurait qu'un ?

Enfin, si je comprends bien la tête des prompts, je suis admin sur le serveur 1 mais pas sur le serveur 2 ?

@jlliagre : peux-tu m'expliquer ta phrase ci-dessous ?

Quel que soit l'OS, tu as 10 GO de RAM libre et 27 GO de mémoire virtuelle disponible.

[jlliagre]

ni ptrdiag

Si, dans /usr/platform/sun4u/sbin/prtdiag et /usr/sbin.

ni ptrcong

Normal, cette commande n'existe pas, il s'agit d'une coquille pour prtconf.

Cela veut vraiment dire que j'ai 32 Go de RAM ? ou il y a des subtilités qui feraient que j'ai virtuellement 32 mais réellement 1 ou 2 ?

Qu'est ce qui te fait penser qu'il n'y en a qu'un ou deux de présents ?

A première vue, j'aurais dit que c'était iso, mais à la revoyure, je me demande si le doublon sur le serveur 1 veut dire qu'il aurait deux CPU tandis que le serveur 2 n'en aurait qu'un ?

Oui, un CPU pour le premier serveur, deux pour le deuxième.

Enfin, si je comprends bien la tête des prompts, je suis admin sur le serveur 1 mais pas sur le serveur 2 ?

C'est une convention mais elle ne parait pas respectée. A priori, tu n'es admin ni sur l'un ni sur l'autre.

@jlliagre : peux-tu m'expliquer ta phrase ci-dessous ?

Elle fait référence à la sortie de la commande vmstat qui, que tu sois sous AIX ou Solaris indique les valeurs que j'ai indiquées (mais sont peut-être une moyenne depuis le dernier boot et pas les valeurs courantes).
Un point qu'il faudrait que tu éclaircisse et d'expliquer ce que tu veux savoir exactement sur ce serveur et pourquoi. La mémoire installée ou la mémoire disponible, physique ou virtuelle ?

PS: Il semble que tu sois dans des zones Solaris, pour lesquelles il peut y avoir des mécanismes de limitations de ressources (CPU, RAM, etc ).

[Antoun]

Merci pour toutes les précisions !

Un point qu'il faudrait que tu éclaircisse et d'expliquer ce que tu veux savoir exactement sur ce serveur et pourquoi. La mémoire installée ou la mémoire disponible, physique ou virtuelle ?

En fait j'ai deux préoccupations différentes. Premièrement, on vient de faire une migration de serveur1 à serveur2, durant laquelle il y a eu pas mal de problèmes. J'ai eu un ou deux indices d'un écart de performance entre les deux serveurs, j'essaie donc de déterminer s'ils sont vraiment iso-config. Apparemment, il manque un CPU sur le nouveau serveur, ce qui expliquerait un certain nombre de choses.

Dans un second temps, je vais devoir faire le tuning Essbase, ce qui suppose de connaître le nombre de CPU utilisables pour paralléliser des processus de calcul, ainsi que la quantité de RAM dispo. Je ne suis pas sûr de comprendre ce qu'il faut comprendre quand tu parles de mémoire virtuelle. Pour moi, ça veut dire que le système utilise une partie du disque dur comme extension de la mémoire vive, ce qui veut dire que la vitesse de traitement est limitée par les I/O. Ce que je veux savoir, c'est donc la quantité de mémoire physique disponible sans swapper sur disque.

Enfin, ce sont des serveurs dédiés, donc je m'attends à ce que l'écart entre mémoire dispo et mémoire installé soit relativement faible, du coup l'une ou l'autre info peut me satisfaire.

Je n'ai pas vraiment de raison objective pour penser qu'il n'y a qu'un ou deux Go de mémoire, disons juste qu'avec 32 Go ça devrait péter le feu et qu'en fait ça ne casse pas trois pattes à un canard. Mais bon, il y a tellement de goulets d'étranglement possibles que c'est juste une première impression. Si par contre il n'y a en fait que 10 Go physiques, je comprends mieux les performances médiocres observées.

[Antoun]

voici ce que donne le prtdiag

$ /usr/platform/sun4u/sbin/prtdiag
prtdiag can only be run in the global zone

[Antoun]

Je reviens sur l'histoire des CPU... ce matin, en arrivant, j'ai refait le psrinfo, et je n'avais plus qu'un CPU de chaque côté ! Un peu plus tard, j'avais à nouveau deux CPU sur le serveur 1.

Serait-ce une question de mutualisation, avec les serveurs qui peuvent obtenir des CPU supplémentaires quand ils travaillent plus ?

[gangsoleil]

Je reviens sur l'histoire des CPU... ce matin, en arrivant, j'ai refait le psrinfo, et je n'avais plus qu'un CPU de chaque côté ! Un peu plus tard, j'avais à nouveau deux CPU sur le serveur 1.

Serait-ce une question de mutualisation, avec les serveurs qui peuvent obtenir des CPU supplémentaires quand ils travaillent plus ?

Oui, c'est quelque chose comme ca (difficile d'etre plus precis sans savoir ce qui est mis en place reellement).

Je pense que les zones que vous utilisez sont configurees pour avoir au moins 1 CPU, et au plus N si besoin et si dispo. Pour information, il est possible de faire le meme genre de configuration avec la RAM.

[Antoun]

Merci !

Du coup, c'est un peu difficile de savoir sur quelles hypothèses je dois tabler pour calculer mes optimisations...

[jlliagre]

En fait j'ai deux préoccupations différentes. Premièrement, on vient de faire une migration de serveur1 à serveur2, durant laquelle il y a eu pas mal de problèmes. J'ai eu un ou deux indices d'un écart de performance entre les deux serveurs, j'essaie donc de déterminer s'ils sont vraiment iso-config. Apparemment, il manque un CPU sur le nouveau serveur, ce qui expliquerait un certain nombre de choses.

serveur1 et serveur2 sont des serveurs virtualisés (zones non globales). Pourquoi ne pas demander aux administrateurs du ou des serveurs physiques qui les hébergent comment sont configurées les zones en question ?

Dans un second temps, je vais devoir faire le tuning Essbase, ce qui suppose de connaître le nombre de CPU utilisables pour paralléliser des processus de calcul, ainsi que la quantité de RAM dispo. Je ne suis pas sûr de comprendre ce qu'il faut comprendre quand tu parles de mémoire virtuelle. Pour moi, ça veut dire que le système utilise une partie du disque dur comme extension de la mémoire vive, ce qui veut dire que la vitesse de traitement est limitée par les I/O. Ce que je veux savoir, c'est donc la quantité de mémoire physique disponible sans swapper sur disque.

La mémoire virtuelle, ce n'est pas exactement ce que tu décris, on peut être à court de mémoire virtuelle alors qu'il reste de la mémoire physique et sans générer aucune I/O disque.

La mémoire physique installée sur le serveur physique est vraisemblablement 32 Go, la mémoire physique inutilisée est peut-être 10 Go. Aucune de ces deux valeurs ne permettent de savoir quelle est la mémoire disponible pour essbase dans ta zone.

Enfin, ce sont des serveurs dédiés, donc je m'attends à ce que l'écart entre mémoire dispo et mémoire installé soit relativement faible, du coup l'une ou l'autre info peut me satisfaire.

En général non, d'une manière générale, la mémoire disponible (free) est de la mémoire gaspillée, le système d'exploitation s'arrange donc pour en utiliser le plus possible, en particulier comme cache. Suivant le système de fichier utilisé, ce cache est rapporté comme mémoire libre ou non, ce qui ne simplifie pas l'interprétation de vmstat ...

Je n'ai pas vraiment de raison objective pour penser qu'il n'y a qu'un ou deux Go de mémoire, disons juste qu'avec 32 Go ça devrait péter le feu et qu'en fait ça ne casse pas trois pattes à un canard. Mais bon, il y a tellement de goulets d'étranglement possibles que c'est juste une première impression. Si par contre il n'y a en fait que 10 Go physiques, je comprends mieux les performances médiocres observées.

Pour savoir ce qu'essbase utilise comme mémoire, lance la commande "prstat -a" pendant un test de performance et montre nous ce qu'il sort, en particulier les colonnes "SWAP/SIZE et RSS".

[Antoun]

serveur1 et serveur2 sont des serveurs virtualisés (zones non globales). Pourquoi ne pas demander aux administrateurs du ou des serveurs physiques qui les hébergent comment sont configurées les zones en question ?

Quand je suis arrivé chez ce client il y a trois semaines, je leur ai posé des questions sur l'utilisation de la mémoire, ils m'ont répondu en me balançant des résultats de vmstats sans la moindre explication, malgré mes demandes. Ensuite je leur ai demandé combien il y avait de RAM et de CPU, et j'attends encore la réponse...
Donc effectivement, je vais finir par leur poser ce genre de questions, mais j'ai besoin d'un maximum de billes pour avoir les moyens de les faire parler

La mémoire virtuelle, ce n'est pas exactement ce que tu décris, [...] ce cache est rapporté comme mémoire libre ou non, ce qui ne simplifie pas l'interprétation de vmstat ...

Pour savoir ce qu'essbase utilise comme mémoire, lance la commande "prstat -a" pendant un test de performance et montre nous ce qu'il sort, en particulier les colonnes "SWAP/SIZE et RSS".

Je ferais ça, mais en fait la question n'est pas combien de mémoire Essbase utilise, mais plutôt combien je peux allouer à ses caches. En gros, j'ai des données de base qui doivent représenter quelques centaines de Mo, et Essbase va s'en servir pour générer environ 30 Go de données calculées. Il peut le faire avec 100 Mo de RAM, il peut aussi le faire avec 4 Go, mais évidemment ça va plus vite dans la seconde hypothèse. Par contre, si j'ai la main trop lourde, il peut y avoir un conflit entre les différentes bases Essbase, voire même une saturation de l'OS.

[jlliagre]

la question n'est pas combien de mémoire Essbase utilise, mais plutôt combien je peux allouer à ses caches.
...
Par contre, si j'ai la main trop lourde, il peut y avoir un conflit entre les différentes bases Essbase, voire même une saturation de l'OS.

Il y a peut-être un truc que je n'ai pas bien expliqué, c'est que les 32 Go de mémoire physique sont partagés entre toutes les zones du serveur, et on peut supposer que ta zone n'est pas la seule, vu qu'elle ne voit qu'un ou deux CPUs alors que la machine en a probablement entre 8 et 64.
S'il n'y a pas de "capping" mémoire sur les autres zones, tu n'a pas de garantie de pouvoir disposer d'une quelconque quantité de mémoire dans ta zone, il y aura compétition entre les différentes zones pour l'utilisation de la RAM et tu ne pourra pas dimensionner ton cache de manière fiable. S'il y a du capping, la taille mémoire disponible pour ta zone sera garantie. C'est donc une info primordiale a demander à ton client.

[gangsoleil]

Bonjour,

Peut-etre n'es-tu pas familié avec la notion de zone ? Pour la faire courte, c'est une machine virtuelle geree par l'OS "de base".

[Antoun]

Peut-etre n'es-tu pas familié avec la notion de zone ? Pour la faire courte, c'est une machine virtuelle geree par l'OS "de base".

Effectivement, je découvre totalement cette notion... Mais à lire les messages précédents, j'avais plutôt compris que c'était un pool de ressources mutualisé entre plusieurs VM ?

[gangsoleil]

j'avais plutôt compris que c'était un pool de ressources mutualisé entre plusieurs VM ?

Jiliagre (comme d'autres) te repondra beaucoup mieux que moi, mais pour faire simple : Solaris (a partir de la version 5.10, aussi appelee Solaris 10) gere, tout seul comme un grand, la notion de zone.
C'est a dire que l'OS est capable de gerer des sous-OS, comme des VM, qui seront vues de l'exterieur (comme de l'interieur) presque comme des OS independants (il y a de legeres differences lorsque tu as besoin d'acceder directement au materiel, mais c'est a peu pres tout).
L'avantage, c'est que tu peux gerer toutes tes machines (tes zones) depuis un seul endroit, la zone globale.
L'inconvenient, c'est que ca demande un peu de competences, car c'est un outil tres puissant, et que tous les admin n'ont pas pris la peine de s'y mettre.

Exemple :
J'ai une grosse machine avec 8 processeurs et de la RAM a foison, et quelques utilisateurs.
Je fais donc la configuration suivante :

• Zone globale : reservee a l'administrateur (moi)
• Zone toto : reservee a l'equipe toto. 1 a 4 CPU selon les besoins.
• Zone test : reservee a l'equipe de test, 2 a 4 CPUs
• Zone bac-a-sable : pour jouer, 1 a 2 CPUs
• Zone prod : pour tester la prod, 4 a 8 CPUs.

Comme tu le vois, j'alloue en permanence 8 a 18 CPUs, et je peux faire pareil pour la RAM.

L'avantage par rapport a un logiciel de virtualisation, c'est la gestion depuis la zone globale -- entre autre.

Attention, il y a pleins d'autres limitations (si je limite dans la zone globale chaque processus a 4 fichiers ouverts, cette limitation sera repercutee dans toutes les zones sans pour autant etre forcement visible par l'utilisateur), et pleins d'autres notions qui ont ete ajoutees (comme les groupes ou quelque chose dans le genre, je ne me souviens plus du nom).

[jlliagre]

Effectivement, je découvre totalement cette notion... Mais à lire les messages précédents, j'avais plutôt compris que c'était un pool de ressources mutualisé entre plusieurs VM ?

Il ne s'agit pas de VMs (au sens VirtualBox, VMWare, voire Java) mais de cloisonnement d'instances de systèmes d'exploitations partageant un noyau unique. http://en.wikipedia.org/wiki/Operati...virtualization

[Antoun]

OK, je vois l'idée.

Merci pour tout !