N'avez vous pas non plus un antivirus qui ferait de l'analyse à l'accès en temps réel sur vos fichiers de données ?
++
Version imprimable
N'avez vous pas non plus un antivirus qui ferait de l'analyse à l'accès en temps réel sur vos fichiers de données ?
++
Oui, nous avons vérifié la config de nos drivers, firmwares et version de MPIO. Tout est OK à ce niveau là.
Par contre, je ne m'explique pas en utilisant les mêmes vdisks sur un serveur avec moins de CPU, cela fonctionne parfaitement.
Je vais réduire le nombre de fichiers de la tempdb (J'ai 4 Lun : je vais essayer 1 fichier/Lun). Nous avons aujourd'hui 4 procs x 6 coeurs.
Non, les partitions de données et autres ont été exclues de l'antivirus.
La, j'ai des attentes de type PAGEIOLATCH_EX en permanence lors d'un update sur ma base utilisateur principale et plus de lock qu'avant sur la tempdb.
Regardez également le paramétrage des files d'attentes de vos cartes HBA ...
Qu'avez vous comme valeur ?
J'ai eu le cas lors de mon dernier audit ... une valeur trop élevée de ce paramètre augmente considérablement les temps de latence des sous systèmes disques avec des pageiolatch importants ...
++
Je ne sais pas ou trouver ce paramétrage de file d'attente... Pouvez-vous m'éclairer?
De plus, hier soir, j'ai fait tourné mon traitement de référence avec 4 datafiles pour ma tempdb (1 datafile par Lun) : le traitement est toujours en cours ce matin. Je n'ai plus de lock de tempdb mais des waits de type PAGEIOLATCH_EX avec 2:8:120158 (à quoi cela correspond ?)
Merci.
Vous êtes donc en serveur virtuel et non physique ???Citation:
Envoyé par davy.g
Si vous voulez des performances, commencez par dévirtualiser. La virtualisation tue les performances des SGBDR comme SQL Server.
Lisez ce que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p8...irtualisation/
http://blog.developpez.com/sqlpro/p8...t-le-stocakge/
A +
Non, je ne suis pas sur des environnements virtualisés mais physiques.
J'ai présenté les mêmes Luns sauf ceux contenant les bases systèmes évidemment (puisque j'ai dû faire un nouvelle install sur cet autre serveur).
Vdisk signifie partition sur du SAN HP.
S'il n'y a plus que 4 fichiers, celà paraît étrange car 2:8:120158 indique une contention sur le 8ième fichier. Pouvez-vous nous retourner le résultat de :
Code:select file_id, type_desc, name, physical_name, size/128, max_size/128 from tempdb.sys.database_files
Pour info:
2=> database_id
8=> file_id
120158=>pageid
et la requête sur les waits mentionnée plus haut SVP ?
1 ROWS tempdev K:\Program Files\Microsoft SQL Server\MSSQL10_50.LPT_BI_PRD\MSSQL\Data\tempdb.mdf 16384 0
2 LOG templog P:\Program Files\Microsoft SQL Server\MSSQL10_50.LPT_BI_PRD\MSSQL\Data\templog.ldf 16000 0
4 ROWS tempdb10 S:\Program Files\Microsoft SQL Server\MSSQL10_50.LPT_BI_PRD\MSSQL\Data\tempdb10.ndf 16384 0
8 ROWS tempdb4 Q:\Program Files\Microsoft SQL Server\MSSQL10_50.LPT_BI_PRD\MSSQL\Data\tempdb4.ndf 16384 0
11 ROWS tempdb7 R:\Program Files\Microsoft SQL Server\MSSQL10_50.LPT_BI_PRD\MSSQL\Data\tempdb7.ndf 16384 0
Voici le résultat pour les waits :
Citation:
IO_COMPLETION 410.535000 410.385000 0.150000 78886 50.822121645778347
PAGEIOLATCH_EX 184.233000 184.036000 0.197000 23268 22.807097901924762
SLEEP_DBSTARTUP 150.938000 139.498000 11.440000 1376 18.685348135897042
SLEEP_BPOOL_FLUSH 44.194000 43.984000 0.210000 22550 5.470989913195046
Ok vous fonctionnez en mode stockage virtualisé avec du provisionning derrière d'après ce que vous avez écrit.
Vous devez aller directement sur votre machine physique dans la configuration des cartes HBA (en redémarrant le serveur vous devez avoir au boot de la machine une touche menu pour y accéder) ou vous pouvez également le faire depuis Windows si l'utilitaire est installé.
Le paramètre correspond en général à Queue Depth dans les settings de la carte. Voyez si la valeur du paramètre est égale à 64K ou 128K.
Les temps d'attente vont dans ce sens .. votre sous système disque n'a pas l'air de pouvoir absorber la charge initiée par votre activité du serveur.
Il faudrait pouvoir avoir corréler ceci avec les valeurs de compteurs de performance :
% disk read
% disk write
Avg Queue Length
Avg. disk sec / read
Avg. disk sec / writes
Avg. disk sec / transfer
++
OK. Je vais aller voir ce paramétrage. Nous sommes aussi en relation avec HP qui nous demande de faire un test avec du Windows Server 2008R2.
Je dois réinstaller mon serveur et vous fait un retour par rapport au résultat des compteurs que vous me demandez.
Merci beaucoup pour votre aide.
A bientôt.
Concernant notre stockage : nous utilisons un serveur physique relié à une baie HP EVA 6100.
Par contre, je rapelle que lorsque nous utilisons un serveur HP DL 380 G7 avec les mêmes cartes HBA et les mêmes disks SAN, nous n'avons pas de problème de performance.
Ok vous êtes à peu près dans les mêmes conditions que mon dernier client .. virtualisation du stockage .. vous pouvez donc provisionner en principe plus facilement d'espace disque que sur les SAN classiques.Citation:
Concernant notre stockage : nous utilisons un serveur physique relié à une baie HP EVA 6100.
Quelle configuration VRAID avez vous ?
Vous utilisez quoi comme OS ? 2003 ?
++
Les partitions de données sont en RAID5.
Les partitions des journaux et de la tempdb sont en RAID1.
Nous sommes sur du Windows Server 2003 R2 X64 Ent. Ed. avec du Sql Server 2008 R2.
Quelque chose qui pourrait vous faire gagner en performance est l'alignement des partitions vu que vous êtes en Windows 2003..
++
Nous avons déjà aligner les partitions via diskpart :
Citation:
create partition primary align=64
Idéalement la taille du stripe unit du RAID5 entre aussi en ligne de compte. On met en général 1024 pour couvrir toutes les tailles de stripes possibles alignées sur 64K. As-tu formatté NTFS avec une taille de cluster de 64K aussi pour les données ?
Le RAID 5 est fortement à déconseillé au niveau des SGBDR !
A +