w3wp.exe mémoire de porcs


8

Sur une installation de Small Business Server 2011, un nombre entier de processus w3wp.exe semblent utiliser une quantité disproportionnée de mémoire. Les installations prêtes à l'emploi SBS sont livrées avec un total de 7 sites et 20 pools d'applications ASP.NET (Sharepoint, Exchange, WSUS et des éléments spécifiques à SBS comme Remote Web Workplace).

La douzaine de processus w3wp.exe qui en résulte a tendance à consommer plus de 4 Go de mémoire du serveur au fil du temps, le pool d'applications de pointe étant celui appartenant à WSUS avec environ 800 Mo dans le jeu de travail. Le recyclage manuel des pools d'applications via IIS MMC permet de réduire temporairement l'utilisation de la mémoire (les processus w3wp.exe diminuent à 10 Mo, certains repoussant rapidement), mais ce n'est évidemment pas quelque chose qu'un administrateur veut faire toute la journée. Je n'ai pas pu trouver de recommandations sur le recyclage automatique des pools d'applications préinstallés SBS, donc je suis quelque peu réticent à "simplement le faire" sur les systèmes de production.

Ma recherche sur le net sur la façon de limiter cela n'a fait apparaître qu'un certain nombre de messages indiquant que la consommation de mémoire w3wp ne nuirait pas mais améliorerait les performances car la mémoire serait "libérée en cas de besoin par d'autres applications". Le problème est que cela ne fonctionne pas:

  • pour un, un SBS est un serveur multi-rôle, l'un des rôles (le principal) étant le stockage réseau CIFS qui profite énormément de la mise en cache du système de fichiers qui repose à nouveau sur la mémoire étant "libre" comme dans "non utilisé par d'autres processus dans aucun "- Les pools d'applications ASP.NET qui ne voient presque jamais les utilisateurs et mangent de la mémoire sont contre-productifs
  • une autre chose est que je dois encore voir une diminution substantielle de la consommation de mémoire des instances w3wp en cas de pénurie de mémoire - ce que je vois est une diminution mineure de beaucoup moins de 100 Mo et un échange excessif à la place - nuisant encore aux performances

J'administre rarement les applications IIS ou ASP.NET, donc toutes les idées sur la façon de réduire efficacement les besoins en mémoire pour les pools d'applications sont les bienvenues.


Que fait cette application ASP.NET? J'ai vu w3wp.exe utiliser beaucoup de mémoire lorsqu'une application ne parvient pas à fermer les connexions avec Linq-To-SQL ou Entity Framework.
Nate

Il y a plusieurs. Beaucoup sont liés à Exchange comme les services OWA / OMA et Sync, un exceptionnellement grand est WSUS, certains sont utilisés pour Sharepoint ou des sites personnalisés spécifiques à SBS (CompanyWeb, Remote Web Workplace)
the-wabbit

Réponses:


7

Bienvenue dans le monde merveilleux de SBS. Exigences recommandées pour la RAM = 10 Go ... et il nécessite un minimum de 8 Go. ( selon Microsoft .) pour une bonne raison. Ce n'est pas une machine bien huilée bien réglée ... elle est très bâclée, gonflée et a tout sous le soleil. Plus vous pouvez jeter de RAM dans cette boîte ... mieux c'est. Malheureusement, vous êtes limité à 32 Go maximum. À mon humble avis ... c'est idiot.


Je suppose que je devrais affiner un peu ma réponse. Si vous êtes préoccupé par la quantité de RAM qu'il consomme, vous vous épargnerez beaucoup de temps / maux de tête en effectuant l'une des opérations suivantes: A) N'utilisez pas SBS ... utilisez un serveur standard et configurez les rôles dont vous avez besoin individuellement. ou B) Ajoutez plus de RAM dans le système ... car la RAM est assez bon marché. SBS est conçu pour les très petits bureaux ... (10-20 postes de travail ...) et ne s'adapte pas très bien.
TheCompWiz

Merci pour votre réponse. Le système où j'ai observé le comportement avait 16 Go de RAM, ce qui est la limite physique. La mémoire disponible s'est rapidement remplie avec store.exe d'Exchange et de nombreuses instances de SQL Server et w3wp.exe qui n'est pas seulement "pas affiné" mais carrément braindead. Je sais comment gérer les problèmes de consommation de mémoire excessive des deux autres, car il m'arrive de gérer fréquemment des systèmes Exchange et SQL Server, mais avec w3wp, je suis un peu perdu. Le réseau lui-même ne compte que 11 utilisateurs.
the-wabbit

Exchange, SQL Server et IIS ont tous des mécanismes qui essaieront de consommer 100% de RAM pour les données "mises en cache". Si quelque chose d'autre demande plus de RAM ... tous les 3 sont censés évoluer pour permettre à d'autres services de fonctionner sans avoir recours à l'échange. (en théorie) En pratique, cependant, je trouve que vous avez juste à rouler avec les coups de poing sur certaines choses ... Vous pouvez essayer de tout modifier manuellement et définir des limites strictes ... mais vous serez toujours à la poursuite de votre queue celui-là. Je vais voir si je peux trouver un article que j'ai lu il y a quelques années sur la limitation des pools d'applications dans IIS pour vous ...
TheCompWiz



7

