Leistungsprobleme mit SQL Server 2012 Enterprise Edition unter CAL-Lizenzierung

In SQL Server 2012 wurden zahlreiche Lizenzierungsänderungen eingeführt; Die bedeutendste war die Umstellung von Socket-basierter Lizenzierung auf Core-basierte Lizenzierung für die Enterprise Edition. Eine der Herausforderungen, denen sich Microsoft bei dieser Änderung gegenübersah, war die Bereitstellung eines Migrationspfads für Kunden, die zuvor eine auf Server+CAL basierende Lizenzierung für Enterprise Edition vor SQL Server 2012 verwendet haben. Kunden mit Software Assurance können auf SQL Server 2012 Enterprise Edition upgraden und weiterhin Server verwenden +CAL-Lizenzierung (auch als „Grandfathering“ bezeichnet), jedoch mit einer Beschränkung auf 20 logische Prozessoren, wie im SQL Server 2012-Lizenzierungshandbuch dokumentiert. Diese Lizenzierung erstreckt sich auch auf VMs mit einem Limit von 4 VMs, die von der Enterprise Server+CAL-Lizenz abgedeckt werden, aber immer noch mit der gleichen Beschränkung auf 20 logische Prozessoren, wie im SQL Server 2012 Virtualization Licensing Guide dokumentiert.

Viele Leute wurden von der Beschränkung auf 20 logische Prozessoren überrascht, obwohl sie in den Lizenzhandbüchern dokumentiert ist.

Beim Starten der Instanz wird ein Eintrag in die ERRORLOG-Datei vorgenommen, der die Anzahl der logischen Prozessoren angibt und dass die Begrenzung auf 20 Prozessoren erzwungen wird:

Bei der Standardkonfiguration, die SQL Server unter der Beschränkung auf 20 logische Prozessoren mit Server+CAL anwendet, sind die ersten 20 Planer ONLINE SICHTBAR und alle verbleibenden Planer sind OFFLINE SICHTBAR. Infolgedessen können aufgrund von Ungleichgewichten im NUMA-Knotenplaner Leistungsprobleme für die Instanz auftreten. Um dies zu demonstrieren, habe ich auf unserem Dell R720-Testserver eine VM erstellt, die über zwei Sockets und installierte Intel Xeon E5-2670-Prozessoren mit jeweils 8 Kernen und aktiviertem Hyperthreading verfügt, was insgesamt 32 logische Prozessoren bereitstellt, die unter Windows Server 2012 Datacenter Edition verfügbar sind. Die VM wurde mit 32 virtuellen CPUs konfiguriert, wobei 16 virtuelle Prozessoren in zwei vNUMA-Knoten zugewiesen wurden.

Abbildung 1 – vNUMA-Einstellungen

In SQL Server unter dem Enterprise Server+CAL-Lizenzmodell führt dies zu einer Scheduler-Konfiguration, die der folgenden ähnelt:

SELECT 
  parent_node_id,
  [status], 
  scheduler_id, 
  [cpu_id], 
  is_idle, 
  current_tasks_count, 
  runnable_tasks_count, 
  active_workers_count, 
  load_factor
FROM sys.dm_os_schedulers;

Abbildung 2 – Scheduler-Zuweisung unter Enterprise Server+CAL

Wie Sie sehen können, werden alle 16 logischen Prozessoren im ersten NUMA-Knoten und nur vier der logischen Prozessoren im zweiten NUMA-Knoten von der Instanz verwendet. Dies führt zu einem erheblichen Ungleichgewicht der Scheduler zwischen den beiden NUMA-Knoten, was unter Last zu erheblichen Leistungsproblemen führen kann. Um dies zu demonstrieren, habe ich 300 Verbindungen aufgebaut, auf denen die AdventureWorks Books Online-Workload für die Instanz ausgeführt wird, und dann die Planerinformationen für die VISIBLE ONLINE-Scheduler in der Instanz mit der folgenden Abfrage erfasst:

SELECT 
  parent_node_id,
  scheduler_id, 
  [cpu_id], 
  is_idle, 
  current_tasks_count, 
  runnable_tasks_count, 
  active_workers_count, 
  load_factor
FROM sys.dm_os_schedulers
WHERE [status] = N'VISIBLE ONLINE';

Eine Beispielausgabe dieser Abfrage unter Last ist in Abbildung 3 unten dargestellt.

Abbildung 3 – Scheduler unter Last mit Enterprise Server+CAL

Sie können dieses Symptom auch visuell in Überwachungstools wie SQL Sentry Performance Advisor sehen:

Abbildung 4 – NUMA-Ungleichgewicht wie in SQL Sentry Performance Advisor gezeigt

Diese Informationen zeigen ein erhebliches Ungleichgewicht und die Leistung wird dadurch beeinträchtigt. Dies zeigt sich deutlich in der Anzahl der ausführbaren Tasks für die vier Scheduler im zweiten NUMA-Knoten, die drei- bis viermal so groß sind wie die für die Scheduler im ersten NUMA-Knoten. Was genau ist das Problem und warum tritt es auf?

Auf den ersten Blick könnte man denken, dass dies ein Fehler in SQL Server ist, aber das ist es nicht. Dies ist etwas, das konstruktionsbedingt auftritt, obwohl ich bezweifle, dass dieses Szenario erwartet wurde, als die Beschränkung auf 20 logische Prozessoren ursprünglich implementiert wurde. Auf NUMA-basierten Systemen werden neue Verbindungen den NUMA-Knoten im Round-Robin-Verfahren zugewiesen, und dann wird die Verbindung innerhalb des NUMA-Knotens basierend auf der Auslastung einem Planer zugewiesen. Wenn wir die Art und Weise ändern, wie wir diese Daten betrachten, und die Daten basierend auf parent_node_id aggregieren, sehen wir, dass die Aufgaben tatsächlich über die NUMA-Knoten verteilt werden. Dazu verwenden wir die folgende Abfrage, deren Ausgabe in Abbildung 5 zu sehen ist.

