none
SQL 2014 sur VM sous HYPERV 2012r2 bonnes pratiques RRS feed

  • Question

  • Bonjour,

    Je ne connais rien en SQL......

    Actuellement j'ai plusieurs hôtes (DELL r740 avec 64 Go de MEM) avec HYPERV 2012r2.

    Ceux ci virtualise des VM avec SQL.

    Parfois j'ai jusqu’à 4 VM avec chacune SQL 2014 dessus.

    J'ai en moyenne 30 utilisateurs par serveurs.

    Les VM disposes entre 16-20 Go de MEM.

    Pour information : souvent ce sont des serveurs RDS avec OUTLOOK de configurer sur chaque session.

    J'utilise

    -2Vcpu par VM

    -Des VHDX en mode fixe 

    -De la mémoire en mode fixe

    En dehors de cela les réglages sont par défaut.

    Cela fonctionne globalement bien mais j'ai de temps en temps le message ci desous :

    Ce message indique que je dois augmenter la mémoire vive de la VM ?

    ou que je dois modifier un paramètre sous SQL ?

    Pouvez vous m'expliquer comment régler correctement SQL sur HYPERV ?

    merci d'avance


    "Marquer comme réponse" les réponses qui ont résolu votre problème




    mercredi 25 juillet 2018 10:01

Réponses

  • En fait c'est le nom de la DLL qui m'a mis sur la piste.

    Et en cherchant un peu sur Internet on voit que c'est effectivement le cas et que cela pose des pbm :
    https://forum.pcsoft.fr/fr-FR/pcsoft.fr.windev/214586-plantage-application-windev-suite-arret-iexplorer-avec-module/read.awp
    Donc si c'est lié à WinDev, on ne pourra rien faire.

    Mais on peut quand même vérifier qu'il n'y a pas de problème sur SQL car le support Cegid va forcément incriminer SQL plutôt que leur développement.

    Pour avoir des infos sur la table et la SP :

    sp_help [nom table]

    et sp_help_text [nom procédure]

    Le fait qu'il n'y ait pas QUE SQL Server sur la VM brouille les pistes en diagnostic. SQL est vraiment hyper stable d'un point de vue consommation mémoire, surtout depuis SQL Server 2012.

    Par contre, on ne peut pas en dire autant de tous el)s applicatifs. C'est pour cela que je recommande fortement une VM dédiée SQL Server.

    dans votre cas, imaginons simplement que chaque user parmi les 30 consomme 500MB de RAM (faites un test avec un start de Outlook et un browser par exemple, on est quasi au dessus), cela reviendrait à consommer 15GB.

    Et il faut ajouter à cela la RAM pour l'OS, 4 à 6GB et le pauvre SGBD qui doit se battre pour en avoir un peu.
    Bref, un peu sous dimensionné à mon avis.

    64 GB seraient plus adaptés sur les VMs : 30 users à 1.5 GB RAM, cela permet de garder 12 ou 14 GB pour l'instance SQL. J'imagine que les BD ne sont pas très grosses, cela devrait passer.

    Christophe


    Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

    samedi 13 octobre 2018 08:53

Toutes les réponses

  • Peut être Christophe LAPORTE (- Independent Consultant & Trainer - SQL Server MVP-MCM) pourrai me donner sont avis ? :)

    J'ai lu son article sur HyperV 2008 & SQL c était intéressante mais plus d'actu.


    "Marquer comme réponse" les réponses qui ont résolu votre problème



    mercredi 25 juillet 2018 17:47
  • Je relance en haut de la pile

    "Marquer comme réponse" les réponses qui ont résolu votre problème

    mardi 7 août 2018 13:45
  • Bonjour

    Malgré le message, je ne pense pas qu'il s'agisse d'un pbm de mémoire, le message ne ressemblerait aps du tout à celui là.

    Question 1 : 

    Est-ce que par hasard l'applicatif est développé en WinDev ?

    Question 2 :

    Quelle est la structure de la table manipulée par la SP ? des gros varchar ou Nvarchar qui excèderaient la taille maxi d'un enreg ....

    Au moment où le problème se produit, si c'est vraiment un soucis côté SQL Server on devrait avoir des infos dans l'xEvent system_health.

    Christophe


    Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

    vendredi 12 octobre 2018 14:08
  • Bonjour

    Bonjour christophe

    Malgré le message, je ne pense pas qu'il s'agisse d'un pbm de mémoire, le message ne ressemblerait aps du tout à celui là.

    Question 1 : 

    Est-ce que par hasard l'applicatif est développé en WinDev ?

    Application développé par CEGID.

    Je ne sais pas si celle ci est en WINDEV.

    Comment je peux savoir ?

    Question 2 :

    Quelle est la structure de la table manipulée par la SP ?

    des gros varchar ou Nvarchar qui excèderaient la taille maxi d'un enreg ....

    Peut tu me donner un moyen de trouver l'information ?

    (avec une capture d’écran ce serait top !

    Au moment où le problème se produit, si c'est vraiment un soucis côté SQL Server on devrait avoir des infos dans l'xEvent system_health.

    Je vais regarder de ce coté aussi.

    Christophe

    Merci


    Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM



    "Marquer comme réponse" les réponses qui ont résolu votre problème

    samedi 13 octobre 2018 04:08
  • En fait c'est le nom de la DLL qui m'a mis sur la piste.

    Et en cherchant un peu sur Internet on voit que c'est effectivement le cas et que cela pose des pbm :
    https://forum.pcsoft.fr/fr-FR/pcsoft.fr.windev/214586-plantage-application-windev-suite-arret-iexplorer-avec-module/read.awp
    Donc si c'est lié à WinDev, on ne pourra rien faire.

    Mais on peut quand même vérifier qu'il n'y a pas de problème sur SQL car le support Cegid va forcément incriminer SQL plutôt que leur développement.

    Pour avoir des infos sur la table et la SP :

    sp_help [nom table]

    et sp_help_text [nom procédure]

    Le fait qu'il n'y ait pas QUE SQL Server sur la VM brouille les pistes en diagnostic. SQL est vraiment hyper stable d'un point de vue consommation mémoire, surtout depuis SQL Server 2012.

    Par contre, on ne peut pas en dire autant de tous el)s applicatifs. C'est pour cela que je recommande fortement une VM dédiée SQL Server.

    dans votre cas, imaginons simplement que chaque user parmi les 30 consomme 500MB de RAM (faites un test avec un start de Outlook et un browser par exemple, on est quasi au dessus), cela reviendrait à consommer 15GB.

    Et il faut ajouter à cela la RAM pour l'OS, 4 à 6GB et le pauvre SGBD qui doit se battre pour en avoir un peu.
    Bref, un peu sous dimensionné à mon avis.

    64 GB seraient plus adaptés sur les VMs : 30 users à 1.5 GB RAM, cela permet de garder 12 ou 14 GB pour l'instance SQL. J'imagine que les BD ne sont pas très grosses, cela devrait passer.

    Christophe


    Christophe LAPORTE - Independent Consultant & Trainer - SQL Server MVP-MCM

    samedi 13 octobre 2018 08:53
  • Je te remercie pour ton aide tu es un chef !

    Tu m'as apporté tout les éléments dont j'avais besoin.

    Bonne journée Christophe.


    "Marquer comme réponse" les réponses qui ont résolu votre problème


    samedi 13 octobre 2018 11:50