C'est ce que j'ai fini par faire:

réglage du cache de l' application de serveur pour les AppPools .NET à une faible valeur (5 Mo) en définissant le paramètre privateBytesLimit dans le web.configà %WINDIR%\Microsoft.NET\Framework\<version>\Configcomme suggéré dans cette réponse :

    <configuration>
      <system.web>
         <caching>
           <cache privateBytesLimit="5242880" privateBytesPollTime="00:01:00" />
         </caching>
      </system.web>
    </configuration>

Cela a permis de réduire l'utilisation de la mémoire à un peu plus de 1 Go avec les paramètres de recyclage de pool par défaut.

Apparemment, l'utilisation du type "serveur" de garbage collector ( <gcServer = "true">) peut également entraîner une consommation de mémoire importante , mais il semble <gcServer>être défini sur false par défaut.


Pour info - il y a quelque temps, nous avons commencé à définir gcserver sur false après avoir lu ces articles: forums.asp.net/t/1654596.aspx/1 et msdn.microsoft.com/en-us/library/ff647787.aspx
Greg Askew

@ the-wabbit Le conseil de définir gcServer = false est-il toujours d'actualité maintenant que le garbage collection du serveur se produit simultanément?
Michael Steele

6

Si vous pensez que la consommation de mémoire résultante est un problème dû à un défaut logiciel, vous pouvez utiliser Microsoft DebugDiag 1.2 pour créer un vidage mémoire complet et analyser le vidage pour les problèmes courants. Si vous pensez qu'il peut y avoir un problème de mémoire, vous devez activer le suivi des fuites en sélectionnant l'option "Surveiller les fuites" et le laisser fonctionner pendant un certain temps avant de créer / analyser le vidage.

DebugDiag 1.2 Télécharger
https://www.microsoft.com/download/en/details.aspx?id=26798

entrez la description de l'image ici

entrez la description de l'image ici

entrez la description de l'image ici


Merci pour le lien, je vais essayer. Le package d'installation MSI a apparemment des problèmes lorsqu'il est exécuté sur des versions localisées (non-US-Englisch) de Windows, je dois voir s'il y a une solution à cela.
le-wabbit

2

Vous n'avez pas besoin d'un pool d'applications distinct pour chaque application, seulement celles qui ne sont pas fiables ou auxquelles vous souhaitez donner la priorité. Beaucoup peuvent partager (en gardant différentes versions de .net séparées). Vous pouvez alors limiter de manière plus réaliste la mémoire qu'un pool d'applications utilisera. Il ne devrait pas être nécessaire de recycler plusieurs fois les pools plus d'une fois par jour.

De plus, il n'y a que peu de mémoire pouvant être libérée de cette manière. Bien que certains d'entre eux soient mis en cache, chaque application a besoin d'une certaine quantité de mémoire de travail qui dépend fortement de l'application Web spécifique. Essayer de trop restreindre cela va arrêter les choses.

Le problème est vraiment que SBS essaie d'en faire trop à la fois, vous devez regarder ce que vous utilisez réellement et arrêter ce que vous n'utilisez pas.

Mais pour être honnête pour seulement 11 utilisateurs, où va le reste de la mémoire? Exchange et SQL pour une utilisation légère n'ont certainement pas besoin de plus de 12 Go!


Ah, vous n'avez jamais connu la beauté d'un SBS, n'est-ce pas? La banque d'informations d'Exchange atteint 8 Go lorsqu'elle n'est pas restreinte, plusieurs instances de serveur SQL prendront volontiers 3 Go supplémentaires. La plupart des pools d'applications exécutent seulement 1 à 2 applications avec la même version .NET et dans le même contexte de sécurité. Pourtant, je ne peux pas les regrouper en raison de problèmes de support. Il est également peu probable qu'il résout les problèmes de mémoire - si je n'ai que 4 processus de 1 Go au lieu de 12 plus petits, pas grand-chose n'est gagné.
the-wabbit

La différence avec moins de pools d'applications est que les différents caches seront remplis de ce qui est régulièrement utilisé, éliminant ce qui ne l'est pas. Avec beaucoup de pools d'applications, il y aura plus de gaspillage. De combien de contextes de sécurité avez-vous réellement besoin avec 11 utilisateurs? Oui, Exchange utilisera gaiement autant de votre mémoire que possible, mais il fonctionnera également avec plaisir sur seulement 2 Go pour ces quelques utilisateurs si vous le limitez. Avec SBS, vous devez accepter que vous ne pouvez pas utiliser les meilleures pratiques partout ou exécuter l'une des options de manière optimale, vous devez être un peu pragmatique et ne pas trop ingénier les choses.
JamesRyan

Eh bien, si vous essayez d'en exécuter 20 instances sur un serveur, pas étonnant que vous essayez de tout mettre en mémoire. Vous auriez vraiment dû mentionner cela dans la question, car cela met les choses sous un jour entièrement différent.
JamesRyan

En fait, je ne le fais pas - comme je l'ai dit, le problème se pose avec un système physique où les pools d'applications rarement utilisés volent la mémoire du cache du système de fichiers beaucoup plus précieux. Je soupçonnais que cela serait dû à une mise en cache d'objets dans les pools d'applications et je cherchais un moyen de réduire / désactiver le cache.
le-wabbit
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.