SELECT 
  parent_node_id, 
  SUM(current_tasks_count) AS current_tasks_count, 
  SUM(runnable_tasks_count) AS runnable_tasks_count, 
  SUM(active_workers_count) AS active_workers_count, 
  AVG(load_factor) AS avg_load_factor
FROM sys.dm_os_schedulers
WHERE [status] = N'VISIBLE ONLINE'
GROUP BY parent_node_id;

Abbildung 5 – Round-Robin-Saldo für NUMA-Knoten

Dieses Verhalten ist in der Onlinedokumentation für SQL Server (http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx) dokumentiert. Da ich weiß, was ich über SQLOS, SQL Server und Hardware weiß, macht das Sinn. Vor der Beschränkung auf 20 logische Prozessoren in SQL Server 2012 Enterprise Edition mit Server+CAL-Lizenzierung war es ein seltenes Szenario, dass SQL Server ein Scheduler-Ungleichgewicht zwischen NUMA-Knoten in einem Produktionsserver aufwies. Eines der Probleme in diesem speziellen Fall ist die Art und Weise, wie die virtuelle NUMA an die VM weitergegeben wurde. Das Durchführen der exakt gleichen Installation auf der physischen Hardware ermöglicht, dass alle Scheduler ONLINE SICHTBAR sind, da die zusätzlichen logischen Prozessoren, die von den Hyperthreads präsentiert werden, durch SQL unterscheidbar und frei sind.

Mit anderen Worten, das Limit von 20 logischen Prozessoren führt tatsächlich zu 40 Planern ONLINE, wenn (a) es sich nicht um eine virtuelle Maschine handelt, (b) die Prozessoren von Intel sind und (c) Hyper-Threading aktiviert ist. stark>

Wir sehen also diese Nachricht im Fehlerprotokoll:

Und dieselbe Abfrage wie oben führt dazu, dass alle 32 Prozessoren ONLINE SICHTBAR sind:

SELECT 
  parent_node_id,
  [status], 
  scheduler_id, 
  [cpu_id], 
  is_idle, 
  current_tasks_count, 
  runnable_tasks_count, 
  active_workers_count, 
  load_factor
FROM sys.dm_os_schedulers
WHERE [status] = N'VISIBLE ONLINE';

Abbildung 6 – Dieselbe Konfiguration auf physischer Hardware

Da es in diesem Fall nur 32 logische Prozessoren gibt, wirkt sich die Beschränkung auf 20 (naja, 40) Kerne überhaupt nicht aus, und die Arbeit wird gleichmäßig auf alle Kerne verteilt.

In Szenarien, in denen die Beschränkung auf 20 Prozessoren die NUMA-Balance der Scheduler beeinflusst, ist es möglich, die Serverkonfiguration manuell zu ändern, um die Anzahl der VISIBLE ONLINE-Scheduler in jedem der NUMA-Knoten durch die Verwendung von ALTER SERVER CONFIGURATION auszugleichen . Im bereitgestellten VM-Beispiel konfiguriert der folgende Befehl die ersten 10 logischen Prozessoren in jedem NUMA-Knoten für VISIBLE ONLINE.

ALTER SERVER CONFIGURATION
SET PROCESS AFFINITY CPU = 0 TO 9, 16 TO 25;

Mit dieser neuen Konfiguration, bei der dieselbe Arbeitslast von 300 Sitzungen und die Arbeitslast von AdventureWorks Books Online ausgeführt wird, können wir sehen, dass das Lastungleichgewicht nicht mehr auftritt.

Abbildung 7 – Balance wiederhergestellt mit manueller Konfiguration

Und wieder mit SQL Sentry Performance Advisor können wir sehen, dass die CPU-Last gleichmäßiger auf beide NUMA-Knoten verteilt ist:

Abbildung 8 – NUMA-Saldo wie in SQL Sentry Performance Advisor gezeigt

Dieses Problem ist nicht streng auf VMs und die Art und Weise beschränkt, wie virtuelle CPUs dem Betriebssystem präsentiert werden. Es ist auch möglich, dass dieses Problem mit physischer Hardware auftritt. Beispielsweise ein älterer Dell R910 mit vier Sockeln und acht Kernen pro Sockel oder sogar ein AMD Opteron 6200 Interlagos-basierter Server mit zwei Sockeln und 16 Kernen pro Sockel, der sich als vier NUMA-Knoten mit jeweils acht Kernen präsentiert. Bei jeder dieser Konfigurationen kann das Prozessungleichgewicht auch dazu führen, dass einer der NUMA-Knoten vollständig offline geschaltet wird. Folglich können auch andere Nebeneffekte wie Speicher von diesem Knoten, der auf die Online-Knoten verteilt wird, was zu Problemen beim Zugriff auf fremden Speicher führt, die Leistung beeinträchtigen.

Zusammenfassung

Die Standardkonfiguration von SQL Server 2012 mit der Enterprise Edition-Lizenzierung für Server+CAL ist nicht ideal für alle NUMA-Konfigurationen, die möglicherweise für SQL Server vorhanden sind. Immer wenn die Enterprise Server+CAL-Lizenzierung verwendet wird, müssen die NUMA-Konfiguration und der Scheduler-Status pro NUMA-Knoten überprüft werden, um sicherzustellen, dass SQL Server für optimale Leistung konfiguriert ist. Dieses Problem tritt bei Core-basierter Lizenzierung nicht auf, da alle Scheduler lizenziert und ONLINE SICHTBAR sind.