Comment estimez-vous la quantité de mémoire à acheter?

J'ai une application serveur personnalisée qui s'exécute sur Windows 2008 R2. Il s'agit d'un service Windows maison écrit en .Net prenant en charge un certain nombre de terminaux personnalisés. J'ai une machine de test qui a une spécification similaire au serveur live et j'ai un ensemble de simulateurs clients que je peux utiliser pour produire une charge qui est une approximation raisonnable du système réel. Je dois pouvoir prendre en charge 12 000 d'entre eux et actuellement le serveur manque de mémoire (la pagination passe par le toit).

Mon plan était de démarrer seulement 100 des simulateurs, de mesurer l'utilisation de la mémoire, puis de recommencer 100 autres mesures de la mémoire et de répéter jusqu'à ce que la pagination commence à monter (en réalité, je prendrai plus de trois points de données.) Cela devrait me donner un chiffre pour la quantité de mémoire supplémentaire requise pour 100 simulateurs et me permet de projeter la quantité de mémoire requise. Je n'ai besoin que d'une idée approximative de +/- 30 Go pour éviter d'acheter la totalité des 2 To (150 000 $) que le serveur prendra. Ma question est de savoir s'il s'agit d'une méthode raisonnable à utiliser et, dans l'affirmative, quels compteurs de performances surveilleriez-vous pour donner la quantité de mémoire réellement utilisée?

Je parle spécifiquement de mémoire ici car la différence entre Working Set, Private Bytes, Committed, Shared, Virtual et tous les autres termes de mémoire me confond. Je pense que je peux gérer par moi-même le CPU, les E / S et les réseaux. L'autre chose que j'ai remarquée est que le cache .Net ajuste son utilisation de la mémoire en fonction de ce qui est disponible, ce qui rend la détection d'une tendance difficile à voir.

Honnêtement? Je ne ai pas .
Lors de la spécification d'un serveur qui verra tout type de charge de travail réelle, j'incruste autant de RAM que je peux raisonnablement me le permettre (les systèmes sont plus susceptibles de se retrouver contraint par la RAM que par le CPU ou le disque - le seul autre goulot d'étranglement garanti est le front-side autobus).

Si vous voulez savoir combien de RAM de votre application peut utiliser un test de charge de base comme vous avez proposé est un bon début, mais si vous avez déjà avez ce système dans la production (il semble que vous faites) et votre système de production est de troquer votre la tâche est plus facile: déterminez la quantité d'espace de swap que vous utilisez -> Ajoutez au moins 2 fois plus de RAM (arrondissez pour l'adapter aux contraintes de taille DIMM de votre système).

Si vous effectuez un test de charge pour obtenir des chiffres approximatifs et extrapoler à partir de là, n'oubliez pas de prendre en compte quelques éléments:

1. La courbe de mémoire sera probablement constituée de deux segments distincts
   (montée en puissance initiale initiale lorsque les frameworks / bibliothèques partagées sont mis en cache, puis une courbe légèrement moins raide lorsque le code non partageable de chaque nouvelle application est mis en mémoire)

2. Vous avez toujours besoin de RAM gratuite pour la mise en cache du disque et de la bibliothèque partagée et pour le système d'exploitation.
   (Cela devrait être au moins quelques concerts sur les besoins de votre application)

3. TOUS les logiciels perdent de la mémoire (du moins tous les logiciels pratiques), alors faites attention à cela dans vos tests et assurez-vous d'avoir la place pour faire face à une fuite.

4. Votre charge augmentera probablement au cours de la durée de vie du serveur. Planifiez en conséquence.
   (Si vous n'avez pas de bons chiffres de planification de capacité, doublez la charge de travail d'aujourd'hui et prévoyez de gérer cela).

5. Acheter trop de RAM aujourd'hui est moins cher que de faire tomber votre environnement demain.

   • Premier corollaire: si vous achetez un serveur légèrement plus grand que ce dont vous avez besoin, vous êtes l'administrateur prémonitoire qui a fait fonctionner l'entreprise. Vous serez largement ignoré et méconnu.
   • Deuxième corollaire: si vous sous-dimensionnez la machine et qu'il y a des problèmes, vous êtes le bouffon incompétent qui ne pouvait pas anticiper une croissance de 500%, et tout le monde vous déteste.

Merci, la mise à jour donne au moins à tout le monde un indice. Le fait que vous envisagiez 2 To de mémoire signifie que vous jouez dans un stade différent des configurations habituelles. Grand système. Je déteste penser à la quantité de chaleur qui va être émise.

Étant donné que c'est un processus serveur interne et que vous manquez de mémoire (vous ne dites pas à quel niveau vous commencez la pagination), mais je voudrais éliminer la possibilité que le processus serveur consomme des quantités de mémoire toujours plus importantes avant de commencer plus loin. Si cela se produit, cela ne fait aucune différence ce que vous faites, le système s'arrêtera à un moment donné.

Je ne connais aucun outil générique que vous pouvez utiliser pour vous donner bien plus qu'un aperçu de base de ce qui se passe ... ce qui vient avec Windows. Le processus de service lui-même est une boîte noire et votre équipe de développement doit fournir des outils de surveillance.

Retour rapide du calcul de l'enveloppe:

2Tb of memory = 1024Gb = 1024*1024Mb = 1048576Mb
1048576Mb / 13000 connections = around 80mb per session

Ce ne serait pas hors de la plage de travail d'un exe .net normal.

Le service a-t-il plusieurs threads? S'ils lancent un thread pour chaque connexion, il vaudrait la peine de voir comment ils le font. ProcExp.exe de Microsoft est un moyen facile de voir si vous avez plusieurs threads et ce que ces threads consomment. Il ne connaît pas .net mais vous donnera des compteurs win32.

Pouvez-vous indiquer la quantité de mémoire et le nombre de connexions que vous aviez lors de vos tests avant le début de la pagination?

Alors, comment savoir si le processus serveur a des problèmes de fuite de mémoire? Cela pourrait accumuler plus de mémoire à chaque session connectée, ou cela pourrait accumuler de la mémoire et ne jamais les libérer.

Ce que vous pourriez faire est de choisir un certain nombre de sessions qui ne provoquent pas de pagination et de simuler ce nombre de connexions. - Exécutez la simulation sur quelques heures et utilisez perfmon pour regarder les compteurs de mémoire de base. - Répétez ces tests avec des sessions qui se connectent brièvement et se déconnectent.

L'idée étant de voir si le service consomme de plus en plus de mémoire à chaque session, ou si les sessions ouvertes provoquent une utilisation toujours croissante de la mémoire.