Azure托管ASP.NET Core 2.2服务高CPU及SQL连接问题咨询

Hey there, let's tackle your two questions based on the details you've shared, along with some actionable insights:

Short answer: Small, occasional CPU fluctuations are normal, but sustained swings near 90% warrant further investigation—especially given your low daily request volume (500-600 requests). Here's why and what to check:

• Even with low request counts, poorly optimized SQL interactions (e.g., unindexed queries, large result sets requiring heavy serialization) can trigger temporary CPU spikes. The fact that removing FluentMigrator's logging middleware helped suggests excessive logging/thread locking was a major culprit, but residual inefficiencies might still be present.
• Look for correlation between CPU spikes and specific events: Are there scheduled background tasks (like leftover FluentMigrator jobs, or other maintenance tasks) firing at peak times? Use Azure Application Insights' Performance Counters and Dependency Tracking to map CPU usage to individual requests or SQL operations.
• Watch out for synchronous blocking in your code: If you're using .Result or .Wait() to call async SQL methods, you could be causing thread pool starvation, leading to uneven CPU utilization as the runtime struggles to manage threads. Stick to async/await throughout your call chain where possible.
• For ASP.NET Core 2.2, Kestrel's default thread scheduling might cause minor fluctuations, but anything approaching 90% is a sign that some operation is consuming more resources than it should. Use Azure Process Explorer or Visual Studio's Performance Profiler (if you can replicate the issue locally) to identify which threads are eating up CPU—look for GC activity, SQL client processing, or unexpected background work.

Absolutely—this is highly likely, and here's the breakdown:

• Your load test generates roughly 60-70 WebSocket requests per second (6-7 clients × 10 requests/second), each triggering 3-4 SQL operations. That's 180-280 SQL transactions per second—way beyond what a 10 DTU instance can handle. DTU 10 is designed for very light workloads; even simple insert operations (which involve transaction logging and locking) will consume most of its allocated resources quickly.
• When SQL operations slow down due to DTU constraints, connections in your pool get held open longer as requests wait for results. This leads to connection exhaustion because new requests can't acquire a free connection from the pool.
• Your concern about connection leaks in the singleton WebSocket service is valid. If you're creating scoped services (like DbContext) in a singleton without properly disposing of the scope, connections won't be returned to the pool. Always use IServiceScopeFactory to create a scope, and wrap it in a using block to ensure disposal:

  using var scope = _serviceScopeFactory.CreateScope();
  var dbContext = scope.ServiceProvider.GetRequiredService<YourDbContext>();
  // Perform SQL operations
  

• To confirm, you can run the query SELECT * FROM sys.dm_exec_connections on your SQL instance during testing. If the number of active connections keeps rising without dropping after the test ends, you've got a leak.

Quick Additional Tips #

• For CPU optimization: Enable Azure Monitor's Thread Sampling to pinpoint exactly which methods are consuming CPU.
• For SQL connection issues: Even if you upgrade DTUs, optimize your SQL queries first—add indexes to frequent filter columns, merge multiple small queries into a single batch, and ensure all SQL calls use async/await to release connections faster.

内容的提问来源于stack exchange，提问作者Andrius