Mehr Kerne, schnellere Kerne oder eine bessere Abfrage?

Kurz gesagt

Ob viele oder schnelle Kerne besser sind, entscheidet Ihre Last, nicht das Datenblatt. Eine einzelne Abfrage, die seriell läuft, wird nur durch einen schnelleren Kern schneller. Mehr Kerne helfen parallelen Abfragen und vielen gleichzeitigen Sitzungen, aber nicht unbegrenzt und nicht linear.

Bevor Sie über Kerne entscheiden, lohnt die Frage, wofür die CPU heute arbeitet. In unserem Labor verbrauchten 5 Prozent der Aufrufe 84 Prozent der CPU. Die doppelte Kernzahl brachte 43 Prozent mehr Durchsatz, die verbesserte Abfrage auf der alten Hardware das 3,6-Fache.

Ein echter CPU-Engpass zeigt sich nicht an einer einzelnen Zahl. Lange Antwortzeiten allein beweisen ihn nicht, und auch der Anteil der Signal-Wartezeit allein nicht. Erst mehrere Kennzahlen zusammen ergeben ein belastbares Bild.

Das Bild: die Kasse im Supermarkt

Stellen Sie sich die CPU als Kassenbereich vor. Jeder Kern ist eine Kasse, jede Abfrage ein Einkauf.

• Ein schnellerer Kassierer verkürzt jeden einzelnen Einkauf. Das ist ein schnellerer Kern.
• Mehr Kassen verkürzen die Schlange, aber nicht den einzelnen Einkauf. Das sind mehr Kerne für viele gleichzeitige Abfragen.
• Ein großer Einkauf, auf mehrere Kassen verteilt, ist schneller fertig. Das Verteilen und Zusammenführen kostet aber zusätzliche Arbeit. Das ist eine parallele Abfrage.
• Ein überladener Wagen blockiert eine Kasse lange, egal wie viele es gibt. Das ist die ineffiziente Abfrage, die den größten Teil der CPU verbraucht.

Mit diesem Bild lassen sich die drei Versuche lesen.

Im Bild: schnellerer Kassierer, verteilter Einkauf

Versuch 1: eine Abfrage, mehr Kerne

Im Bild: mehr Kassen

Versuch 2: viele Sitzungen, mehr Kerne

Dass 12 Kerne kaum mehr brachten als 8, ist ein Befund dieses Laborhosts. Unsere Kerne sind virtuelle CPUs unter Hyper-V. Mehr virtuelle CPUs bedeuten nicht automatisch mehr physische Rechenleistung, etwa wenn sie sich Hyperthreads, Takt oder Cache des Hosts teilen. Die genaue Ursache haben wir nicht isoliert.

Im Bild: mehr Kassen oder überladener Wagen

Versuch 3: mehr Kerne oder bessere Abfrage?

Woran Sie einen echten CPU-Engpass erkennen

Im Labor haben wir eine Last schrittweise von 1 auf 32 gleichzeitige Sitzungen erhöht, auf 4 Kernen. Ab 16 Sitzungen war die CPU bei 99 Prozent, der Durchsatz blieb bei 922 Abfragen je Sekunde stehen, und die Antwortzeiten wuchsen mit jeder weiteren Sitzung. Zum Vergleich ein ganz anderer Fall: Abfragen, die auf eine Sperre warteten, brauchten 2 Sekunden, bei 0,6 Prozent CPU-Auslastung. Mehr Kerne hätten dort nichts geändert.

Daraus ergeben sich fünf Kennzahlen, die Sie zusammen betrachten:

Zwei Fallen. Der Anteil der Signal-Wartezeit an der gesamten Wartezeit taugt allein nicht als Maß. Bei reiner Rechenarbeit gibt es kaum andere Wartezeiten; der Anteil lag in unserem Labor schon bei 26 Prozent CPU-Auslastung bei fast 100 Prozent. Und eine Durchschnittsauslastung unter 100 Prozent schließt eine Warteschlange nicht aus: Mit wenigen dauerhaft aktiven Verbindungen liefen in unserem Labor zeitweise zwei Abfragen auf demselben Scheduler, während drei andere leer blieben. Deshalb lohnt der Blick je Scheduler.

