Bonjour,
Je dévie un peu du sujet initial:
2014-09-29 16:37 GMT+02:00 nap naparuba@gmail.com:
2014-09-29 16:15 GMT+02:00 frsag@jack.fr.eu.org:
+1. sur mes serveurs Oracle c'était 0 de swap (enfin si à l'install car Oracel check, mais après hop on vire). Même avec swapiness à 0 le swap st trop utilisé face au cache disque (or dans lecas d'une bdd on préfère que ce soit la base qui gère ça, pas trop le système).
Les précos d'Oracle sont de mettre entre 1,5Go et 16Go de swap, en fonction de la quantité de mémoire disponible (voir : http://docs.oracle.com/cd/E11882_01/install.112/e47689/pre_install.htm#LADBI...
En dehors de pouvoir récupérer un peu de disque, est-ce que ça vaut vraiment le coup? Et comment réagit le support Oracle en cas de problème?
Pour la gestion de la mémoire, j'ai tendance à ne pas toucher au swapiness mais à configurer les huges pages et activer les paramètres pre_page_sga & lock_sga: Le premier permet à l'instance de réserver tout les segments mémoire de la SGA (correspondant à SGA_MAX) dès le démarrage. Le second que ces segments soient des segments de mémoire réelle (ie de la vraie RAM) et non de la mémoire virtuelle (qui elle peut partir en swap si le système le décide).
Ca a par contre des effets de bords: - Les instances sont plus longues à démarrer (le temps d'allouer l'ensemble des segments mémoire) - Si on n'est pas carré au niveau des huges pages on peut justement se retrouver avec des Out of Memory error (si on essaie d'allouer plus de huge pages que la quantité disponible par exemple).
Pardon mais ils ne se foulent pas .... ce sont les précos "générales" qu'on trouves depuis 20 ans sur les serveurs et même desktops Linux ... Plus personne ne met l'équivalent de sa ram en swap !
Le 29 septembre 2014 18:11, Benoit Garcia benoit.garcia@gmail.com a écrit :
Bonjour,
Je dévie un peu du sujet initial:
2014-09-29 16:37 GMT+02:00 nap naparuba@gmail.com:
2014-09-29 16:15 GMT+02:00 frsag@jack.fr.eu.org:
+1. sur mes serveurs Oracle c'était 0 de swap (enfin si à l'install car Oracel check, mais après hop on vire). Même avec swapiness à 0 le swap st trop utilisé face au cache disque (or dans lecas d'une bdd on préfère
que ce
soit la base qui gère ça, pas trop le système).
Les précos d'Oracle sont de mettre entre 1,5Go et 16Go de swap, en fonction de la quantité de mémoire disponible (voir :
http://docs.oracle.com/cd/E11882_01/install.112/e47689/pre_install.htm#LADBI...
En dehors de pouvoir récupérer un peu de disque, est-ce que ça vaut vraiment le coup? Et comment réagit le support Oracle en cas de problème?
Pour la gestion de la mémoire, j'ai tendance à ne pas toucher au swapiness mais à configurer les huges pages et activer les paramètres pre_page_sga & lock_sga: Le premier permet à l'instance de réserver tout les segments mémoire de la SGA (correspondant à SGA_MAX) dès le démarrage. Le second que ces segments soient des segments de mémoire réelle (ie de la vraie RAM) et non de la mémoire virtuelle (qui elle peut partir en swap si le système le décide).
Ca a par contre des effets de bords:
- Les instances sont plus longues à démarrer (le temps d'allouer
l'ensemble des segments mémoire)
- Si on n'est pas carré au niveau des huges pages on peut justement se
retrouver avec des Out of Memory error (si on essaie d'allouer plus de huge pages que la quantité disponible par exemple).
-- Benoit _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
2014-09-29 20:12 GMT+02:00 Greg greg-frsag@duchatelet.net:
Pardon mais ils ne se foulent pas .... ce sont les précos "générales" qu'on trouves depuis 20 ans sur les serveurs et même desktops Linux ... Plus personne ne met l'équivalent de sa ram en swap !
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...
(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).
Concernant le support Oracle, on a jamais eu trop de remarque sur ce point. 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 :)
Pour remarque c'était une RHEL5 donc avec un noyau ancien, on dirait que c'est mieux géré maintenant :)
Jean
2014-09-30 9:19 GMT+02:00 nap naparuba@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.
Le mar 30 sep 14 à 13:10:38 +0200, Benoit Garcia benoit.garcia@gmail.com écrivait :
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.
Oui, c'est un peu l'explication que j'avais entendue : en principe, la plupart des processus d'Oracle sont toujours plus ou moins actifs, et ça n'est pas la base qui est censée utiliser le swap.
Par contre il arrive que des programmes applicatifs partent en vrille ou libèrent mal la mémoire, et c'est eux que l'on espère faire swapper. Ou un gros batch java qui a lancé une requête de la mort, et qui n'a rien d'autre à faire en attendant la fin de cette requête.
2014-09-29 20:12 GMT+02:00 Greg greg-frsag@duchatelet.net:
Pardon mais ils ne se foulent pas .... ce sont les précos "générales" qu'on trouves depuis 20 ans sur les serveurs et même desktops Linux ... Plus personne ne met l'équivalent de sa ram en swap !
Salut,
Pour le mode 'suspend' de ton laptop fonctionne à tous les coups, c'est recommandé. Mais bon, on a rarement 256G de RAM sur un laptop.
Baptiste
-
Baptiste -
Benoit Garcia -
Greg -
Laurent -
nap -
Thierry Thomas