Bonjour,
Attention, question longue et peut être pas claire ;)
J'ai monté pour un projet dans ma boite un serveur basé sur Red Hat 7.3 avec dessus Oracle 9i, Apache et Php (plus CVS et Samba pour les dev). Tout marche bien dans le meilleur des mondes sauf pour la mémoire...
Je m'explique. au bout de quelques temps (entre 1 et 5 jours en moyenne) on arrive plus à créer de connexions à la base Oracle aussi bien dans l'appli PHP que sous Toad ou encore directement sous Sql Plus sur le serveur. On se prend un joli message du genre ORA-16000 cannot allocate shared memory gniagniagnia.
N'écoutant que mon courage, je décide de prospecter ça. Etant à la base développeur, je ne connais rien aux joies de l'admin de base Oracle. Je me dépatouille donc comme je peux, je regarde à droite à gauche mais j'ai pas que ça à faire et donc ça marche pas vraiment mieux. Bien sur, trouver un DBA Oracle est mission impossible dans ma boite...
Donc pour faire simple, je ne demande pas comment devenir DBA Oracle en 30 secondes sans se fatiguer mais j'aimerais avoir votre avis sur un phénomène que je trouve pas normal qui est la gestion de la mémoire.
Une petite description du serveur pour commencer. Le serveur est un PC normal, PIV 2,4 GHz avec 1Go de RAM. Déjà un premier soucis à mon avis est que la Red Hat 7.3 gère plutot très mal le matos. Par exemple, les écritures sur disque sont super lente, du genre parfois 1h pour copier un fichier de 400 Mo... Donc déjà je pense faire une petite MAJ du noyau serait nécessaire. Mais pour cela y'a plein d'autres trucs (logique) qui se mettent à jour en même temps, et comme le projet est suffisament dans les choux niveau temps, je me ferais lyncher si jamais le serveur tombais à cause de ça...
Maintenant, le soucis qui m'a fait prendre la plume de mon clavier. Quand on démarre le serveur, qu'on lance Oracle, son listener, apache, et tout le reste on bouffe au maximum 380 Mo de RAM. Tout va bien, ça marche impec, ça répond "bien", bref, le bonheur. Mais la quantité de RAM dispo diminue tout le temps. Ainsi au bout de 2 jours environ, on se retrouve plus que avec 10 Mo de RAM dispo. Le swap quand à lui n'est presque pas utilisé (genre 15 Mo sur 2 Go). Et donc quand on en arrive là, il est impossible de se connecter à la base.
Donc pour finir, ma question est de savoir si il est normal qu'il n'y ait jamais aucune libération de mémoire et est-ce que cela peut provoquer l'erreur Oracle qu'on rencontre ? Car c'est la RAM qui n'est jamais libérée et Oracle dit qu'il ne peut plus alouer de mémoire partagée. Perso, je vois la chose ainsi. Oracle aloue un espace mémoire (si je ne m'abuse correspondant au paramètre shared_pool_size et au db_block_buffer dans le init.ora) pour chaque connexion entrante, mais il ne le libère jamais. Ainsi quand on tombe à 15 Mo de RAM dispo, il ne peut plus alouer l'espace nécessaire. Mais le truc, c'est que normalement lorsque la session se termine, la mémoire ne devrait-elle pas être libérée automatiquemet ? Le problème vient-il d'un paramétrage Oracle ou de l'appli PHP qui merdoie ? Voila donc la question que je te pose Oh Grand journal de l'éternel...
Merci à ceux qui ont lu jusque là, merci pour les éventuelles réponses et si des questions il y a (donner des morceaux du init.ora ou autre par exemple) n'hésitez pas.
# Fermer les connexions
Posté par allcolor (site web personnel) . Évalué à 1.
Si tu as toad, tu peux le voir directement en listant les sessions ouvertes (dans outil ou un truc du genre)...
[^] # Re: Fermer les connexions
Posté par Nicolas Vaton . Évalué à 1.
Je trace actuellement les sessions pour tenter de voir ça, mais apparement elles sont bien fermées. Seulement la mémoire n'est pas libérée...
Merci de la réponse en tout cas !
# OS non certifié
Posté par Colargol . Évalué à 1.
[^] # Re: OS non certifié
Posté par Nicolas Vaton . Évalué à 1.
[^] # Re: OS non certifié
Posté par roychris . Évalué à 1.
RH AS 2.1 et 3.0 sont certifiée par Oracle.
RH 7.3 a toujours été déconseillée pour de la production.
[^] # Re: OS non certifié
Posté par Nicolas Vaton . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.