Sehr ungleichmäßige CPU-Auslastung mit SQL Server 2012 auf einem 2-Prozessor-Computer mit 16 Kernen / Prozessor


8

Nach der Installation von SQL Server Enterprise 2012 mit dem Server + Cal-Lizenzmodell waren auf einem Computer mit 2 Prozessoren mit jeweils 16 Kernen (und ohne Hyperthreading) und einer extrem hohen Belastung des Servers die 16 Kerne des ersten Prozessors sehr wenig ausgelastet Die ersten 4 Kerne auf der 2. CPU waren stark ausgelastet, und die letzten 12 Kerne wurden überhaupt nicht verwendet (aufgrund des 20-Kern-Limits für diese SQL Server-Version). Die gesamte CPU-Auslastung lag bei rund 25%. Leider litt der Server unter einer extrem schlechten Leistung, obwohl die Aufgaben bei gleichmäßiger Verteilung auf die 20 Kerne nicht annähernd so schlecht gewesen wären.

Der Windows Server wurde auf einem virtuellen VMWare-Image unter ESX Server ausgeführt, aber die gesamte CPU wurde dem Windows Server zugewiesen.

Wir haben versucht, die Affinitätseinstellungen zu ändern (z. B. die meisten Kerne der CPU und die anderen der E / A zuzuweisen), aber das hat nicht zur Lösung der Leistungsprobleme beigetragen.

Durch das Upgrade der Produktversion auf SQL Server Enterprise Core 2012 konnte SQL Server nicht nur die 12 zuvor nicht verwendeten Kerne auf dem 2. Prozessor verwenden, sondern auch die Aufgaben auf alle Prozessoren verteilen. Um den Rückstand an Anfragen zu überwinden, stieg die CPU-Auslastung auf rund 90% und ging nach dem Aufholen auf rund 33% zurück. Die Leistung verbesserte sich jedoch dramatisch, da wir auf die neu aktualisierte Version umgestiegen sind. Die Leistungsprobleme verschwanden.

Ich habe mich gefragt, ob jemand weiß, was dazu führen kann, dass SQL Server die Last ungleichmäßig verteilt, wobei er sich fast ausschließlich auf die ersten 4 Kerne des 2. Prozessors mit 12 im Leerlauf befindlichen Kernen stützt und jedem der 16 Kerne des ersten nur wenige Aufgaben zuweist Prozessor. Gibt es auch eine Möglichkeit, die Last gleichmäßiger auf die 20 Kerne zu verteilen, die ohne das Upgrade der Product Edition verwendet wurden?

Die Kehrseite dieser Frage ist, was das Produkt-Upgrade bewirkt hat, das dazu geführt hat, dass SQL Server die Last gleichmäßig auf alle erkannten Kerne verteilt hat.

Vielen Dank für die Beantwortung dieser Fragen und / oder Links, die mir helfen könnten, besser zu verstehen, wie ich das Geschehen verstehen kann.


Wollen Sie damit sagen, dass es sich bei dem fraglichen Computer um eine VM mit 32 vCPUs handelt? In beiden Szenarien?
Mfinni

Ja, es war dieselbe Maschine mit 2 Prozessoren mit jeweils 16 Kernen (und es war kein Hyperthreading beteiligt).
Cooplarsh

1
Warum hast du im Namen des Herrn 32 vCPUs? Haben Sie versucht, das zu reduzieren? Ich weiß, dass ESXi die Gang-Planung von CPUs verbessert hat, aber Sie fragen nur nach Problemen mit so vielen. Auf welcher ESXi-Version befinden Sie sich und welche Hardware liegt Ihnen zugrunde?
Mfinni

Antworten:


4

Die ungleichmäßige Leistung war wahrscheinlich eine Kombination aus dem 20-Core-Limit und der Art und Weise, wie SQL Server Threads auf NUMA-Computern plant. Leider verwendet SQL Server 2012 keine Intelligenz, um zu entscheiden, welche 20 Kerne verwendet werden sollen, was zu einer unausgeglichenen Anzahl von Kernen pro NUMA-Knoten führt. Mit 32 Kernen, die auf 2 NUMA-Knoten verteilt sind, werden Sie wahrscheinlich einen 16/4-Split erhalten. Dies ist problematisch, da SQL versucht, die Aktivität auf NUMA-Knoten im Round-Robin-Verfahren gleichmäßig zu verteilen (vorausgesetzt, Sie erzwingen keine Affinität mit Resource Governor).

In Ihrem Fall ist 1/2 der Last 4 Kernen und 1/2 bis 16 Kernen zugeordnet. Der Engpass auf dem 4-Kern-Knoten wirkt effektiv als Drossel und begrenzt die Kapazität der Maschine auf 2x 4 Kerne = 8 Kerne = 25% CPU-Auslastung.

Nach dem Upgrade auf die Core Edition verwendete SQL alle 32 Kerne auf 2 Numa-Knoten (16/16 Split). Leistung verbessert usw.

Eine Option, die Ihre Leistung hätte verbessern können, wäre die Verwendung des SQL Server-Ressourcen-Governors gewesen, um den Großteil Ihrer Arbeitslast auf einen numa-Knoten zu übertragen. Sie können beispielsweise einen Ressourcenpool WEB_APP erstellen und ihn so aktivieren, dass er nur auf dem 16-Kern-Numa-Knoten ausgeführt wird. Die dem WEB_APP-Pool zugewiesene Last könnte 50% der Serverkapazität plus die verbleibenden 12,5% der Kapazität des 4-Kern-Knotens belegen.

Die andere Option wäre, die für SQL Server verfügbaren Kerne auf nur 10 von jedem numa-Knoten zu beschränken.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.