Version imprimable
Bonjour,
J'ai un probleme de perf sur mon SQL2K il est tres lent. J'ai réinstallé un autres serveur SQL2K, j'ai créer dessus les meme base et injecté les DATA. Celui ci est bcp plus rapide que l'ancien comment faire pour rendre a mon ancien serveur toute ces facultées ? Comparasion de conf ?
SQL2k0 SP3 sous windows 2k3 SP
Cordialement
Pour chaque environnement:
- Modèle de machine
- Nb CPU
- Mémoire
- Disques
Compteurs de perfs:
\Memory\Available MBytes
\Processor\Processor Time %
Paramètres de SQL Server:
- max server memory
Les deux machines sont sous vmware :
La premiere ( qui est pas assé rapide )
4 cpu
4Go
4 disque mais tout est sur la meme baie
Windows 2k3 & sql2k sp3
La seconde
2 cpu
2Go
2 disques sur la meme baie que l'autre serveur
Windows 2k3 sp2 & sql2k sp4
La seconde est beaucoup plus rapide que la premier et c'est bien ca le probleme
Déjà, le fait que la seconde machine soit sous un OS SP2 alors que l'autre est en RTM, ça change au niveau du support matériel : les SP sont souvent accompagnés d'optimisations au niveau du support matériel (entre autres) mais aussi de corrections qui comportent des optimisations.
Idem pour le SP de SQL Server : le SP4 peut parfaitement apporter des évolutions en termes de performances et d'exploitation du matériel par rapport au SP3.
Tu devrais comparer avec les mêmes versions.
Ensuite, des pistes :
- Rechercher les process qui tourne sur le vieux serveur et les comparer avec le nouveau : logiciel tiers qui met le bordel ?
- Vérifier la version des VM : l'ancienne VM est peut-être dans une vieille version, ça peut affecter les performances.
- Vérifier la fragmentation sur le serveur hôte : peut-être que les fichiers de la vieille VM sont fragmentés, et pas ceux de la nouvelle.
- Vérifier la fragmentation des disques sur la vieille VM : si c'est une base qui a beaucoup vécu, les fichiers de data en croissance automatique peuvent grandement se fragmenter.
- Vérifier les index : lors de la restauration, je ne serais pas étonné que SQL Server le recrée les index sur la nouvelle config, mais que sur l'ancienne tout soit en bordel dans les index.
Et... Les deux VM sont sur la même machine physique ou pas ?
=> Parceque si c'est pas la même machine, il y a peut-être une différence de matériel/logiciel/charge entre les deux machines hôtes non ?
Ok les deux machines sont sur le meme serveur vmware et en meme version.
Je craind de mettre a jour et que plus rien ne fonctionne.
Je ne comprend pas de quelle fragmentation tu parle !!!!!
Dans une VM, il y a deux niveaux de fragmentation :Citation:
Envoyé par k2011
1/ Les fichiers physiques du disque dur hôte (surtout si les VM utilisent des disques virtuels) : qu'ils soient dans une baie ou non, ils se fragmentent. Il faut veiller à ce qu'ils le soient le moins possible.
2/ Dans la VM, les bases de données sont scindées en X fichiers. Ces fichiers sont amenés à grossir : ils se fragmentent donc obligatoirement, surtout si ces fichiers grossissement petit à petit : il faut donc veiller à ce qu'ils soient le moins possible fragmentés, que ta machine utilise des disques virtuel ou physiques.
Il y a donc deux defrag à faire :
1/ Une sur le seveur hôte (si possible, il faut couper toutes les VM avant, histoire de pouvoir défragmenter les fichiers des VM)
2/ Sur chaque VM, en coupant au préalable si possible les services (notamment SQL Server)
Avec SQL Server, il y a aussi un troisième niveau de fragmentation : celui des index (et des données dans les tables). A nouveau, dans SQL Server, il y a des outils pour recalculer les index et éventuellement réorganiser les données dans le fichier de données.
Défragmenter à l'intérieur des VM, les disques utilisés par SQL Server ??
Cela revient au fait de le faire également si tu n'es pas dans une VM ?
Je pensais que le moteur de MS SQL Server était un grand garçon et, à partir du moment où les tailles des fichiers sont correctement paramétrées, il se débrouillais pour placer correctement ses fichiers aux bons endroits du disque (à l'extérieur). Et que du coup, il était même déconseillé d'appliquer des défrag classiques de fichiers là où sont positionnés les fichiers de données du moteur.
Ok je comprend.
La baie vien d'etre installée il y a 2 mois et avant le serveur etait 100% physique , il a donc été virtualisé.
Je viens de lancer DBCC SHOWCONTIG WITH TABLERESULTS, ALL_INDEXES sur mes deux server pour esperer voir quelque chose de flagrant et là c'est le drame; car d'un coté le temps d'execussion est de 4 min et de l'autre je suis à 10 min et ca tourne toujours.
Ca promet !!!!!!!!!
Tout d'abord tu parles de lenteur ... donc à quel niveau ? Est ce que tu peux nous en dire plus ?
--> Est ce un problème de ressources ? (CPU, disques, RAM). Voyez ce que dbaffaleuf vous demande en terme de métrique dans un post plus haut.
--> Est ce un problème de configuration applicative ? N'avez vous pas un antivirus qui serait à l'origine de vos lenteurs ?
Est ce un problème de configuration des machines virtuelles ? Avec les machines virtuelles il est facile d'avoir des problèmes de performances si les ressources ne sont pas correctement alloués côté ESX ... Est ce que les ressources sont dédiés à SQL Server ou sont elles partagés avec d'autres hôtes virtuels ? Est ce que les datastores sont dédiés à SQL Server ou sont ils partagés avec d'autres hôtes ?
Si j'en crois la configuration actuelle de k2011 la défragmentation n'apportera rien et peut même engendrer des problèmes de performances :Citation:
Dans une VM, il y a deux niveaux de fragmentation :
1/ Les fichiers physiques du disque dur hôte (surtout si les VM utilisent des disques virtuels) : qu'ils soient dans une baie ou non, ils se fragmentent. Il faut veiller à ce qu'ils le soient le moins possible.
2/ Dans la VM, les bases de données sont scindées en X fichiers. Ces fichiers sont amenés à grossir : ils se fragmentent donc obligatoirement, surtout si ces fichiers grossissement petit à petit : il faut donc veiller à ce qu'ils soient le moins possible fragmentés, que ta machine utilise des disques virtuel ou physiques.
- Au niveau du SAN, la plupart des défragmentateurs ne sont pas au courant de l'implémentation physique des clusters sur disque. Le système d'exploitation ne voit qu'une représentation logique du disque (LUN). Défragmenter un disque depuis le système d'exploitation peut allonger la distance qu'il existerait entre la tête de lecture d'un des disques et le secteur qui contient le bloc de données. De plus en fonction du RAID sous jascent, l'overhead IO peut être très important (calcul de parité pour le RAID 5 et 6 qui sont les raid les plus utilisés sur ce type de stockage).
- Même chose pour les VMFS du fait de comment l'écriture des blocs se font sur ce type de stockage (un fichier VMFS peut se fragmenter bien entendu mais pas du point même point de vue Extent de Windows). Le système d'exploitation ne voit ici qu'une abstraction du stockage. C'est l'hyperviseur qui se charge de translater les opérations IO du système d'exploitation sur le stockage virtuel.
++
Justement positionnez les compteurs qui vont bien pour pouvoir vous faire une idée !Citation:
Envoyé par k2011
A titre de test et pour savoir si votre stockage est en cause , que donne une copie de fichier (plus ou moins important) sur un de vos disques ?
++
Je j'ai enfin le resulta du dbcc showcontig et les chiffres ( meme si je les comprend pas ) semble indiquer une énorme diferrence.
%Frag = LogicalFrangmentation
Nom de l'objet %frag %frag Difference
VAL_TACHES_USER 100,00 0,00 100,00
IF_MYSQL 100,00 0,00 100,00
LOGCLIENT 99,99 0,00 99,99
ERRORLOG 99,98 0,00 99,98
ABS_USER 99,98 0,00 99,98
PRODUIT 99,96 0,00 99,96
SAVE_TVTRANSFERT_2 99,95 0,00 99,95
ERRORLOG 99,95 0,00 99,95
PRODCLI_EXT 99,91 0,00 99,91
MLTASK 99,89 0,00 99,89
LOGINTV 99,88 0,00 99,88
LOG_CENTRA 99,83 0,00 99,83
FAMPRODUIT 33,33 0,00 33,33
Visiblement vous avez pas mal de fragmentation logique sur vos tables. Vous pouvez tenter une reconstruction de vos indexes (mais là je me pose la question de savoir pourquoi une telle différence .. est ce que vous avez eu de l'activité entre temps ?)
++
C'est un peu particulier car l'un des deux serveur est celui de prod et l'autre est pour faire des test. Il y a 1 semaine de difference dans les data mais meme si je restaure les data de hier sur le nouveau serveur je jsuis certain que les resultat seron les meme.
Concernant les metric , j'ai les courbes sous les yeux mais je ne sais pas quelles chiffres vous fournir ! la moyenne ?
New server
Memory average 132
Proc average 0.308
Old server
Memory average 1022
Proc average 12
Pour defragmanter tout ca je fais quoi.
Je pourrais chercher sur le net mais je prefere m'en remettre a vos experrience avec les options qui vons bien
Compteurs proposés par dbaffaleuf :
\Memory\Available MBytes
\Processor\Processor Time %
Paramètres de SQL Server:
- Max server memory
+
\SQLServer:Buffer Manager\Page Life Expectancy
\SQLServer:Buffer Manager\Buffer Cache Hit Ratio
Regardez ces compteurs lorsque vous lancez un DBCC SHOWCONTIG par exemple.
++
pour le max memory c'est 3071 sur l'ancien et 2047 sur le nouveau
Avec ce script : http://blog.developpez.com/sqlpro/p8...des-statisti/*Citation:
Envoyé par k2011
A +
Non, SQL ne gère pas physiquement où va être enregistré son fichier : c'est l'OS qui fait ce travail.Citation:
Envoyé par Jinroh77
Donc le fichier MDF peut parfaitement est découpé en 1000 fragements, SQL Server ne sera même pas au courant.
En revanche, SQL Server s'assure de stocker les données d'une même table à la suite les un des autres... Dans une certaine mesure : quand une table dépasse la taille qu'il avait prévu, l'espace suivant au sein du fichier peut déjà être occupé. A ce moment, pour éviter de mettre 3 minutes à déplacer 2 Go de données et faire attendre tout le monde, il se met à fragmenter à l'intérieur du fichier MDF. C'est là que les fonctions d'administration entrent en jeu (je ne les connais pas, j'en ai jamais eu besoin - utilisation perso de SQL Server, avec des bases qui sont toujours restées de taille raisonnables)
-- Edit après lecture du post de mikedavem
(ceci s'applique effectivement plutôt sur un disque physique dans un serveur et non un SAN)
Idem pour les fichiers à l'intérieur d'un disque virtuel : que le fichier du disque virtuel soit fragmenté ou non ne change pas le fait que les données à l'intérieur du fichier peuvent aussi être fragmentées ou non : il faut donc bien effectuer un defrag à la fois sur la machine hote et ensuite dans les machines virtuelles.
Ceci dit, certains SAN proposent un defragmenteur.
Et je suis persuadé (à partir du moment où les fichiers physiques ne sont pas fragmentés) que le defrag dans VM apporte quelquechose.