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.