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.

vendredi, 20 mai 2011

Firefox : optimisation des bases SQlite

J'entends beaucoup parler d'optimisation de navigateur avec des manipulations plus ou moins pertinentes à effectuer sans que le gains ne soit réellement mesuré. Aujourd'hui je vous propose une optimisation relativement triviale visant à nettoyer les bases SQlite utilisées par Firefox pour y stocker diverses informations.

Les pré-requis:

  • sqlite3 doit être installé
  • Firefox doit être fermé au moment des manipulations, faute de quoi les commandes à venir se solderont par un message vous informant que la base est verrouillée.

Mise en œuvre

les fichiers relatifs au profil utilisateur sont, par défaut, stockés dans le répertoire ~/.mozilla/firefox/*.default/. Nous allons donc optimiser tous les fichiers sqlite présents dans ce répertoire à l'aide de la commande suivante:

$ find ~/.mozilla/firefox/*.default/ -iname "*.sqlite" -exec sqlite3 {} 'VACUUM;' \;

Pour comprendre l'opération effectuée il suffit de se reporter à la documentation sqlite. La directive VACUUM vise à reconstruire dans son intégralité la base sqlite en compactant cette dernière au maximum. Pour le détail des actions effectuées par la commande je vous invite à lire l'excellente présentation de la documentation officielle. http://www.sqlite.org/lang_vacuum.html Voici une présentation de chacun des fichiers sqlite afin de mieux comprendre (Merci Gniarf):
urlclassifier3.sqlite : c'est la base qui est fournie par google pour la fonction anti-malware, ca pèse facilement 23 Mo a la sortie d'une installation. Si la fonctionnalité est désactivé vous n'avez donc pas besoin de stocker cette base.
cookies.sqlite : va contenir l'ensemble des cookies stockés par les différents sites visités.
places.sqlite : contient l'historique des pages visitées donc avec une rétention de 90 jours, ce fichier peut facilement atteindre 20Mo. Vous pouvez trouver une présentation exhaustive de cette base ici.
key3.db : c'est la base de mots de passes enregistrés dans firefox. Cette dernière est chiffrées et ne peut donc être accédée :

sqlite> SELECT name FROM sqlite_master WHERE type = "table";
Error: file is encrypted or is not a database

signons.sqlite : il fonctionne apparemment de paire avec la base key3.db. ce dernier n'est pas chiffré. On peut donc imaginer qu'il est utilisé pour accéder aux informations chiffrées de la base key3.db
downloads.sqlite : contient la liste de téléchargements lancés dans le navigateur.
content-prefs.sqlite : Contient les préférences individuelles appliquées à des pages. ici pour plus de détails le contenu (désolé la page n'était disponible que dans le cache google au moment ou j'écris).
premissions.sqlite : contient l'ensemble des préférences appliquées sur un site. On y liste donc les sites autorisés à utiliser ou non les cookies, ou encore afficher ou non des images.
formhistory : contient l'historique des formulaires saisis dans votre navigateur.
search.sqlite : contient la liste des différents moteurs de recherche intégrés au navigateur.
webappsstore.sqlite : contient les données au format DOM générées par les différents sites. plus de détails ici

Maintenant est-ce vraiment efficace ?

J'ai effectué mes tests sur un navigateur Firefox fraichement installée, je n'ai donc pas observé de changement significatif de performances. Cependant les chiffres parlent d'eux même. Voici donc les variations de taille que j'ai pu observer sur les différents fichiers SQLite une fois le nettoyage des base effectué. Optimisation des bases SQLite Firefox On constate que 3 bases (cookies.sqlite, urlclassifier3.sqlite, places.sqlite) ont fait l'objet d'un sérieux nettoyage et j'avoue avoir été surpris d'un tel gain après un temps si court d'utilisation. J'imagine donc largement à quel point cette optimisation peut s'avérer bénéfique dans le cas d'une utilisation prolongé de Firefox. J'ai entamé un suivi des bases sqlites constitutives du profil, nous pourrons ainsi voir l'évolution de ces dernières dans le temps et générer des jolis graphiques :). Voici donc comme promis un graphique représentant le bénéfice du compactage des bases dans le temps. compactage de base sqlite pour la version en taille originale vous pouvez la trouver ici

Liens connexes

samedi, 5 septembre 2009

[Oracle] Verifier état d'un utilisateur

Je dois souvent vérifier l'état d'un compte utilisateur posant problème sur des bases Oracle. Il faut donc vérifier le statut du compte au cas ou le compte serait bloqué ou encore mal configuré.

Lire la suite...

jeudi, 23 avril 2009

[Oracle] Verfier etat d'un listener

vérifier état d'un listener sur un serveur.

[sql]
(server) [root] /home/root > ps -ef | grep pmon
  ora102  880834       1   0 03:18:05      -  0:06 ora_pmon_LDREF01
  ora102 1712218       1   0 03:17:45      -  0:06 ora_pmon_LDREP01
    root 1732796  806948   0 14:12:37  pts/4  0:00 grep pmon
(server) [root] /home/root > su - ora102
============================================
= You are connected with a [LOCAL] account =
============================================
(server) [ora102] /home/ora102 > lsnrctl

LSNRCTL for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Production on 23-APR-2009 14:14:47

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Welcome to LSNRCTL, type "help" for information.

LSNRCTL> status LDR01
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LDR01)))
STATUS of the LISTENER
------------------------
Alias                     LDR01
Version                   TNSLSNR for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Production
Start Date                16-NOV-2008 08:24:08
Uptime                    158 days 5 hr. 51 min. 1 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      ON
Listener Parameter File   /appl/oracle/product/10.2.0/network/admin/listener.ora
Listener Log File         /appl/oracle/product/10.2.0/network/log/ldr01.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LDR01)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=server)(PORT=1549)))
Services Summary...
Service "LDR01" has 1 instance(s).
  Instance "LDR01", status READY, has 1 handler(s) for this service...
Service "LDR01_XPT" has 1 instance(s).
  Instance "LDR01", status READY, has 1 handler(s) for this service...
The command completed successfully
LSNRCTL>

bien vérifier la présence de l'entrée dans le fichier local D:\oracle\product\10.2.0\client_2\network\admin\tnsnames.

[sql]
LDR01.WORLD =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = server.mondomaine.com)(PORT = 1548))
    )
    (CONNECT_DATA =
      (SID = LDR01)
      (SRVR = DEDICATED)
    )
  )

vendredi, 24 octobre 2008

Trouver listener Oracle

tnsping

Le listener d'après oracle correspond au port sur lequel une instance est en écoute. Il est donc vital de connaitre le numéro de listener pour ensuite contacter l'instance.

Pour se faire nous devons nous connecter au serveur hebergeant l'instance en utilisant l'utilisateur oracle. Utiliser ce compte va permettre de charger les variables d'environnement propre à ce compte.

Nous pourrons ensuite lancer un tnsping INSTANCE_NAME

----sortie tronquée----
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=server3)(PORT=1527)) (CONNECT_DATA= (SID=BS6)))
OK (0 msec)
----sortie tronquée----

On voit donc que l'instance est en écoute sur le port 1527

Autre méthode

La variable TNS_ADMIN contient le chemin vers le dossier relatif aux fichiers de configuration réseau de l'instance. Ainsi dans ce repertoire nous pouvons trouver un fichier tnsnames.ora contenant la configuration réseau des diverses instances oracles. c'est dans ce fichier que nous pouvons également trouver la valeur d'un listener :

----sortie tronquée----
MABASE = (DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS= (PROTOCOL=TCP)(HOST = server1)(PORT = 1549))
)
(CONNECT_DATA =
(SID = NOVA)
(SERVER = DEDICATED)
)
)
----sortie tronquée----

Nous pouvons ici aussi obtenir le listener pour la base MABASE ici fixé à 1549