Представьте, сервис на C# стал медленнее или нестабильнее после релиза. Какие language/runtime-specific причины вы проверите?

Где искать причины деградации .NET-сервиса

Когда сервис на C# / .NET стал медленнее или нестабильнее после релиза, причины делятся на несколько категорий: GC и память, thread pool и async, JIT и startup, ресурсы (соединения, файлы), и изменения в зависимостях. Проходим по каждой.

1. GC pressure и memory allocation

Наиболее частая причина регрессии производительности — рост аллокаций. Симптомы: CPU spikes каждые N секунд, увеличение GC pause time в метриках.

// Диагностика через dotnet-counters
// dotnet-counters monitor --process-id <PID> --counters System.Runtime
// Смотрим: gen-0-gc-count, gen-1-gc-count, gen-2-gc-count, loh-size

// Антипаттерн: string concatenation в hot path
string result = "";
for (int i = 0; i < 10000; i++)
    result += items[i]; // O(n^2) allocations

// Исправление
var sb = new System.Text.StringBuilder(capacity: 10000 * 20);
for (int i = 0; i < 10000; i++)
    sb.Append(items[i]);
string result = sb.ToString();

// Или через LINQ/string.Concat без промежуточных объектов
string result = string.Concat(items);

Инструменты: dotnet-counters, dotnet-trace с EventPipe, PerfView, Visual Studio Diagnostic Tools, JetBrains dotMemory.

2. Thread pool starvation (sync-over-async)

Самая коварная причина нестабильности в ASP.NET Core — блокирование потоков thread pool вызовами .Result, .Wait(), GetAwaiter().GetResult().

// Проблема: захват thread pool потока на время IO
public IActionResult Get()
{
    var data = _repository.GetDataAsync().Result; // блокирует поток TP
    return Ok(data);
}

// После релиза под нагрузкой: TP исчерпан, запросы встают в очередь
// Метрика: ThreadPool.PendingWorkItemCount растёт

// Исправление: полностью async pipeline
public async Task<IActionResult> GetAsync(CancellationToken ct)
{
    var data = await _repository.GetDataAsync(ct);
    return Ok(data);
}

Диагностика: dotnet-counters — метрика threadpool-queue-length и active-timer-count. В логах: задержки на ровно кратные значения (признак голодания TP).

3. DbContext / connection pool деградация

// Антипаттерн: DbContext как Singleton или неправильный Scoped в фоновых сервисах
services.AddDbContext<AppDbContext>(opts =>
    opts.UseNpgsql(connectionString)); // Scoped — правильно для HTTP

// Для IHostedService нужен IServiceScopeFactory:
public class BackgroundWorker(IServiceScopeFactory scopeFactory) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken ct)
    {
        using var scope = scopeFactory.CreateScope();
        var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        await db.Users.CountAsync(ct);
    }
}

// Connection pool exhaustion диагностируется через:
// Npgsql: NpgsqlConnection.ConnectionPoolStats
// Или через pg_stat_activity в PostgreSQL

4. JIT warm-up и Tiered Compilation

После деплоя .NET JIT компилирует методы в несколько тиров: сначала быстрый Tier0, потом оптимизированный Tier1. Первые N секунд после запуска сервис всегда медленнее — это ожидаемо, не баг. Если латентность не стабилизируется, проверьте:

• ReadyToRun (R2R) compilation включена? (<PublishReadyToRun>true</PublishReadyToRun>)
• Profile-Guided Optimization (PGO) для .NET 7+: DOTNET_TieredPGO=1
• Startup проблема или steady-state: сравните p99 через 30 секунд и через 10 минут.

5. Чеклист диагностики после релиза

• dotnet-counters monitor — базовые runtime метрики в реальном времени.
• dotnet-dump collect + dotnet-dump analyze — heap snapshot при OOM или зависании.
• dotnet-trace collect --profile gc-verbose — детальный GC trace.
• OpenTelemetry + Prometheus: runtime.dotnet.gc.collections, runtime.dotnet.threadpool.threads.count.
• Сравнение git diff NuGet-пакетов между релизами — обновление зависимости может изменить поведение.

Подводные камни

• LOH (Large Object Heap, объекты > 85 000 байт) не компактируется по умолчанию — фрагментация накапливается при частых аллокациях больших буферов.
• ConfigureAwait(false) в библиотечном коде предотвращает захват SynchronizationContext, но не влияет на ASP.NET Core (там нет SC по умолчанию).
• EF Core change tracker накапливает сущности при длинных сценариях — AsNoTracking() для read-only запросов обязателен.
• HttpClient не должен создаваться per-request — используйте IHttpClientFactory для переиспользования connection pool.
• CancellationToken не передан в async методы — сервис не может отменить запрос при таймауте клиента, поток занят.
• ObjectPool<T> помогает при частом создании дорогих объектов (StringBuilder, MemoryStream), но требует корректного Reset.
• Tiered compilation может маскировать проблему производительности при нагрузочном тестировании сразу после старта.
• Утечки IDisposable без using/await using — HttpResponseMessage, DbConnection, StreamReader должны явно освобождаться.

• Сразу обвинять C#, не проверив соседние слои системы
• Чинить симптом без минимального воспроизведения и evidence
• Не учитывать версии, конфигурацию, окружение и recent changes

• Умеет локализовать проблему вокруг C#
• Двигается от симптома к гипотезам и проверкам
• Отличает баг инструмента от ошибки использования или окружения