SQL Server - Tout le monde utilise SUMA, l'indicateur de trace 8048 ou l'indicateur de trace 8015?

Indicateur de trace 8048 de démarrage de SQL Server récemment inclus pour résoudre un grave problème de contention de verrou tournant dans un système SQL Server 2008 R2.

Intéressé à entendre d'autres personnes qui ont trouvé des cas d'utilisation où la valeur de performance a été fournie par l'indicateur de trace 8048 (promouvoir la stratégie d'allocation de mémoire de requête du nœud par NUMA vers le noyau), l'indicateur de trace 8015 (SQL Server ignore le NUMA physique) ou SUMA ( accès mémoire suffisamment uniforme entrelacé, une option BIOS sur certaines machines NUMA).

Indicateur de trace 8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -presented-per-numa-node-may-need-trace-flag-8048.aspx

Indicateur de trace 8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

Des détails sanglants sur la charge de travail du système, des métriques collectées du système en difficulté et des métriques du système après l'intervention suivent.

L'indicateur de trace 8048 était un «correctif», mais était-ce le meilleur correctif? Est-ce que SQL Server ignorant NUMA physique en raison de l'indicateur de trace 8015 aurait accompli la même chose? Qu'en est-il de la configuration du BIOS pour entrelacer la mémoire, laissant au serveur un comportement SUMA imitant SMP au lieu d'un comportement NUMA?

Paix! tw: @sql_handle

À propos du système: - 4 cœurs hexagonaux Xeon E7540 à 2,00 GHz, hyperthreaded - 128 Go de RAM - WS2008R2 - MSSQL 2008 R2 SP2 - maxdop 6

À propos de la charge de travail: - Des milliers de rapports planifiés / mis en file d'attente générés par 2 serveurs d'applications de rapports. - 3 versions de lots: quotidiennes, hebdomadaires, mensuelles - Toutes les connexions des serveurs d'applications de rapports à SQL Server sont établies en tant que compte de service unique - Concurrence maximale des rapports = 90

Principales conclusions sur le système en difficulté: - De Perfmon, intervalles de 15 secondes - - Le système reste à 95% -100% CPU occupé - - Recherches de page de tampon SQL Server <10000 par / seconde

• À partir des DMV d'attente et de verrouillage, intervalles de 5 minutes
• • Serveurs CMEMTHREAD et temps d'attente élevés
• • SOS_SUSPEND_QUEUE tours et retards élevés

Le billet de blog d'ingénieur CSS de Bob Dorr sur l'indicateur de trace 8048 indique que les systèmes avec plus de 8 cœurs par nœud NUMA peuvent rencontrer des symptômes similaires en raison d'un goulot d'étranglement dans l'allocation de mémoire de requête. L'indicateur de trace 8048 changera la stratégie en noyau par cœur au lieu de nœud par NUMA.

L'intervention

MSSQL a été redémarré avec -T8048 en place. La différence était immédiatement évidente: le taux de consultation des pages tampons a augmenté de plus d'un million et a atteint 8 millions par seconde. La charge de travail par lots en difficulté, qui auparavant ne pouvait pas se terminer en 24 heures, s'est terminée en moins de 4 heures. Une autre charge de travail par lots qui n'a pas fait l'objet d'une enquête ou d'une intervention a été soumise dans le cadre de la validation de la valeur corrective de l'indicateur de trace 8048 (et de la garantie que ses effets secondaires indésirables étaient minimes). Ce lot de rapports précédemment terminé en 2 heures; avec l'indicateur de trace 8048 en place, le lot de rapports s'est terminé en environ 20 minutes.

ETL nocturne a également rencontré un avantage. Le temps ETL est passé d'environ 60 minutes à 40 minutes.

En rassemblant des informations de plusieurs endroits, je suppose que le haut niveau de mise en file d'attente des rapports, le nombre de rapports simultanés supérieur au nombre de threads matériels et le compte d'utilisateur unique pour tous les rapports combinés pour exercer une pression sur un nœud NUMA jusqu'à ce que la pression du thread de travail le fasse être défavorisé pour la prochaine demande de connexion entrante pour le même compte d'utilisateur, moment auquel le prochain nœud NUMA obtiendrait un certain nombre de connexions presque instantanément. Chaque nœud NUMA se retrouverait avec une forte probabilité de stresser le goulot d'étranglement de la mémoire de requête.

L'ouverture de plus de voies pour l'allocation de mémoire de requête a supprimé le goulot d'étranglement. Mais je ne suis pas sûr du coût. La publication CSS de Bob Dorr indique clairement qu'il existe une surcharge de mémoire supplémentaire avec l'indicateur de trace 8048. Cette surcharge dans la région d'allocateur à page unique est-elle régie par la mémoire maximale du serveur MSSQL 2008 R2? Si c'est le cas, je suppose que le système aura juste un certain nombre de pages de base de données en moins dans le cache du pool de mémoire tampon. Sinon, la mémoire maximale du serveur doit-elle être réduite pour s'adapter?

Ceci est un post génial.

Pour répondre à votre dernière question, je suppose que votre réponse est "oui".

Cela dit, j'aurais probablement poursuivi la numa douce avant de recourir aux indicateurs de trace. Je pense que vous avez raison sur l'allocation des nœuds numa et cela pourrait être à l'origine de votre problème. Via soft numa, vous pouvez étendre les demandes, en fonction de votre nombre de nœuds numa (4?) - à 4, si c'est le bon numéro, puis affecter, via l'adresse IP, chaque hôte à un nœud numa spécifique, en plus à cela, je désactiverais l'hyper threading. Combiné, le problème diminuerait probablement, mais il le ferait au prix de moins de programmateurs.

Sur une pensée séparée, j'examinerais le paramétrage forcé - le fait que votre charge entraîne votre CPU si haut est très intéressant et cela peut valoir la peine d'être étudié.

Enfin, sur les systèmes de nœuds multi-numa, j'ai généralement la sortie des requêtes suivantes vers une table toutes les N secondes. Fait une analyse intéressante lorsque des changements de charge de travail ou des indicateurs de trace sont implémentés:

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

et

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC