Mot-clé - supervision

Fil des billets - Fil des commentaires

mardi, 1 octobre 2013

Centreon : superviser la charge mémoire de vos serveurs Oracle

Les gens sensibilisés à la supervision ont tous rencontrés ce problème;
Un applicatif hébergé sur un serveur, se réserve de la RAM au démarrage pour disposer d'un espace d'échange avec la certitude que ce dernier lui sera entièrement dédiée.
Pour le cas d'Oracle cela va permettre au SGBD de charger directement en RAM une structure interne et ainsi avoir des temps de réponse optimum.
Voici par exemple un cas concret avec un serveur Oracle.

$ free -m
             total       used       free     shared    buffers     cached
Mem:          7971       7847        124          0        171       3966
-/+ buffers/cache:       3709       4261
Swap:        16002       1812      14189

On remarque que sur les 8Go de RAM présente sur le serveur, 4Go sont en cache.
À l'aide de la commande ipcs, on relève la RAM allouée spécifiquement au service Oracle.

$ ipcs -m  | grep oracle
0x43906674 11239429   oracle    660        4096       0
0x8a5a4b48 11501575   oracle    660        4096       0

Pour le serveur concerné nous avons 2 instances de bases avec chacune 4Go de RAM allouée.
Il est également possible de voir la valeur de la RAM allouée directement en base de données.

$ sqlplus '/ as sysdba'
SQL*Plus: Release 11.2.0.2.0 Production on Tue Oct 1 10:59:38 2013
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connecte a :
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
SQL> show parameter memory

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
hi_shared_memory_address             integer     0
memory_max_target                    big integer 3G
memory_target                        big integer 3G
shared_memory_address                integer     0
SQL>

Il est à noter, que la valeur memory_target, au même titre que celle retournée par la commande ipcs, sont des valeurs maximales, la valeur effective pouvant être inférieure.
Oui mais voilà, comment, côté supervision, traiter ce comportement ? D'un point de vue du système la RAM est allouée, donc consommée. Comment pouvons nous dans ce cas identifier un manque de RAM et décider s'il est nécessaire ou non de redimensionner la machine ?
La supervision de la RAM sur ce genre de serveur est problématique car souvent en statut critique. Le but de la manœuvre est donc ici de continuer de stocker la charge de RAM, sans que cela ne remonte d'état WARNING ou CRITICAL.
% Pour se faire nous allons utiliser un check classique que nous allons chainer avec un second script, j'ai nommé negate.
Voici le script classique utilisé pour superviser la RAM :

# ./check_snmp_storage.pl -H serveur1 -C ro-snmp -m -q Ram -w 90 -c 95 -f ; echo $?
Physical memory: 98%used(3818MB/3886MB) (>95%) : CRITICAL | 'Physical_memory'=3818MB;3497;3691;0;3886
2

Le script retourne bien un statut critique, la valeur du code retour étant 2.
Et maintenant le même script couplé avec negate :

# ./negate -o OK -w OK -c OK /usr/lib/nagios/plugins/check_snmp_storage.pl -H serveur1 -C ro-snmp -m -q Ram -w 90 -c 95 -f ; echo $?
Physical memory: 98%used(3819MB/3886MB) (>95%) : CRITICAL | 'Physical_memory'=3819MB;3497;3691;0;3886
0

Cette fois-ci, le code retour est 0.
Voilà donc, mission accomplie ! Nous continuons de stocker les valeurs d'utilisation de la mémoire vive, sans que celle si ne change jamais d'état coté supervision.
Ce n'est plus la RAM que nous allons superviser, mais la mémoire virtuelle (swap). Ainsi, dès que le serveur va commencer à utiliser la mémoire virtuelle, des alertes seront remontées.
Nous venons donc de voir un moyen efficace et élégant de superviser les serveurs hébergeant des applications fonctionnant sur le principe de réservation de mémoire vive.