Utilisation de deux groupes de files sur un RAID 10

Si un server Microsoft SQL Server 2008 Standard Edition est configuré comme ci-dessous, l'option 1 offre-t-elle un avantage sur l'option 2?

Configuration de base:

  • 32 Go de RAM
  • 2 x Xeon 7460 (6 kernelx)
  • Windows Server 2008 Standard SP2
  • Microsoft SQL Server 2008 Standard SP1
  • 2 x 146 Go 15K RPM HDD dans RAID 1 (pour le operating system)
  • 2 x 146 Go 15K RPM HDD dans RAID 1 (pour les journaux)
  • 4 x 146 Go 15K RPM HDD dans RAID 10 (pour datatables)

Option 1:

Configurez un disque virtuel sur le RAID 10 et utilisez un groupe de files

Option 2

Configurez deux disques virtuels sur RAID 10 et utilisez deux groupes de files

Le bon sens me dit qu'il n'y aurait pas d'avantage de vitesse car le RAID 10 n'est toujours capable de lire / écrire qu'à la même vitesse.

Quelqu'un peut-il conseiller si le bon sens prévaut ou s'il y a une raison pour laquelle j'ai négligé pourquoi cela serait avantageux?

Je ne sais pas s'il existe une amélioration de la performance pour plusieurs groupes de files, mais vous pouvez constater que plusieurs files sur votre groupe de files amélioreront les performances.

Examinez ma consortingbution à cette question: Pourquoi l'utilisation de l'UC est-elle asymésortingque sur notre boîte de server SQL 8-cpu?

Nous prenons soin de configurer nos plus grandes tables les plus souvent utilisées dans les groupes de files avec plusieurs files. L'une des améliorations de performance de ceci est que SQL va filer des requêtes à chaque file dans le groupe de files – donc si BigOverUsedTable est sur FileGroup1 et FileGroup1 comporte quatre files et votre DB possède 8 kernelx, il utilisera quatre kernelx pour faire "select grand nombre de requêtes méchantes de BigOverUsedTable "- alors que sinon, il n'utilisera qu'une CPU. Nous avons eu cette idée de cet article MSDN:

http://msdn.microsoft.com/en-us/library/ms944351.aspx

De TFA:

"Les groupes de files utilisent des threads parallèles pour améliorer l'access aux données. Lorsqu'une table est accessible séquentiellement, le système crée un thread distinct pour chaque file en parallèle. Lorsque le système effectue une parsing de table pour une table dans un groupe de files avec quatre files, il utilise quatre séparés pour lire datatables en parallèle. En général, l'utilisation de plusieurs files sur des disques distincts améliore les performances. Trop de files dans un groupe de files peuvent provoquer de nombreux threads parallèles et créer des goulets d'étranglement.

Nous avons quatre files dans notre groupe de files sur une machine 8 core grâce à ce conseil. Cela fonctionne bien.

Les seuls avantages que vous obtiendriez seraient que le operating system disposerait de deux files d'attente physiques dans Windows au lieu d'une, et que vous serez prêt à append un autre tableau et à déplacer un file de database à l'avenir. Les deux sont des avantages mineurs.

Si vous avez le time, vous pouvez toujours l'essayer et voir au lieu de deviner!

Je ne vois aucun gain de performance perçu avec 2 disques virtuels sur un disque virtuel, mais avoir des files et des groupes de files supplémentaires est toujours bon pour les épreuves futures.

Avoir vos index dans un groupe de files distinct est une bonne pratique, alors vous pouvez toujours déplacer le groupe de files vers un nouveau jeu de broches pour une augmentation de performance supplémentaire!

Il n'y aura pas d'avantage de vitesse mesurable, mais, comme l'ont souligné d'autres, avoir deux groupes de files est un concept plus futur.

Vos deux options ne fournissent tout simplement aucun avantage, car les E / S seront simplement dispersés autour de tous les disques physiques dans les deux configurations.

Si vous disposez de 4 disques physiques et que vous voulez vraiment get les performances possibles possibles (*), voici comment procéder:

  • Créez 2 arrays RAID 1, chacun utilisant 2 disques.
  • Créez un seul volume sur chaque tableau.
  • Créez un groupe de files sur chaque volume.
  • Optimisez votre database pour un parallélisme maximal.

Le dernier point est le plus important; Avec cette configuration, vous pouvez avoir les deux groupes de files en train de fonctionner en parallèle, mais cela ne sert qu'à vous permettre de placer vos données là-bas d'une manière qui permet d'effectuer des E / S sur les deux en même time; afin que vous puissiez mettre différentes tables sur différents groupes de files, ou utiliser l'une d'entre elles pour les tables et l'autre pour les index, ou … vous avez des solutions sans fin, tout dépend de votre charge de travail réelle.

(*) Il s'agit vraiment d'une optimization avancée, dans la plupart des cas, il s'agit d'une overkill, car un seul groupe de files / single volume / single array sera beaucoup plus simple à gérer et atteindra des performances très similaires, à less que vous ne pouvez paralléler vos E / S .

L'option 2 entraînera vraisemblablement un mouvement plus physique des têtes de lecteur car ils doivent aller et venir entre les deux disques logiques. Cela peut ou non compenser les avantages obtenus par les files d'attente de disques séparées. Seuls les tests utilisant votre environnement pourraient donner des résultats concluants.