• CONTEXTE :

L’une de nos plateformes dédiées au « transcodage vidéo » (changement de codage d’un média afin de comprimer, encapsuler un média dans un fichier ou transporter un signal) bénéficie d’une infrastructure Oracle-Dataguard hébergée sur un socle Solaris 10 utilisant la technologie de « virtualisation », dite « zone Solaris ».
Durant la fin d’été 2013 de graves problèmes de performances sont apparus sur cet environnement. Les premières conclusions, issues des divers diagnostiques [Base,applicatif] ont mis en exergue des défaillances applicatives liées à un moteur de workflow IBM générant plusieurs « event » :
– « enq : TX row lock contention », avec une activité transactionnelle « surdimensionnée »
– Un Bug Oracle dans la gestion des LOB générant des « event » de type « HW enqueu » et enfin
– Un event « resmgr:cpu quantum ».
Mais pas que …

• ARCHITECTURE GLOBALE :

les bases WE et WH sont ouvertes sur une machine virtuelle Solaris, dite « zone Solaris ». Les éléments d’architecture sont les suivants :
Les deux zones virtuelles w-s (hébergeant les bases Primary) et w-p (hébergeant les bases Standby) sont chacune sur des serveurs physiques distincts (socles physique = zones globales) :
– w-p sur ZG1
– w-s sur ZG2

• INCIDENTS ET « Capping CPU »

Parmi les autres problèmes de performances rencontrés, nous avions des indicateurs de charge  (load average notamment) assez haut.
D’après les indicateurs systèmes et les graphes de consommation serveur remontés par la console OEM, il y avait un décalage conséquent entre un (load average) important et une inadéquation totale avec une conso CPU à priori faible sur la machine « PRIMARY ».
En investiguant plus profondément sur la partie système, et en tenant compte de la particularité des « zones solaris », Nous avions pu émettre une hypothèse sur une limitation de CPU sur la zone virtuelle w-s, via le mécanisme de « capping ».
Ce « capping » serait configurer à 100… !
Cette valeur, se définissant en centièmes de thread CPU indiquant le chiffre 100 serait donc équivalent à 1 thread maximum en conso instantanée partagé par l’ensemble des processus consommateurs sur la zone.
Pour résumer, la machine virtuelle w-s « Primary » n’utilisait qu’un seul CPU sur les 32 au total. Les préconisations du constructeur (non suivi par erreur de configuration) étaient de dédier la totalité des ressources (CPU) à l’unique machine virtuelle w-s.
De plus, nous avions le paramètre  cpu_count=4 configuré au sein des bases pour gérer un seul thread alloué, ce qui ne manquait pas d’ajouter de l’huile sur le feu. Cette mauvaise configuration était surement la cause de L’event « resmgr:cpu quantum » remonté par les clichés AWR.
Nous avions donc vérifié sur le système.
…Et le système confirma notre hypothèse …
# prctl $$
process: 28289: -bashNAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
process.max-port-events
privileged 65.5K – deny –
system 2.15G max deny –
process.max-msg-messages
privileged 8.19K – deny –
system 4.29G max deny –
system 16.0EB max deny –
project.max-locked-memory
system 16.0EB max deny –
project.max-port-ids
zone.max-shm-ids
privileged 192 – deny –
…
…
…
zone.max-msg-ids
privileged 512 – deny –
system 16.8M max deny –
zone.max-lwps
privileged 10.2K – deny –
system 2.15G max deny –
zone.cpu-cap
privileged 100 – deny –
system 4.29G inf deny –
zone.cpu-shares
privileged 1 – none –
system 65.5K max none –

• GESTION DES RESSOURCES

La gestion des ressources sous solaris 10, à pour visée l’encadrement de la consommation d’un environnement spécifique, dans notre cas la « zone solaris » ou machine virtuelle. L’approche utilisée pour la mise en œuvre de cette limitation peut être effectuer :
– Soit par le haut :
Limitation des ressources accessibles à cet environnement
– Soit par le bas :
Garantissant l’accès à un minimum de ressources.
Cet problématique s’invite de plus en plus dans les choix d’architecture, et plus particulièrement, dans les environnements virtualisés.
Dans l’univers Sun, on parle de « containers » dès qu’un environnement subit un quelconque encadrement de ressources. Cet environnement peut être une « zone Solaris » (comme dans notre cas), mais aussi un « projet » ou une « tâche », qui sont deux notions propres à Solaris 10.
La gestion de ressources sous Solaris 10 concernant les « zones solaris » s’appuie sur les mécanismes Suivants :
1. Le Capping mémoire
Le capping mémoire permet de plafonner la consommation mémoire. Il se configure statiquement au sein de la zone ou dynamiquement par l’intermédiaire de la commande rcapadm.
2. Partage CPU avec FSS :
Le Fair Share Scheduler (FSS) permet de pondérer respectivement le partage CPU à des groupes d’éléments (utilisateurs, projets, ou encore des zones solaris). Concrètement, ces poids relatifs définissent la proportion de CPU à laquelle chaque zone pourra prétendre, en cas de contention.
3. Processeurs dédiés :
Cela consiste à dédier un ou plusieurs processeurs à une zone. Ces processeurs seront utilisables exclusivement par elle, et cachés à toutes les autres zones, à l’exception de la zone globale.
A l’inverse, cette zone ne verra plus que son ou ses processeurs dédiés, sans accès aux autres processeurs.
4. Hard capping (Limite CPU absolue):
Cette fonction présente à partir de l’update 5 permet de limiter de manière absolue la quantité de CPU qu’une « zone solaris » peut utiliser. On appelle parfois cette fonctionnalité le hard capping. Cette fonctionnalité est présente à partir de l’update 5.
C’est cette fonctionnalité qui a été utilisé pour permettre à la « zone solaris » w-s d’utilisé l’ensemble des ressources du système.
La configuration se fait de manière statique avec zonecfg :
– le paramètre zone.cpu-cap.
– la propriété ncpus, exprimée en nombre de cpus.
Ce nombre ne doit pas forcément être un entier :
– Un ncpus égal à 3 permet à la « zone solaris »pourra utiliser 3 CPUs .
– Une valeur de .45 correspond à 45% d’un processeur.
# zonecfg –z mazone
zonecfg:mazone> add capped-cpu
zonecfg:mazone:capped-cpu> set ncpus=.45
zonecfg:mazone:capped-cpu> end
zonecfg:mazone> exit

• Conclusion :

– Une fois la modification effectué nous avons obtenu immédiatement une baisse du « load average », constaté que l’accès et le redémarrage des bases de la plateforme WOODE étaient devenus plus rapide et le paramètre « cpu_count=4 » repris le chemin de la cohérence.
En effet, l’event resmgr:cpu quantum qui fut auparavant remonté par les clichés AWR avait totalement disparu.
Dans les fenêtres de maintenance, un plan de ressources gérant la CPU était actif. Étant donnée que le paramètre « cpu_count=4 » eut été positionné, le « cagging » (fonctionnalité permettant de fixer le nombre maximum de processeurs utilisables par une instance) entra alors en action pendant ces intervalles.
L’instance cagging « pensait » pouvoir gérer 4 threads, alors qu’elle n’en disposait que d’un seul, d’où cette attente qui était mesurée puis qui disparu.
La résolution de cet incident système, nous a permis de travailler plus sereinement avec une base plus performante pour résoudre le reste des problématiques.
– A retenir donc, la manipulation avec parcimonie des options de limitations ressources système pour les bases Oracle surtout dans les cas de plateforme virtualisées.