Die folgenden Abfragen lesen die Werte nur aus; wir haben sie auf SQL Server 2017 bis 2025 geprüft. Starten Sie sie, während das Problem auftritt. Die zweite filtert harmloses Hintergrundwarten heraus, sonst zeigt sie schon auf einem untätigen Server hohe Werte. Weil viele Aufgaben gleichzeitig warten, kann die Signal-Wartezeit je Sekunde größer als 1.000 Millisekunden sein. Zur Einordnung die Werte je Sekunde und Kern aus unserem Labor: etwa 0,3 ms bei einer einzelnen Sitzung, rund 440 ms bei 75 Prozent Auslastung, rund 1.080 ms bei voller Sättigung. Die dritte liest den Plan Cache; auf sehr großen Systemen kann sie einige Sekunden dauern. Die Werte im Plan Cache beginnen mit dem letzten Neustart oder dem Zeitpunkt, an dem ein Plan in den Cache kam.

Nur lesend – ändert nichts an Ihrer Datenbank

-- Nur lesend: Warteschlange je Scheduler (Momentaufnahme)
SELECT scheduler_id, cpu_id,
       current_tasks_count, runnable_tasks_count, active_workers_count
FROM sys.dm_os_schedulers
WHERE status = N'VISIBLE ONLINE'
ORDER BY scheduler_id
OPTION (MAXDOP 1);

-- Nur lesend: Signal-Wartezeit je Sekunde und Kern über 10 Sekunden,
-- ohne harmloses Hintergrundwarten (dieselbe Liste wie im Ratgeber, nicht vollständig)
IF OBJECT_ID('tempdb..#vorher') IS NOT NULL DROP TABLE #vorher;
SELECT wait_type, signal_wait_time_ms
INTO #vorher
FROM sys.dm_os_wait_stats
OPTION (MAXDOP 1);

WAITFOR DELAY '00:00:10';

DECLARE @kerne int = (SELECT COUNT(*) FROM sys.dm_os_schedulers
                      WHERE status = N'VISIBLE ONLINE');
SELECT kerne = @kerne,
       signal_ms_je_sekunde = SUM(n.signal_wait_time_ms - v.signal_wait_time_ms) / 10.0,
       signal_ms_je_sekunde_und_kern = SUM(n.signal_wait_time_ms - v.signal_wait_time_ms) / 10.0 / @kerne
FROM sys.dm_os_wait_stats AS n
JOIN #vorher AS v ON v.wait_type = n.wait_type
WHERE n.wait_type NOT LIKE N'SLEEP[_]%'
  AND n.wait_type NOT LIKE N'BROKER[_]%'
  AND n.wait_type NOT LIKE N'XE[_]%'
  AND n.wait_type NOT LIKE N'QDS[_]%'
  AND n.wait_type NOT LIKE N'HADR[_]%'
  AND n.wait_type NOT LIKE N'PARALLEL[_]REDO[_]%'
  AND n.wait_type NOT IN (
      N'AZURE_IMDS_VERSIONS', N'CHECKPOINT_QUEUE', N'CHKPT', N'CLR_AUTO_EVENT', N'CLR_MANUAL_EVENT',
      N'CLR_SEMAPHORE', N'DBMIRROR_DBM_EVENT', N'DBMIRROR_EVENTS_QUEUE',
      N'DBMIRROR_WORKER_QUEUE', N'DBMIRRORING_CMD', N'DIRTY_PAGE_POLL',
      N'DISPATCHER_QUEUE_SEMAPHORE', N'EXECSYNC', N'FSAGENT',
      N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'FT_IFTSHC_MUTEX', N'KSOURCE_WAKEUP',
      N'LAZYWRITER_SLEEP', N'LOGMGR_QUEUE', N'MEMORY_ALLOCATION_EXT',
      N'ONDEMAND_TASK_QUEUE', N'PREEMPTIVE_OS_FLUSHFILEBUFFERS',
      N'PREEMPTIVE_XE_GETTARGETSTATE', N'PVS_PREALLOCATE',
      N'PWAIT_ALL_COMPONENTS_INITIALIZED', N'PWAIT_DIRECTLOGCONSUMER_GETNEXT',
      N'PWAIT_EXTENSIBILITY_CLEANUP_TASK', N'REDO_THREAD_PENDING_WORK',
      N'REQUEST_FOR_DEADLOCK_SEARCH', N'RESERVED_MEMORY_ALLOCATION_EXT', N'RESOURCE_QUEUE', N'SERVER_IDLE_CHECK',
      N'SNI_HTTP_ACCEPT', N'SOS_WORK_DISPATCHER', N'SP_SERVER_DIAGNOSTICS_SLEEP',
      N'SQLTRACE_BUFFER_FLUSH', N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
      N'SQLTRACE_WAIT_ENTRIES', N'VDI_CLIENT_OTHER', N'WAIT_FOR_RESULTS',
      N'WAITFOR', N'WAITFOR_TASKSHUTDOWN', N'WAIT_XTP_CKPT_CLOSE',
      N'WAIT_XTP_HOST_WAIT', N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG', N'WAIT_XTP_RECOVERY')
OPTION (MAXDOP 1);

-- Nur lesend: die zehn Abfragen mit der meisten CPU-Zeit seit Planerstellung
SELECT TOP (10)
       cpu_ms_gesamt = qs.total_worker_time / 1000,
       ausfuehrungen = qs.execution_count,
       cpu_ms_je_ausfuehrung = qs.total_worker_time / 1000.0 / qs.execution_count,
       anteil_cpu_prozent = 100.0 * qs.total_worker_time
                            / SUM(qs.total_worker_time) OVER (),
       abfrage = SUBSTRING(st.text, qs.statement_start_offset / 2 + 1, 200)
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY qs.total_worker_time DESC
OPTION (MAXDOP 1);

Den Weg vom Symptom zur Ursache bei hoher CPU-Last beschreibt der Ratgeber SQL Server unter Last langsam.

Viele oder schnelle Kerne?

Aus den Versuchen ergibt sich eine Zuordnung nach Lastprofil. Sie ersetzt keine Messung Ihrer Last, zeigt aber, wonach Sie suchen.

Drei Dinge, die die Entscheidung mitbestimmen

• Lizenzen. SQL Server wird in der Regel je Kern lizenziert. Jeder zusätzliche Kern kostet also nicht nur Hardware. Die Standard Edition nutzt außerdem nur eine begrenzte Zahl von Kernen, mehr dazu im Abschnitt zur Edition in der Upgrade-Entscheidungshilfe. Lizenzfragen bestätigt Ihnen Ihr Lizenzpartner. Wir verkaufen keine Lizenzen und beraten deshalb ohne Umsatzinteresse.
• Virtualisierung. Eine virtuelle CPU ist kein physischer Kern. Ob zusätzliche virtuelle CPUs Rechenleistung bringen, hängt davon ab, was der Host darunter bereitstellt. Unser Labor zeigt, dass der Zugewinn ab einem Punkt klein werden kann.
• Die Last von morgen. Eine Abfrage, die heute seriell läuft, kann nach einer Änderung parallel laufen und umgekehrt. Kerne sind eine Entscheidung für Jahre, Abfragen ändern sich mit jedem Release.

Häufige Fragen

Methode und Grenzen

Alle Messwerte stammen aus unserer Laborreihe vom 23.10.2026: SQL Server 2022 CU27 Developer in einem Linux-Container, virtuelle CPUs unter Hyper-V auf einem Intel Xeon mit 2,4 GHz, alle zugewiesenen CPUs in einem NUMA-Knoten, 6 GiB maximaler SQL-Speicher. Synthetische Daten mit 10 Millionen Zeilen im Arbeitsspeicher, gleiche Statistiken. Jede Variante lief nach einer Aufwärmphase in fünf Messfenstern; angegeben sind Mediane. Varianten, deren Fenster mehr als zehn Prozent voneinander abwichen, haben wir mit längeren Fenstern wiederholt. Der Lastgenerator lief auf getrennten CPUs und war nie der Engpass.

Das ist ein Labor, kein Kundenbetrieb. Die Taktfrequenz haben wir nicht verändert; Aussagen über schnellere Kerne sind Schlussfolgerungen aus der seriellen Messung. Die Kurve über 8 Kerne hinaus gilt für diesen Host. Zwei Varianten mit wenigen dauerhaft aktiven Sitzungen streuten stark, weil Abfragen ungleich auf die Scheduler verteilt waren; sie sind nur als Hinweis verwendet. Für die Variante mit 8 Kernen in Versuch 3 lagen die Mediane zweier Messreihen eng beieinander, die Streuung innerhalb einer Reihe aber über zehn Prozent.

Weiterlesen