2014-09-30 9:19 GMT+02:00 nap <napar...@gmail.com>: > J'ai longuement "échangé" avec un consultant Oracle sur ce sujet quand il me > sortait ces précos justement. Je lui ais demandé de calculer le temps que > prenait une requête lorsqu'une grosse partie d'un ancien processus avait été > mis en swap et qu'on venait à le requéter (genre un batch de nuit qui fait > des appels un peu particuliers). J'ai bien rigolé à voir sa tête quand il a > testé le calcul et qu'on a vu que ça timeoutait les requêtes...
Au prix actuel de la RAM, c'est presque un crime d'avoir un processus de base de données qui parte en swap. Outre le fait de se conformer aux préconisations de l'éditeur, le but de garder du swap est d'en avoir pour le système si celui-ci en a besoin. > (remarque: je ne suis pas méchant avec les consultants d'habitude, mais lui > se disait expert oracle/système et me relançais constamment sur les préecos > sans être capable de me fournir un début d'explication sur ce que ça > impliquait dans la réalité, et ce genre de consultants désolé mais ils ne > font pas leur cirque très longtemps). Ce n'est pas parce que le consultant est mauvais qu'il a tort. Pour du Oracle, ne pas hésiter à faire une recherche sur Metalink.. > > Concernant le support Oracle, on a jamais eu trop de remarque sur ce point. Ok. C'est plus ce point la qui me bloque aujourd'hui.. > Mais il faut dire que lorsqu'on a viré le swap on avait beaucoup, beaucoup > moins de soucis à causes es performances (Oracle application sur RAC > actif/actif, qu'on a encore bien "amélioré" en le passant en > actif/passif...). > > Il est possible que les huges pages aient réglés le soucis, mais sur ma > qualification j'avais du mal à régler les huges convenablement (pas évident > de reproduire une même charge qu'en prod sur une telle application > "lourde"), et el swap avait fait l'affaire, donc j'ai pris cette solution :) Je pense effectivement qu'il y avait quelque chose à faire avec les huges pages. Quand je récupère une application que je ne connais pas, la première chose que je fais est de régler la SGA_TARGET/SGA_MAX à environ 20% de la quantité de données. Si le système le permet, rajouter le nombre de huges pages nécessaires (ne pas oublier de laisser de la place pour le reste du système et la PGA) et activer les options pré-allocation et de verrouillage de la SGA. Après j'affine en fonction de l'activité et des ressources disponibles. Les problèmes de perf que je rencontre sont rarement au niveau de la SGA... > Pour remarque c'était une RHEL5 donc avec un noyau ancien, on dirait que > c'est mieux géré maintenant :) J'ai eu quelques soucis sur du AIX mais uniquement à cause d'un problème de ressources (plus de RAM allouée aux LPAR que de disponible), mais que ce soit sur du RedHat (OEL plus exactement) 5 ou 6, je n'ai jamais eu de problème. -- Benoit _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
