Pas une question technique, mais néanmoins valable. Scénario:
HP ProLiant DL380 Gen 8 avec 2 processeurs Xeon E5-2667 à 8 cœurs et 256 Go de RAM sous ESXi 5.5. Huit machines virtuelles pour le système d'un fournisseur donné. Quatre machines virtuelles à tester, quatre machines virtuelles à produire. Les quatre serveurs de chaque environnement remplissent différentes fonctions, par exemple: serveur Web, serveur d'applications principal, serveur de base de données OLAP et serveur de base de données SQL.
Partages d'UC configurés pour empêcher l'environnement de test d'avoir un impact sur la production. Tout le stockage sur SAN.
Nous avons posé des questions sur les performances et le fournisseur a insisté sur le fait que nous devions donner au système de production plus de mémoire et de vCPU. Cependant, vCenter montre clairement que les allocations existantes ne sont pas touchées, par exemple: une vue mensuelle de l'utilisation de l'UC sur le serveur d'applications principal oscille autour de 8%, avec une pointe pouvant atteindre 30%. Les pics ont tendance à coïncider avec le démarrage du logiciel de sauvegarde.
Histoire similaire sur RAM: le taux d'utilisation le plus élevé sur les serveurs est d'environ 35%.
Nous avons donc fait des recherches en utilisant Process Monitor (Microsoft SysInternals) et Wireshark, et nous recommandons au fournisseur d’effectuer certains réglages TNS en premier lieu. Cependant, c'est en dehors du point.
Ma question est la suivante: comment pouvons-nous leur faire reconnaître que les statistiques VMware que nous leur avons envoyées sont une preuve suffisante que plus de RAM / vCPU n’aidera pas?
--- MISE À JOUR 12/07/2014 ---
Semaine intéressante. Notre direction informatique a déclaré que nous devrions modifier les allocations des ordinateurs virtuels. Nous attendons maintenant un certain temps d'indisponibilité de la part des utilisateurs professionnels. Étrangement, ce sont les utilisateurs professionnels qui disent que certains aspects de l'application fonctionnent lentement (par rapport à ce que je ne sais pas), mais ils vont "nous le faire savoir" quand nous pourrons mettre le système en panne (grommeler , grogne!).
En passant, l'aspect "lent" du système n'est apparemment pas l'élément HTTP (S), c'est-à-dire "l'application mince" utilisé par la plupart des utilisateurs. On dirait que ce sont les installations du "gros client", utilisées par les principaux organismes financiers, qui sont apparemment "lentes". Cela signifie que nous examinons maintenant les interactions client / serveur dans nos enquêtes.
Comme le but initial de la question était de demander de l’aide afin de déterminer s’il fallait emprunter la voie du «piquer-le» ou simplement apporter le changement, et nous procédons maintenant au changement, je vais le terminer en utilisant la réponse de longneck .
Merci à tous pour votre participation; comme d'habitude, serverfault a été plus qu'un simple forum - c'est un peu comme le canapé d'un psychologue :-)