Alexis Molteni's BI Blog

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 30 avril 2009

Les processing semblent plus lents

Sur les serveurs SQL Server de plus de 4 Cpu et de 8Gb de Ram mini, il existe un problème qui affecte les temps de process des cubes. Ce problème est du à un changement de comportement entre les versions 2000 et 2005. Aujourd’hui les valeurs des propriétés <MaxThread> pour les Pool des requêtes et des process sont en dures dans le fichier de configuration de l’instance SQL Server Analysis Services (voir ci-dessous).

...
<Query>
        <MaxThreads>10</MaxThreads>
        <MinThreads>1</MinThreads>
        <PriorityRatio>2</PriorityRatio>
        <Concurrency>2</Concurrency>
        <StackSizeKB>0</StackSizeKB>
</Query>
<Process>
        <MaxThreads>64</MaxThreads>
        <MinThreads>1</MinThreads>
        <PriorityRatio>2</PriorityRatio>
        <Concurrency>2</Concurrency>
        <StackSizeKB>0</StackSizeKB>
</Process>
...

Cette configuration pose un problème quand des Thread supplémentaires sont crées au delà de la limite définie par la propriété < MaxThreads >. Ce dépassement est du à une dépendance entre job (un job est une opération interne au moteur SSAS), comme l’exécution de job enfant à un autre job, l’exécution en parallèle de plusieurs processing ou l’activité des requêtes MDX. Pour résoudre ce besoin d’exécution du à ces dépendances, le moteur autorise la création de thread au delà de la limite. Et c’est là qu’il y a un problème, car pour être certain que ce besoin supplémentaire de ressource n’est pas du à un simple pique d’activité, le moteur applique un délai de 30 secondes à la création de ces nouveaux Thread, ce qui se traduit par le ralentissement des jobs dépendants.

Dans la majeure partie des installations de SQL Server, la configuration par défaut est suffisante, car le Memory Quota Manager limite le nombre d’opérations parallèles en fonction de la quantité de mémoire disponible. Cependant, dans le cas de serveur disposant d’une grande quantité de mémoire le Memory Quota Manager va permettre la création d’un grand nombre de job en parallèles (query ou(et) process) et la limite sera très rapidement dépassée. Le délai ajouté à chaque thread crée au delà de la limite, va très rapidement s’accumuler et donner l’impression d’un ralentissement des processing.

Pour identifier cette situation il existe différent symptômes :

  1. 1 – Faible utilisation de la CPU pour le process msmdsrv.exe
  2. 2 – Faible activité disque pour le process msmdsrv.exe
  3. 3 – La somme des valeurs des compteurs :
        Threads :Processing Pool Idle Threads
        Threads :Processing Pool Busy Threads
        Threads :Processing Pool Job Queue Length

Si cette somme est supérieur à la valeur spécifiée dans la propriété <MaxThread> il y a peut etre un probleme.

Le système n’a pas besoin de combiner tous les symptômes. La combinaison des symptômes 1 et 3 ou 1 et 2 sont suffisant pour être l’expression de ce problème.

Pour l'exemple j'utilise des relevés réalisés sur l'un de mes serveurs de Prod qui a ce probleme. En utilisant les relevés faits avec la trace Perfmon qui tourne sur le serveur, j’obtiens les valeurs suivantes :

  • Threads :Processing Pool Idle Threads = 64
  • Threads :Processing Pool Busy Threads = 46
  • Threads :Processing Pool Job Queue Length = 2

Soit un total de 112. La valeur maxi étant fixée à 64 nous sommes bien au delà de cette dernière. En utilisant la méthode suivante :

1 - Récupérer la valeur de la somme des trois compteurs Perfmon (112) et ajouter 10. Soit 122

2 - Appliquer la modification dans le fichier de configuration de l’instance SSAS, le serveur va vérifier la configuration dans les 30 secondes, détecter les changements et permettre la création des threads supplémentaires.

Pour l’instant cette réponse ne concerne que les Pools de thread pour les Process, mais la même vérification doit être faite sur le Pool de Thread dédié aux requêtes car elles utilisent également le Pool de thread dédié au Process en plus de celui dédié aux requêtes.

mercredi 14 mai 2008

Sauvegarder votre requete faite dans le Browser de BIDS

Vu sur le blog de Russell Christopher, un nouvel Add-in pour le BIDS qui vous permet de concerver la requete réalisée à l'aide du browser lors du debug de votre UDM.

Plus d'infos : http://blogs.microsoft.co.il/blogs/bei/archive/2008/04/25/analysis-services-browser-views-add-in.aspx

mercredi 19 septembre 2007

MDX Studio CTP1 (v0.1 Alpha)

Vu sur le blog de Mosha Pasumansky, la mise à disposition de l'outil MDX Studio CTP, version 0.1 Alpha.

MDX Studio est un outil qui aide les utilisateurs de SQL Server Analysis Services à analyser des instructions MDX complexes, suivre les performances des requetes MDX et voir comment les instructions interagissent avec d'autres fonctionnalités de l'UDM comme les relations entre attributs. MDX Studio est compatible avec toutes les versions de SQL Server Analysis Services de 7 à 2008.

MDXStudio

lundi 17 septembre 2007

SP2 et performance.

Il semble que quelques requêtes MDX deviennent plus lentes depuis le SP2 de SSAS. Microsoft a sorti depuis 2 KB sur le sujet qui vous conseille de passer le "Cumulative update package 3 for SQL Server 2005 Service Pack 2" pour résoudre le problème....

http://support.microsoft.com/?kbid=940373

http://support.microsoft.com/?kbid=940372