J'ai des serveurs MOSS 2007 en pseudo-production avec bien sûr IIS 6.0.
Malheureusement, le soir, le matin ou l'après-midi, j'arrive en limite de
consommation de mémoire pour mes pools d'application, ce qui a pour effet
"boum" .... IIS 6 out ... et j'ai systématiquement 3 workers quand je
redémarre ou quand je reboote.
J'ai trouvé un outil permettant de recycler les workers (wakeup), mais
apparemment cela n'est pas suffisant.
Comment paramétrer correctement IIS 6.0 ? Sur le web, on trouve tout et
n'importe quoi. MS reste très sobre sur la question, les consultants MS sont
bien peu locaces sur le sujet.
Existe-t-il des "best practices" ? un exemple concret avec paramétrage réel
serait le bienvenu ?
Quels compteurs pourraient-on suveiller ou quels outils employés pour
"tuner" le IIS 6.0 ? Faut-il créer des "web garden" ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Lognoul, Marc \(Private\)
Bonjour,
J'ai des serveurs MOSS 2007 en pseudo-production avec bien sûr IIS 6.0. Malheureusement, le soir, le matin ou l'après-midi, j'arrive en limite de consommation de mémoire pour mes pools d'application, ce qui a pour effet "boum" .... IIS 6 out ... et j'ai systématiquement 3 workers quand je redémarre ou quand je reboote.
Logique, dans la mesure ou il y a au moins un process par application pool. en imaginant que vous avez 3 pools "standards": le pool par défaut d'IIS, le pool central admin sharepoint et un pool pour l'application MOSS A noter que normalement, le process n'est effectivement crée que lorsque la première requête atteint le serveur
J'ai trouvé un outil permettant de recycler les workers (wakeup), mais
Si c'est bien du script/tool de wakeup pour WSS dont vous parlez, son but n'est pas d'optimiser quoi que ce soit mais bien de forcer exécution de pages (et donc la compilation) afin d'éviter le délais d'application à la première exécution d'un page après un reboot, recycle, IISRESET, changement de code ou Web.Config...
apparemment cela n'est pas suffisant.
Euh, pas suffisant pour quoi faire?
Comment paramétrer correctement IIS 6.0 ? Sur le web, on trouve tout et n'importe quoi. MS reste très sobre sur la question, les consultants MS sont bien peu locaces sur le sujet.
A mon avis, il seront plus loquaces si vous posez des question TRES précises. Les question générales renvoient des réponses générales dans le style "allez voir sur Technet"
Existe-t-il des "best practices" ? un exemple concret avec paramétrage réel serait le bienvenu ?
Avez-vous testé les configuration reprise dans le post du blog de Joel Oleson que je vous ai indiqué sur le NG SharePoint?
Quels compteurs pourraient-on suveiller ou quels outils employés pour
Voici un bon aperçu des compteurs: http://blogs.msdn.com/joelo/archive/2007/01/16/good-list-of-performance-counters.aspx
"tuner" le IIS 6.0 ? Faut-il créer des "web garden" ?
Sous WSS/MOSS, le gardening n'a que peu ou pas d'intérêt dans ce cas, cela tient notamment à la manière dont WSS/MOSS gère la mémoire
QQ info et solution en ce qui concerne l'utilisation excessive de mémoire avec WSS/MOSS: http://blogs.technet.com/stefan_gossner/archive/2007/11/26/dealing-with-memory-pressure-problems-in-moss-wss.aspx
Mais si vous déployez des applications "custom" le best practice du développeur c'est de ne jamais oublier .Dispose :)
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses]
PS: Si vous aviez tenté de m'envoyer des infos complémentaires sur ma BAL, je n'ai rien reçu. pour rappel:
Bonjour,
J'ai des serveurs MOSS 2007 en pseudo-production avec bien sûr IIS 6.0.
Malheureusement, le soir, le matin ou l'après-midi, j'arrive en limite de
consommation de mémoire pour mes pools d'application, ce qui a pour effet
"boum" .... IIS 6 out ... et j'ai systématiquement 3 workers quand je
redémarre ou quand je reboote.
Logique, dans la mesure ou il y a au moins un process par application pool.
en imaginant que vous avez 3 pools "standards": le pool par défaut d'IIS, le
pool central admin sharepoint et un pool pour l'application MOSS
A noter que normalement, le process n'est effectivement crée que lorsque la
première requête atteint le serveur
J'ai trouvé un outil permettant de recycler les workers (wakeup), mais
Si c'est bien du script/tool de wakeup pour WSS dont vous parlez, son but
n'est pas d'optimiser quoi que ce soit mais bien de forcer exécution de
pages (et donc la compilation) afin d'éviter le délais d'application à la
première exécution d'un page après un reboot, recycle, IISRESET, changement
de code ou Web.Config...
apparemment cela n'est pas suffisant.
Euh, pas suffisant pour quoi faire?
Comment paramétrer correctement IIS 6.0 ? Sur le web, on trouve tout et
n'importe quoi. MS reste très sobre sur la question, les consultants MS
sont
bien peu locaces sur le sujet.
A mon avis, il seront plus loquaces si vous posez des question TRES
précises. Les question générales renvoient des réponses générales dans le
style "allez voir sur Technet"
Existe-t-il des "best practices" ? un exemple concret avec paramétrage
réel
serait le bienvenu ?
Avez-vous testé les configuration reprise dans le post du blog de Joel
Oleson que je vous ai indiqué sur le NG SharePoint?
Quels compteurs pourraient-on suveiller ou quels outils employés pour
Voici un bon aperçu des compteurs:
http://blogs.msdn.com/joelo/archive/2007/01/16/good-list-of-performance-counters.aspx
"tuner" le IIS 6.0 ? Faut-il créer des "web garden" ?
Sous WSS/MOSS, le gardening n'a que peu ou pas d'intérêt dans ce cas, cela
tient notamment à la manière dont WSS/MOSS gère la mémoire
QQ info et solution en ce qui concerne l'utilisation excessive de mémoire
avec WSS/MOSS:
http://blogs.technet.com/stefan_gossner/archive/2007/11/26/dealing-with-memory-pressure-problems-in-moss-wss.aspx
Mais si vous déployez des applications "custom" le best practice du
développeur c'est de ne jamais oublier .Dispose :)
--
Marc
[Heureux celui qui a pu pénétrer les causes secrètes des choses]
PS: Si vous aviez tenté de m'envoyer des infos complémentaires sur ma BAL,
je n'ai rien reçu. pour rappel: lognoulm@hotmail.com
J'ai des serveurs MOSS 2007 en pseudo-production avec bien sûr IIS 6.0. Malheureusement, le soir, le matin ou l'après-midi, j'arrive en limite de consommation de mémoire pour mes pools d'application, ce qui a pour effet "boum" .... IIS 6 out ... et j'ai systématiquement 3 workers quand je redémarre ou quand je reboote.
Logique, dans la mesure ou il y a au moins un process par application pool. en imaginant que vous avez 3 pools "standards": le pool par défaut d'IIS, le pool central admin sharepoint et un pool pour l'application MOSS A noter que normalement, le process n'est effectivement crée que lorsque la première requête atteint le serveur
J'ai trouvé un outil permettant de recycler les workers (wakeup), mais
Si c'est bien du script/tool de wakeup pour WSS dont vous parlez, son but n'est pas d'optimiser quoi que ce soit mais bien de forcer exécution de pages (et donc la compilation) afin d'éviter le délais d'application à la première exécution d'un page après un reboot, recycle, IISRESET, changement de code ou Web.Config...
apparemment cela n'est pas suffisant.
Euh, pas suffisant pour quoi faire?
Comment paramétrer correctement IIS 6.0 ? Sur le web, on trouve tout et n'importe quoi. MS reste très sobre sur la question, les consultants MS sont bien peu locaces sur le sujet.
A mon avis, il seront plus loquaces si vous posez des question TRES précises. Les question générales renvoient des réponses générales dans le style "allez voir sur Technet"
Existe-t-il des "best practices" ? un exemple concret avec paramétrage réel serait le bienvenu ?
Avez-vous testé les configuration reprise dans le post du blog de Joel Oleson que je vous ai indiqué sur le NG SharePoint?
Quels compteurs pourraient-on suveiller ou quels outils employés pour
Voici un bon aperçu des compteurs: http://blogs.msdn.com/joelo/archive/2007/01/16/good-list-of-performance-counters.aspx
"tuner" le IIS 6.0 ? Faut-il créer des "web garden" ?
Sous WSS/MOSS, le gardening n'a que peu ou pas d'intérêt dans ce cas, cela tient notamment à la manière dont WSS/MOSS gère la mémoire
QQ info et solution en ce qui concerne l'utilisation excessive de mémoire avec WSS/MOSS: http://blogs.technet.com/stefan_gossner/archive/2007/11/26/dealing-with-memory-pressure-problems-in-moss-wss.aspx
Mais si vous déployez des applications "custom" le best practice du développeur c'est de ne jamais oublier .Dispose :)
-- Marc [Heureux celui qui a pu pénétrer les causes secrètes des choses]
PS: Si vous aviez tenté de m'envoyer des infos complémentaires sur ma BAL, je n'ai rien reçu. pour rappel:
