SQL_Kurs

Service Broker & CAP_CPU_PERCENT

Wenn CPU-Limits die Message-Queue lahmlegen – Risiken, Fallstricke und sichere Konfiguration

📌 Zwei mächtige Werkzeuge – doch Vorsicht bei der Kombination

Service Broker ist das eingebaute Message-Queuing-System von SQL Server für zuverlässige, asynchrone Kommunikation zwischen Datenbanken oder Instanzen. CAP_CPU_PERCENT ist eine Einstellung des Resource Governors, die einen harten CPU-Limit für einen Ressourcenpool definiert. Beide Technologien sind für sich genommen extrem nützlich. Doch wenn Sie Service Broker-Aktivitäten in einem Ressourcenpool mit CAP_CPU_PERCENT betreiben, kann dies zu unerwarteten Blockaden, erhöhten Latenzen und scheinbar mysteriösen Wartezeiten führen. Dieser Artikel beleuchtet die Hintergründe, zeigt konkrete Risiken auf und gibt Ihnen eine Schritt-für-Schritt-Anleitung für eine sichere Konfiguration.
💡 Zentrale Erkenntnis: CAP_CPU_PERCENT ist ein „harter“ CPU-Limit, das auch dann greift, wenn die CPU-Auslastung eigentlich gering ist. Genau das kann Service Broker, der auf schnelle Kontextwechsel angewiesen ist, massiv stören.

📨 Service Broker – Asynchrone Nachrichtenwarteschlange in SQL Server

Service Broker ist eine in SQL Server integrierte Message-Queuing-Technologie. Sie ermöglicht den zuverlässigen, transaktionsbasierten Austausch von Nachrichten zwischen Datenbanken innerhalb einer Instanz oder über Instanzgrenzen hinweg. Typische Anwendungsfälle sind:
  • 📬 Asynchrone Auftragsverarbeitung (z. B. Bestellungen in einer Warteschlange)
  • 🔄 Echtzeit-Datenintegration zwischen verschiedenen Datenbanken
  • ⚡ Entkopplung von Anwendungskomponenten für bessere Skalierbarkeit
  • 🔁 Zuverlässige Event-Notification und Auditierung
Eine Service Broker-Anwendung besteht aus Nachrichtentypen, einem Kontrakt, Warteschlangen (Queues) und Diensten. Die Kommunikation läuft über logische Konversationen zwischen initiierendem und Ziel-Dienst. Service Broker ermöglicht dabei eine Priorisierung von 10 (hoch) bis 1 (niedrig) pro Konversation.[reference:0]
-- Service Broker für eine Datenbank aktivieren
ALTER DATABASE [MeineDB] SET ENABLE_BROKER;

-- Nachrichtentyp erstellen
CREATE MESSAGE TYPE [//MyApp/RequestMessage] VALIDATION = WELL_FORMED_XML;

-- Kontrakt erstellen
CREATE CONTRACT [//MyApp/SampleContract] (
  [//MyApp/RequestMessage] SENT BY INITIATOR
);

-- Warteschlange und Dienst erstellen
CREATE QUEUE [dbo].[TargetQueue];
CREATE SERVICE [//MyApp/TargetService]
  ON QUEUE [dbo].[TargetQueue]
  ([//MyApp/SampleContract]);
💡 Wichtig: Service Broker-Objekte werden oft mit URI-ähnlichen Namen versehen, um Eindeutigkeit über mehrere Instanzen hinweg zu gewährleisten.[reference:1]

⛔ CAP_CPU_PERCENT – Hard Cap für CPU-Ressourcen

Resource Governor ermöglicht es, CPU, Arbeitsspeicher und I/O zwischen verschiedenen Workloads aufzuteilen. Dabei unterscheidet man zwischen weichen und harten Limits:
  • MAX_CPU_PERCENT – eine weiche Grenze, die nur bei CPU-Konflikten greift. Ist genug Kapazität vorhanden, kann die Workload auch 100 % erreichen.[reference:2]
  • CAP_CPU_PERCENT – ein harter CPU-Limit. Die Workload kann niemals diesen Wert überschreiten, selbst wenn die CPU vollständig idle ist.[reference:3][reference:4]
CAP_CPU_PERCENT wurde mit SQL Server 2012 eingeführt.[reference:5] Es ist ideal, um eine Workload auf einen festen Prozentsatz zu begrenzen – z. B. für kostenträgerbasierte Abrechnung oder zum Schutz kritischer Systeme vor Ressourcenhungrigen Prozessen.
-- Ressourcenpool mit Hard Cap von 30 % CPU erstellen
CREATE RESOURCE POOL PoolLimit
WITH (
  MIN_CPU_PERCENT = 0,
  MAX_CPU_PERCENT = 100,
  CAP_CPU_PERCENT = 30
);
GO

-- Resource Governor neu konfigurieren
ALTER RESOURCE GOVERNOR RECONFIGURE;
GO
⚠️ Wichtiger Hinweis: Wegen der statistischen Natur der CPU-Governance kann es kurzzeitige Spitzen über den CAP_CPU_PERCENT-Wert geben. Langfristig wird der Durchschnitt jedoch eingehalten.[reference:6]

🚨 Das Problem: Blockaden durch CPU-Kappung

Die Kombination von Service Broker mit CAP_CPU_PERCENT ist riskant. Grund: Service Broker benötigt schnelle Kontextwechsel, um Nachrichten aus der Warteschlange zu verarbeiten und Ressourcen freizugeben. Ein harter CPU-Limit führt dazu, dass der SQL Server „Leerlauf-Consumer“ in die ausführbare Warteschlange einfügt, um das CPU-Quantum zu füllen – und genau das erzeugt den Wartetyp RESOURCE_GOVERNOR_IDLE.
Konkrete Probleme im Alltag:
  • Erhöhte Latenz bei Nachrichten: Nachrichten bleiben länger in der Warteschlange, weil der aktivierte Dienst weniger CPU-Quanten erhält.
  • Wartetyp RESOURCE_GOVERNOR_IDLE: Dies ist ein direktes Indiz dafür, dass der harte CPU-Limit greift und künstliche Leerlaufzeiten erzeugt.[reference:7]
  • Blockierte Sperren durch Kontextwechsel: Bei Verwendung von Datenbanksperren (z. B. UPDLOCK) kann ein künstlicher Delay dazu führen, dass Sperren länger gehalten werden – mit Kettenreaktionen auf andere Workloads.[reference:8]
  • Unterauslastung der CPU: Paradoxerweise kann die CPU trotz vorhandener Arbeit idle sein, weil das Limit die Verarbeitung künstlich ausbremst.
🚨 Beispiel aus der Praxis: Ein Administrator begrenzte einen Reporting-Service auf 30 % CPU mit MAX_CPU_PERCENT. Unter Volllast – wenn nur dieser eine Bericht lief – nutzte die Instanz jedoch über 30 % CPU, weil MAX_CPU_PERCENT nur bei CPU-Konflikten greift.[reference:9] Dies führte zur Verwirrung. Wäre stattdessen CAP_CPU_PERCENT=30 gesetzt worden, hätte SQL Server künstliche Leerlaufzeiten eingefügt, was wiederum die Service Broker-Verarbeitung beeinträchtigt hätte.

📊 RESOURCE_GOVERNOR_IDLE – Frühwarnsystem für CPU-Limits

Dieser spezielle Wartetyp ist nicht zu unterschätzen. Er zeigt an, dass SQL Server aktiv Leerlaufzeiten einfügt, weil ein Ressourcenpool sein CPU-Kontingent (CAP_CPU_PERCENT) bereits ausgeschöpft hat.
-- RESOURCE_GOVERNOR_IDLE in den Wartestatistiken anzeigen
SELECT 
  wait_type,
  waiting_tasks_count,
  wait_time_ms,
  max_wait_time_ms,
  signal_wait_time_ms
FROM sys.dm_os_wait_stats
WHERE wait_type = 'RESOURCE_GOVERNOR_IDLE'
ORDER BY wait_time_ms DESC;

-- Ringbuffer-Einträge für das Phänomen finden
SELECT * FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type = 'RING_BUFFER_SCHEDULER'
  AND record LIKE '%SCHEDULER_IDLE_ENQUEUE%';
💡 Interpretation: Hohe Werte bei RESOURCE_GOVERNOR_IDLE bedeuten, dass ein CPU-Limit aktiv ist und künstliche Pausen eingefügt werden. Wenn dies genau die Service Broker-Workload betrifft, verschlechtert sich die Nachrichtenverarbeitungsrate massiv. In solchen Fällen sollten Sie das CPU-Limit überdenken.
📌 Achtung: Ein gewisses Maß an RESOURCE_GOVERNOR_IDLE ist normal, wenn Sie CAP_CPU_PERCENT verwenden. Problematisch wird es erst, wenn die Wartezeit signifikant wird und gleichzeitig Nachrichten sich stauen.

✅ Sichere Konfiguration für Service Broker mit Resource Governor

  • Verwenden Sie MAX_CPU_PERCENT statt CAP_CPU_PERCENT für Service Broker: Da MAX_CPU_PERCENT nur bei CPU-Konflikten greift, bleibt die Service Broker-Leistung bei freien Ressourcen unbeeinträchtigt – genau das, was eine Message Queue braucht. Der harte CAP_CPU_PERCENT ist für asynchrone Hintergrunddienste meist ungeeignet.[reference:10]
  • Isolieren Sie Service Broker in einer eigenen Workload-Gruppe: So vermischen Sie es nicht mit anderen, ressourcenhungrigen Prozessen.
  • Optimieren Sie die Queue-Verarbeitung: Nutzen Sie WAITFOR (RECEIVE ...) statt Polling, um CPU-Zyklen zu sparen.
  • Überwachen Sie RESOURCE_GOVERNOR_IDLE systematisch: Beziehen Sie diesen Wartetyp in Ihr Performance-Monitoring ein, um frühzeitig zu erkennen, ob ein CPU-Limit ungewollte Nebeneffekte erzeugt.
  • Definieren Sie Prioritäten: Nutzen Sie die Möglichkeit von Service Broker, Konversationen mit Prioritäten (1–10) zu versehen, um kritische Nachrichten bevorzugt zu verarbeiten.[reference:11]
  • Vermeiden Sie unnötige Datenbanksperren in Service Broker-Aktivierungsprozeduren: Sperren in Kombination mit CPU-Kappung verstärken das Problem der blockierten Kontextwechsel.[reference:12]
💡 Empfehlung für die Praxis: Wenn Sie zwingend einen harten CPU-Limit für eine Service Broker-Workload benötigen (z. B. aus Kosten- oder Compliance-Gründen), setzen Sie den Wert nicht zu niedrig an (mindestens 20 %) und testen Sie die Nachrichtendurchsatzrate intensiv. In vielen Szenarien ist jedoch MAX_CPU_PERCENT die bessere Wahl.

🛠️ Schritt-für-Schritt: Service Broker in eigene Resource Pool isolieren

Folgende Schritte zeigen, wie Sie eine Service Broker-Workload in einen eigenen Ressourcenpool mit MAX_CPU_PERCENT auslagern:
-- 1. Ressourcenpool erstellen (weicher CPU-Limit, kein Hard Cap)
CREATE RESOURCE POOL PoolBroker
WITH (
  MIN_CPU_PERCENT = 0,
  MAX_CPU_PERCENT = 30, -- weiches Limit, nur bei Konflikten
  CAP_CPU_PERCENT = 100 -- de facto deaktiviert
);
GO

-- 2. Workload-Gruppe für Service Broker
CREATE WORKLOAD GROUP GroupBroker
USING PoolBroker;
GO

-- 3. Klassifizierungsfunktion erstellen (Beispiel: alle Sitzungen mit 'BROKER' in der Anwendung)
CREATE OR ALTER FUNCTION dbo.ClassifierBroker()
RETURNS SYSNAME
WITH SCHEMABINDING
AS
BEGIN
  DECLARE @group_name SYSNAME = N'default';
  IF APP_NAME() LIKE N'%ServiceBroker%'
    SET @group_name = N'GroupBroker';
  RETURN @group_name;
END;
GO

-- 4. Resource Governor mit neuer Klassifizierung konfigurieren
ALTER RESOURCE GOVERNOR
  WITH (CLASSIFIER_FUNCTION = dbo.ClassifierBroker);
ALTER RESOURCE GOVERNOR RECONFIGURE;
GO
⚠️ Hinweis: Resource Governor ist nicht in allen SQL Server-Editionen verfügbar. Prüfen Sie vorab die Editionsunterstützung.[reference:13]

🔍 Fehlersuche: Service Broker + CAP_CPU_PERCENT

  • Symptom: Nachrichten stauen sich in der Warteschlange, obwohl keine aktiven Blockaden erkennbar sind. Lösung: Prüfen Sie, ob die Service Broker-Workload in einem Pool mit CAP_CPU_PERCENT läuft.
  • Symptom: Hohe Werte von RESOURCE_GOVERNOR_IDLE. Lösung: Überprüfen Sie die CAP_CPU_PERCENT-Konfiguration. Setzen Sie den Wert höher oder wechseln Sie zu MAX_CPU_PERCENT.
  • Symptom: Geringe CPU-Auslastung trotz aktiver Nachrichten – und die Aktivierungsprozedur wird selten aufgerufen. Lösung: Eventuell hat der Dienst keine interne Aktivierung. Nutzen Sie sys.dm_broker_activated_tasks um zu prüfen, ob die Aktivierung überhaupt läuft.
  • Symptom: Aktivierungsprozedur läuft, kommt aber nicht mit der Nachrichtenflut hinterher. Lösung: Erhöhen Sie MAX_QUEUE_READERS (z. B. auf 5) und/oder optimieren Sie die Prozedur.
-- Aktive Service Broker-Tasks anzeigen
SELECT 
  session_id,
  task_address,
  state_desc
FROM sys.dm_broker_activated_tasks;

-- Resource Pool-Zuordnung für aktive Sitzungen prüfen
SELECT 
  s.session_id,
  s.program_name,
  rp.name AS resource_pool
FROM sys.dm_exec_sessions s
JOIN sys.dm_resource_governor_workload_groups wg
  ON s.group_id = wg.group_id
JOIN sys.dm_resource_governor_resource_pools rp
  ON wg.pool_id = rp.pool_id
WHERE s.program_name LIKE '%Service Broker%';
💡 Profi-Tipp: Nutzen Sie Extended Events, um das Verhalten von Service Broker und Resource Governor gemeinsam zu analysieren. Die Events sql_broker_activation und resource_governor_config_change geben detaillierte Einblicke.

✅ Zusammenfassung: So nutzen Sie beide Technologien sicher

  • Verwenden Sie CAP_CPU_PERCENT nicht pauschal für Service Broker. Der harte CPU-Limit kollidiert mit der asynchronen Natur von Warteschlangen.
  • Setzen Sie stattdessen auf MAX_CPU_PERCENT – das schützt bei Konflikten, ohne Leerlauf zu erzwingen.
  • Isolieren Sie Service Broker in einer eigenen Workload-Gruppe, um Auswirkungen anderer Prozesse zu minimieren.
  • Überwachen Sie RESOURCE_GOVERNOR_IDLE und die Warteschlangenlängen aktiv. So erkennen Sie frühzeitig, ob CPU-Limits die Nachrichtenverarbeitung beeinträchtigen.
  • Testen Sie Konfigurationsänderungen immer zuerst in einer Nicht-Produktionsumgebung, insbesondere wenn CAP_CPU_PERCENT im Spiel ist.
🚨 Letzte Warnung: Ein harter CPU-Limit mag verlockend sein, um Ressourcen zu „sparen“. Für Service Broker ist er jedoch oft kontraproduktiv, weil er die Durchsatzrate künstlich reduziert und Sperren verlängert. Hinterfragen Sie daher stets, ob ein echter Hard Cap nötig ist oder ob MAX_CPU_PERCENT nicht die bessere Lösung darstellt.
Nächster SQL Server – QUOTED_IDENTIFIER & ANSI_NULLS
Cookies user preferences
We use cookies to ensure you to get the best experience on our website. If you decline the use of cookies, this website may not function as expected.
Accept all
Decline all
Analytics
Tools used to analyze the data to measure the effectiveness of a website and to understand how it works.
Google Analytics
Advertisement
If you accept, the ads on the page will be adapted to your preferences.
Google Ad
Save