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

21

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?

sql_handle
la source

Réponses:

12

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
Jeremy Lowell
la source
Merci d'avoir mentionné les sys.dm_os_nodes et sys.dm_os_waiting_tasks. J'écris un certain nombre de procédures stockées pour profiler l'activité du système, d'abord pour poursuivre une ligne de base quelque peu optimisée, puis pour surveiller les écarts. En ce moment, la capture des attentes et des tours, vient ensuite les allocations de mémoire (y compris le dop par allocation de mémoire) ... les prochains serveurs et nœuds individuels comme vous l'avez discuté ... puis peut-être
passer
1
Un autre compteur intéressant à regarder est dans perfmon: SQLServer: Buffer Node :. Les compteurs de cette famille d'intérêt sont les pages étrangères, les pages gratuites, l'espérance de vie des pages, les pages totales, les pages cibles et les pages volées. Je suppose qu'avant d'implémenter l'indicateur de trace, vous aviez une très grande quantité de pages étrangères - Avez-vous activé TF 834? Si tel est le cas, j'ai constaté qu'il n'alloue pas de mémoire à chaque nœud numa de manière équilibrée, ce qui conduit à une très grande quantité de recherches de mémoire de nœud numa distant coûteuses. Le système sur lequel j'avais ce problème contenait 1 To de RAM à l'époque.
Jeremy Lowell
bons points. J'ai regardé les métriques du nœud tampon. Le plus curieux était qu'au départ, le nœud 00 n'avait pas de pages étrangères, tandis que les autres nœuds avaient des nombres massifs. Je pense que cela est dû à notre ETL effectuant la montée en charge du tampon avec un nombre de threads suffisamment bas pour tenir entièrement sur le nœud tampon / nœud NUMA 00. Nous n'avons pas activé l'indicateur de trace 834, mais nous commencerons les tests bientôt. Nos tests de charge de travail sur Linux Oracle 11gR2 ont montré un grand avantage pour la mémoire de grandes pages, je pense que nous verrons également des gains dans Windows avec SQL Server.
sql_handle
@Mike Soft NUMA vs TF 8048. Je pense que le soft NUMA me permettrait de créer des «nœuds de mémoire» au sein des nœuds NUMA. Donc, si je créais un NUMA logiciel pour chaque cœur, il y aurait (peut-être) 24 voies pour les demandes d'allocation de mémoire de requête. Mais peut-être aussi 24 nœuds de mémoire? Je serais un peu inquiet de la surcharge de gestion de 24 nœuds de mémoire avec chaque noyau faisant des références de page `` étrangères '' à chaque fois qu'il franchit une frontière NUMA douce, et des références vraiment étrangères quand il franchit une frontière pour référencer une page qui est à la fois différente NUMA doux et NUMA dur. Je vais bricoler et voir si je peux discerner quoi que ce soit.
sql_handle