Pourquoi une application gourmande en disque s'exécuterait-elle plus rapidement sur un SAN que sur un disque physique?

21

Pourquoi une application gourmande en disque s'exécuterait-elle plus rapidement sur un SAN que sur un disque physique? Je m'attendais à ce que le disque physique soit légèrement plus rapide, mais en fait, le processus s'est déroulé 100 fois plus rapidement lorsque son disque de travail a été défini sur une partition sur le SAN.

Notre supposition est que le SAN est optimisé pour être rapide alors que les paramètres de réglage du disque physique sont liés au système d'exploitation (Solaris) et n'ont pas été touchés ou le système d'exploitation corrigé.

Pendant l'activité la plus élevée, les E / S disque s'exécutaient à 100% et le temps nécessaire pour terminer une écriture était supérieur à 2 secondes car plusieurs processus écrivaient sur le disque en même temps.

(Pour info, l'application impliquée était Informatica PowerCenter)

performance storage-area-network hard-drive tuning Stuart Woodward
la source

Réponses:

23

Je ne suis pas du tout surpris. Les baies SAN comportent généralement BEAUCOUP de disques. Le facteur limitant pour les E / S disque est la vitesse du disque individuel, et ces piles. 6 disques localement dans un RAID10 fonctionneront mieux que 2, et 80 disques sur un SAN fonctionneront mieux que 10 disques localement. Il y a bien sûr des variables, mais c'est ainsi que cela est censé fonctionner.

De plus, si le SAN a des SSD impliqués, les choses deviennent vraiment instables.

sysadmin1138
la source
15

C'est presque certainement dû à la mise en cache. Le DAS probable a une mise en cache minimale, où la plupart des SAN d'entreprise ont plusieurs gigaoctets de cache. Je suppose que l'application sature le cache du DAS, mais pas celui du SAN.

Chris S
la source
1
La latence évidente sur le SAN va plus longtemps que le DAS mais le débit global est plus élevé sur le SAN avec toute sa mise en cache. Bonne réponse.
Matt
et puis il y a souvent un cache de lecture anticipée, donc ses lectures / écritures aléatoires qui prennent le plus grand coup et ensuite vous pouvez mettre en cache les écritures de sorte que ses seules lectures aléatoires qui soient impactées, toujours un assez petit retard cependant.
Silverfire
1
Un sous-système de stockage correctement configuré sur le SAN qui n'est pas surchargé devrait vous donner des temps d'écriture aléatoires d'environ 1 à 2 ms.
MikeyB
@MikeyB, je ne suis pas en désaccord avec vous. Une écriture de 1 à 2 ms sur le SAN semble correcte. Mais la configuration SAN de Charles était 100 fois plus rapide que ses disques physiques surchargés (les écritures étaient> 2 secondes pour ce dernier). Donc, même ses performances SAN ne sont pas si bonnes, à 20 ms plutôt qu'à 1-2 ms ...?
Ellie Kesselman
9

Sur le plan conceptuel, il semble toujours que le service de disque à partir du SAN soit plus lent que le service local. Cependant, de nombreux facteurs peuvent inverser la tendance et faire du SAN une option beaucoup plus rapide. Certains de ces facteurs sont:

  • Votre charge de travail nécessite-t-elle un temps de recherche rapide ou un débit rapide, ou les deux?
  • Combien de broches sur le SAN LUN par rapport au disque local?
  • Quelle vitesse de bus entre le SAN LUN et le serveur, par rapport à l'interface du disque local?
  • Quelle quantité de cache en lecture / écriture est disponible sur le SAN LUN par rapport au disque local?
  • À quelle vitesse les disques tournent-ils sur le SAN LUN par rapport au disque local?
  • Quelle autre activité d'E / S se déroule sur le SAN LUN par rapport au disque local?
  • Quels sont les niveaux RAID des baies sur le SAN et le stockage local?

Tous ces éléments affecteront vos performances sur le SAN et le disque local.

Chris Thorpe
la source
1

Tout dépend du nombre de broches disponibles ... Plus le nombre de broches est élevé, plus il est rapide d'accéder à une donnée donnée. si vous êtes intensif en E / S, en particulier si vous êtes une application de base de données, vous pouvez facilement enterrer les performances du disque local avec une solution SAN qui peut avoir un nombre beaucoup plus élevé d'ensembles de disques pour la gestion des données de base, des index et autres.

Avec le sous-système de disque local, vous partagez également probablement l'accès aux têtes de lecture / écriture avec d'autres opérations, telles que r / w pour permuter, l'accès au système d'exploitation local et aux fichiers de bibliothèque, l'accès aux applications, etc ... Bien que individuellement rapide, le temps collectif Pour toutes les actions de lecture / écriture, déplacer les têtes de lecture / écriture d'une zone du disque pour couvrir un ensemble d'actions à une autre afin de satisfaire les exigences de votre application peut certainement battre les performances.

James Pulley
la source