‫فرسایش خاموش منابع: تحلیل اشتباهات رایج در طراحی BackgroundServiceها

public sealed class ImportWorker : BackgroundService
{
    private readonly IImportQueue _queue;

    public ImportWorker(IImportQueue queue)
    {
        _queue = queue;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            var item = await _queue.ReadAsync(stoppingToken);
            _ = ProcessAsync(item, stoppingToken); // الگوی فاجعه‌بار Fire-and-Forget
        }
    }

    private async Task ProcessAsync(ImportItem item, CancellationToken cancellationToken)
    {
        // اجرای کوئری دیتابیس + درخواست HTTP + عملیات Serialization
        await Task.Delay(100, cancellationToken);
    }
}

• فشار سنگین بر حافظه و GC: هر تسک باز اشاره‌گرهایی (References) به بافرهای داده، DTOها، وضعیت‌های لاگین، کلاینت‌های HTTP و موجودیت‌های دیتابیس را زنده نگه می‌دارد و آن‌ها را به نسل‌های بالاتر Garbage Collector منتقل می‌کند.
• اشباع Connection Pool: اگر در هر تسک ارتباطی با پایگاه داده برقرار شود، به سرعت ظرفیت مخزن اتصالات به اتمام می‌رسد و خطاهایی مانند TimeoutException رخ می‌دهد.
• تحمیل بار مخرب به سرویس‌های خارجی (Downstream Overload): ارسال همزمان صدها درخواست HTTP می‌تواند کلاینت‌های دیگر را دچار Socket Exhaustion کرده یا توسط سرویس مقصد مسدود (Rate-limited) شود.
• از دست رفتن خطاهای سیستمی: متدهای ناهمگامی که به صورت Fire-and-Forget اجرا می‌شوند، در صورت مواجهه با Exception خطای خود را در فضای پیش‌فرض Process رها می‌کنند (Unobserved Task Exception) که ردیابی و عیب‌یابی آن بسیار دشوار خواهد بود.

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    while (!stoppingToken.IsCancellationRequested)
    {
        var item = await _queue.ReadAsync(stoppingToken);
        await ProcessAsync(item, stoppingToken); // سقف دقیق: دقیقاً یک کار همزمان
    }
}

public sealed class ImportWorker : BackgroundService
{
    private const int MaxConcurrency = 8;
    private readonly IImportQueue _queue;

    public ImportWorker(IImportQueue queue)
    {
        _queue = queue;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        using var semaphore = new SemaphoreSlim(MaxConcurrency);
        var runningTasks = new HashSet<Task>();

        while (!stoppingToken.IsCancellationRequested)
        {
            var item = await _queue.ReadAsync(stoppingToken);

            await semaphore.WaitAsync(stoppingToken);

            var task = ProcessWithReleaseAsync(item, semaphore, stoppingToken);
            runningTasks.Add(task);
            
            // پاک‌سازی تسک‌های تکمیل‌شده برای جلوگیری از رشد مجموعه
            runningTasks.RemoveWhere(static t => t.IsCompleted);
        }

        // تضمین تکمیل کارهای در حال پردازش پیش از خروج کامل سرویس
        await Task.WhenAll(runningTasks);
    }

    private async Task ProcessWithReleaseAsync(
        ImportItem item,
        SemaphoreSlim semaphore,
        CancellationToken cancellationToken)
    {
        try
        {
            await ProcessAsync(item, cancellationToken);
        }
        finally
        {
            semaphore.Release();
        }
    }
}

public sealed class BackgroundTaskQueue
{
    private readonly Channel<Func<CancellationToken, ValueTask>> _channel =
        Channel.CreateUnbounded<Func<CancellationToken, ValueTask>>();

    public ValueTask QueueAsync(Func<CancellationToken, ValueTask> workItem)
    {
        return _channel.Writer.WriteAsync(workItem);
    }

    public ValueTask<Func<CancellationToken, ValueTask>> DequeueAsync(
        CancellationToken cancellationToken)
    {
        return _channel.Reader.ReadAsync(cancellationToken);
    }
}

• تولیدکننده‌ها با نرخ عادی به افزودن آیتم‌ها ادامه می‌دهند.
• هیچ مکانیزمی کار جدید را رد نمی‌کند و جلوی تولیدکننده‌ها را نمی‌گیرد.
• هیچ سقفی برای مصرف حافظه RAM تعریف نشده است.

public sealed class BackgroundTaskQueue
{
    private readonly Channel<WorkItem> _channel;

    public BackgroundTaskQueue(int capacity)
    {
        var options = new BoundedChannelOptions(capacity)
        {
            FullMode = BoundedChannelFullMode.Wait,
            SingleReader = true,
            SingleWriter = false
        };

        _channel = Channel.CreateBounded<WorkItem>(options);
    }

    public ValueTask EnqueueAsync(
        WorkItem item,
        CancellationToken cancellationToken = default)
    {
        return _channel.Writer.WriteAsync(item, cancellationToken);
    }

    public ValueTask<WorkItem> DequeueAsync(
        CancellationToken cancellationToken)
    {
        return _channel.Reader.ReadAsync(cancellationToken);
    }
}

• Wait (حالت پیش‌فرض): تولیدکننده را متوقف می‌کند تا فضا آزاد شود. این حالت تضمین می‌کند هیچ داده‌ای گم نشود و در عین حال مصرف حافظه کنترل شود (مناسب برای تراکنش‌های مهم).
• DropOldest / DropNewest: داده‌های قدیمی یا جدید را رها می‌کند (مناسب برای لاگ‌ها، تلمتری یا پیام‌های دوره‌ای مانند وضعیت سنسورها).
• DropWrite: پیام را نمی‌پذیرد و به صورت صریح شکست عملیات ثبت را مشخص می‌کند تا بتوان به کلاینت پاسخ 429 Too Many Requests یا 503 Service Unavailable بازگرداند.

• عمق فعلی صف (Queue Depth)
• سن قدیمی‌ترین آیتم منتظر (Oldest Item Age)
• مدت‌زمان توقف تولیدکننده هنگام درج (Enqueue Wait Duration)
• نرخ خروج و پردازش آیتم‌ها (Dequeue Throughput)

public sealed class CleanupWorker : BackgroundService
{
    private readonly AppDbContext _db;

    public CleanupWorker(AppDbContext db)
    {
        _db = db; // خطای Captive Dependency: آبجکت Scoped در یک Singleton به دام افتاده است
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            var expired = await _db.Sessions
                .Where(x => x.ExpiresAt < DateTimeOffset.UtcNow)
                .ToListAsync(stoppingToken);

            _db.Sessions.RemoveRange(expired);
            await _db.SaveChangesAsync(stoppingToken);

            await Task.Delay(TimeSpan.FromMinutes(1), stoppingToken);
        }
    }
}

• انباشت حافظه در Change Tracker: پیش‌فرض EF Core این است که موجودیت‌های کوئری‌شده را در ChangeTracker ردیابی کند. وقتی طول عمر DbContext معادل طول عمر کل پروسس باشد، این لیست ردیابی در هر تکرار حلقه بزرگ‌تر شده، آبجکت‌ها در حافظه زنده می‌مانند و نشت تدریجی حافظه (Memory Leak) رخ می‌دهد.
• عدم بازخوانی داده‌های به‌روز (Stale Data): کانتکست دیتابیس داده‌های لود شده را در کش لایه‌اول (First-level Cache) نگه می‌دارد. اگر رکوردی توسط بخش دیگری از اپلیکیشن تغییر کند، این ورکر متوجه آن نخواهد شد و با داده‌های قدیمی کار می‌کند.
• خطای همزمانی و Thread Safety: نمونه‌های DbContext به هیچ عنوان Thread-Safe نیستند. اگر بخش‌های مختلف ورکر یا تسک‌های همزمان به یک نمونه مشترک دسترسی پیدا کنند، خطای مشهور InvalidOperationException مبنی بر همزمانی دسترسی رخ می‌دهد.

public sealed class CleanupWorker : BackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory;

    public CleanupWorker(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            // ساخت اسکوپ ناهمگام به ازای هر اجرای منطقی
            await using (var scope = _scopeFactory.CreateAsyncScope())
            {
                var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
                await DeleteExpiredSessionsAsync(db, stoppingToken);
            }

            await Task.Delay(TimeSpan.FromMinutes(1), stoppingToken);
        }
    }

    private static async Task DeleteExpiredSessionsAsync(
        AppDbContext db,
        CancellationToken cancellationToken)
    {
        var expired = await db.Sessions
            .Where(x => x.ExpiresAt < DateTimeOffset.UtcNow)
            .ToListAsync(cancellationToken);

        if (expired.Count > 0)
        {
            db.Sessions.RemoveRange(expired);
            await db.SaveChangesAsync(cancellationToken);
        }
    }
}

• استفاده از CreateAsyncScope و await using: در دات‌نت مدرن، همیشه از CreateAsyncScope استفاده کنید تا وابستگی‌هایی که اینترفیس IAsyncDisposable را پیاده‌سازی کرده‌اند، بدون بلاک کردن ترد و به صورت کاملاً غیرهمگام آزاد شوند.
• استفاده از IDbContextFactory: اگر در ورکر خود همزمانی بالا دارید و نمی‌خواهید برای هر کار کوچک اسکوپ کامل DI بسازید، رجیستر کردن و تزریق IDbContextFactory راهکاری بسیار سبک‌تر و بهینه‌تر برای ایجاد کانتکست‌های مجزا است.
• بهره‌گیری از ExecuteDeleteAsync در سناریوهای پاک‌سازی: در متد پاک‌سازی بالا، لود کردن کل داده‌ها در رم و فراخوانی RemoveRange پردازشی سنگین است. در EF Core 7+ می‌توان با یک کوئری مستقیم مانند زیر، کارایی را به شدت ارتقا داد بدون اینکه نیاز به لود حتی یک رکورد در حافظه باشد:

await db.Sessions
    .Where(x => x.ExpiresAt < DateTimeOffset.UtcNow)
    .ExecuteDeleteAsync(cancellationToken);

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    while (!stoppingToken.IsCancellationRequested)
    {
        await Task.Run(() => ProcessBatch(), stoppingToken);
        await Task.Delay(1000, stoppingToken);
    }
}

// الگوی ضدبهینه: سربار زمان‌بندی بیهوده روی تردهای ThreadPool
await Task.Run(async () =>
{
    await db.SaveChangesAsync(stoppingToken);
    await httpClient.PostAsync(url, content, stoppingToken);
}, stoppingToken);

await db.SaveChangesAsync(stoppingToken);
await httpClient.PostAsync(url, content, stoppingToken);

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    while (!stoppingToken.IsCancellationRequested)
    {
        // مسدود کردن قطعی یک نخ از ThreadPool تا اتمام عملیات
        var result = SomeAsyncOperation(stoppingToken).Result; 
        Process(result);
        await Task.Delay(100, stoppingToken);
    }
}

آیا این پردازش سنگین محاسباتی اساساً باید درون همان پروسسی اجرا شود که در حال پاسخ‌دهی به درخواست‌های حساس API است؟

• ThreadPool Queue Length (طول صف کارهای منتظر نخ)
• Thread Count / Active Worker Threads (تعداد تردهای فعال)
• CPU Saturation (میزان اشباع پردازنده)
• API Latency (p95 / p99) در زمان اجرای بارهای پس‌زمینه

_timer = new Timer(
    async _ => await ExecuteCleanupAsync(),
    null,
    TimeSpan.Zero,
    TimeSpan.FromSeconds(10));

• انفجار همزمانی (Concurrency Multiplication): کندی یک وابستگی خارجی به‌جای مهار شدن، باعث راه‌اندازی چندین نمونه همزمان از همان جاب می‌شود.
• رقابت بر سر منابع و دیتابیس: هر اجرا اسکوپ جدیدی می‌سازد، اتصالات دیتابیس جداگانه‌ای می‌گیرد و احتمالاً رکوردهای یکسانی را واکشی و قفل می‌کند. این تداخل می‌تواند منجر به Deadlock یا رقابت مخرب (Race Condition) شود.
• فقدان انتشار CancellationToken: در ساختار تایمر سنتی، متدهای ناهمگام به صورت async void اجرا می‌شوند که مدیریت خطا و لغو تمیز پردازش را به شدت دشوار می‌سازد.

public sealed class ReconciliationWorker : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        using var timer = new PeriodicTimer(TimeSpan.FromSeconds(10));

        // تا زمانی که متد ReconcileAsync به پایان نرسد، اجرای بعدی آغاز نمی‌شود
        while (await timer.WaitForNextTickAsync(stoppingToken))
        {
            await ReconcileAsync(stoppingToken);
        }
    }

    private static async Task ReconcileAsync(CancellationToken cancellationToken)
    {
        // اجرای پردازش به صورت ترتیبی و کنترل‌شده
        await Task.Delay(100, cancellationToken);
    }
}

while (!stoppingToken.IsCancellationRequested)
{
    var started = TimeProvider.System.GetTimestamp();

    await ExecuteBatchAsync(stoppingToken);

    var elapsed = TimeProvider.System.GetElapsedTime(started);
    logger.LogInformation("Batch completed in {Elapsed}", elapsed);

    // دقیقاً ۱۰ ثانیه پس از اتمام اجرای قبلی صبر کن
    await Task.Delay(TimeSpan.FromSeconds(10), stoppingToken);
}

private async Task SendAsync(Message message, CancellationToken cancellationToken)
{
    // خطای کلاسیک: چرخه حیات اشتباه کلاینت
    using var client = new HttpClient();
    await client.PostAsJsonAsync("https://example.com/messages", message, cancellationToken);
}

// ثبت Typed Client در Program.cs با تنظیمات مشخص
builder.Services.AddHttpClient<NotificationClient>(client =>
{
    client.BaseAddress = new Uri("https://notifications.internal");
    client.Timeout = TimeSpan.FromSeconds(5);
});

public sealed class NotificationClient
{
    private readonly HttpClient _httpClient;

    public NotificationClient(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task SendAsync(
        Notification notification,
        CancellationToken cancellationToken)
    {
        using var response = await _httpClient.PostAsJsonAsync(
            "/api/notifications",
            notification,
            cancellationToken);

        response.EnsureSuccessStatusCode();
    }
}

// الگوی پرریسک: Fan-out همزمان بدون سقف
await Task.WhenAll(
    messages.Select(x => notificationClient.SendAsync(x, cancellationToken)));

await Parallel.ForEachAsync(
    messages,
    new ParallelOptions
    {
        MaxDegreeOfParallelism = 16,
        CancellationToken = cancellationToken
    },
    async (message, ct) =>
    {
        await notificationClient.SendAsync(message, ct);
    });

• تنظیمات PooledConnectionLifetime: هنگام استفاده از SocketsHttpHandler یا فکتوری، چرخه حیات اتصال را با PooledConnectionLifetime (مثلاً ۱۵ دقیقه) محدود کنید تا در صورت تغییر DNS سرور مقصد، ورکرها به آدرس‌های منسوخ متصل نمانند.
• استفاده از Resilient Handlers: ترکیب کلاینت با کتابخانه‌های تاب‌آوری مانند Microsoft.Extensions.Http.Resilience (یا Polly) برای اعمال خودکار الگوهای Circuit Breaker، Retry و Timeoutهای هوشمند الزامی است تا کندی یا قطعی مقطعی سرور مقصد کل ورکر را قفل نکند.

var tasks = batch.Select(async item =>
{
    await using var scope = scopeFactory.CreateAsyncScope();
    var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();

    var entity = await db.Items
        .SingleAsync(x => x.Id == item.Id, cancellationToken);

    entity.Process();
    await db.SaveChangesAsync(cancellationToken);
});

await Task.WhenAll(tasks);

• مخزن اتصالات درجا اشباع می‌شود.
• اتصالات بعدی مجبورند در صف قفل شوند تا کانکشن‌های قبلی آزاد شوند (Connection Pool Wait Time).
• اولین نشانه این بحران رخ دادن TimeoutException نیست؛ بلکه جهش شدید در تأخیر دم‌دراز (p99 / Tail Latency) در APIهای اصلی سیستم است. اندپوینت‌های وب که در حالت عادی زیر ۱۰ میلی‌ثانیه پاسخ می‌دادند، حالا برای گرفتن یک کانکشن خالی ثانیه‌ها معطل می‌مانند.
• رقابت بر سر تراکنش‌ها و بروز Lock Contention در سطح جداول دیتابیس بالا می‌گیرد.

await Parallel.ForEachAsync(
    batch,
    new ParallelOptions
    {
        MaxDegreeOfParallelism = 8, // سقف مشخص برای همزمانی استفاده از کانکشن‌ها
        CancellationToken = cancellationToken
    },
    async (item, ct) =>
    {
        await using var scope = scopeFactory.CreateAsyncScope();
        var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();

        await ProcessItemAsync(db, item, ct);
    });

await using var scope = scopeFactory.CreateAsyncScope();
var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();

var ids = batch.Select(x => x.Id).ToArray();

// واکشی دسته‌ای همه رکوردها در قالب یک کوئری به جای N کوئری مجزا
var entities = await db.Items
    .Where(x => ids.Contains(x.Id))
    .ToListAsync(cancellationToken);

foreach (var entity in entities)
{
    entity.Process();
}

// ارسال تغییرات در قالب یک تراکنش واحد و بهینه
await db.SaveChangesAsync(cancellationToken);

• بهینه‌سازی سایز دسته‌ها (Chunking): ارسال لیست‌های بسیار بزرگ به متد Contains (عملگر IN در SQL) می‌تواند به تولید کوئری‌های عظیم منجر شود. تقسیم داده‌ها به تکه‌های کوچک‌تر (مثلاً بسته‌های ۱۰۰ تا ۲۵۰ تایی با متد .Chunk()) رفتاری پایدار و پیش‌بینی‌پذیر ایجاد می‌کند.
• استفاده از ExecuteUpdateAsync در EF Core: برای به‌روزرسانی‌های ساختاریافته بدون نیاز به لود موجودیت‌ها در ChangeTracker، متد ExecuteUpdateAsync کل عملیات را به صورت یک دستور بهینه SQL ترجمه کرده و فشار روی رم و کانکشن را به حداقل می‌رساند.
• جداسازی دیتابیس تحلیلی/گزارشی (Read Replicas): اگر ورکرها وظایف سنگین تحلیلی یا گزارش‌گیری دارند، باید کانکشن‌استرینگ آن‌ها به سمت Read Replicaهای پایگاه داده هدایت شود تا ترافیک خواندن آن‌ها ظرفیت تراکنش‌های اصلی سیستم (OLTP) را کاهش ندهد.

// الگوی ضدبهینه و مخرب: نادیده گرفتن توکن لغو هاست
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    while (true)
    {
        await ProcessBatchAsync(CancellationToken.None); // ایزوله کردن متد از سیگنال خروج
        await Task.Delay(TimeSpan.FromSeconds(5));       // توقف ناپذیر در زمان خاموشی
    }
}

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    while (!stoppingToken.IsCancellationRequested)
    {
        await ProcessBatchAsync(stoppingToken);
        await Task.Delay(TimeSpan.FromSeconds(5), stoppingToken);
    }
}

// کوئری دیتابیس با پشتیبانی از لغو
var pendingJobs = await db.PendingJobs
    .Where(x => x.Status == JobStatus.Pending)
    .Take(100)
    .ToListAsync(stoppingToken);

// درخواست خروجی HTTP با پشتیبانی از لغو
using var response = await httpClient.SendAsync(
    request,
    HttpCompletionOption.ResponseHeadersRead,
    stoppingToken);

public sealed class TrackedWorker : BackgroundService
{
    private readonly ConcurrentDictionary<Guid, Task> _activeTasks = new();

    private void TrackTask(Guid id, Task task)
    {
        _activeTasks[id] = task;
        _ = task.ContinueWith(
            _ => _activeTasks.TryRemove(id, out _),
            CancellationToken.None,
            TaskContinuationOptions.ExecuteSynchronously,
            TaskScheduler.Default);
    }

    public override async Task StopAsync(CancellationToken cancellationToken)
    {
        // منتظر اتمام کارهای جاری تا سقف مجاز زمان Shutdown بمانید
        await Task.WhenAll(_activeTasks.Values);
        await base.StopAsync(cancellationToken);
    }
}

• آیا ورکر تراکنش‌های طولانی‌مدت و سنگینی روی دیتابیس باز نگه داشته است؟
• آیا زمان تایم‌اوت در HttpClient بیشتر از بودجه کل زمان خاموش شدن هاست است؟
• آیا در لایه‌های عمیق سرویس‌ها توکن لغو نادیده گرفته شده است؟
• آیا صف‌های درون‌حافظه‌ای آن‌قدر انباشته شده‌اند که تخلیه آن‌ها در بازه Shutdown ناممکن است؟

• نبود سقف برای حجم صف‌های کاری
• نبود سقف برای همزمانی اجرای تسک‌ها
• نبود سقف برای اتصالات همزمان به پایگاه داده
• نبود سقف برای درخواست‌های موازی خروجی (HTTP Fan-out)
• نبود تعریف شفاف برای طول عمر وابستگی‌های Scoped
• نبود مرز مشخص برای توقف و لغو عملیات (Cancellation)
• نبود سیاست ساختاریافته برای رفتار سیستم در زمان اضافه بار (Overload Policy)

1. استفاده از صف‌های مقید: برای انباشت کار، همواره از Bounded Channel همراه با استراتژی مشخص اعمال Backpressure استفاده کنید.
2. شفاف‌سازی سقف همزمانی: همزمانی را نه یک اثر جانبی، بلکه یک سیاست معماری ملموس با سقف مشخص (مثلاً از طریق Parallel.ForEachAsync یا SemaphoreSlim) در نظر بگیرید.
3. تعریف دقیق مرزهای اسکوپ: ساخت IServiceScope را به واحد کار معنادار عملیاتی محدود کرده و پس از اتمام کار، منابع را بلافاصله آزاد کنید.
4. پرهیز از سربار ترد: عملیات ذاتا I/O-Bound را بیهوده در Task.Run محصور نکنید و از مسدود کردن همگام متدها (Sync-over-Async) بپرهیزید.
5. جلوگیری از همپوشانی اجرای دوره‌ای: با ابزارهایی مانند PeriodicTimer مانع اجرای همزمان و تصادفی کارهای زمان‌بندی‌شده شوید.
6. مدیریت دولایه اتصالات HTTP: با IHttpClientFactory چرخه حیات سوکت‌ها را ایمن کنید و با کنترل همزمانی، شکل بار ارسالی به شبکه را مهار نمایید.
7. احترام به سهم مشترک دیتابیس: پایگاه داده را یک زیرساخت اشتراکی ببینید و با Batching و محدود کردن همزمانی، ظرفیت Connection Pool را حفظ کنید.
8. انتشار کامل توکن لغو: پارامتر stoppingToken را تا عمیق‌ترین سطوح I/O دیتابیس و شبکه هدایت کنید تا فرآیند Graceful Shutdown زیرساخت‌های ابری و کانتینری بدون مانع انجام شود.

• عمق و سن آیتم‌های صف (Queue Depth & Age)
• تعداد کارهای فعال همزمان و نرخ تخصیص حافظه (GC Allocations)
• مدت‌زمان معطلی در صف دریافت کانکشن دیتابیس (Connection Acquisition Wait)
• زمان‌های پاسخگویی p50، p95 و به ویژه p99 در فراخوانی‌های شبکه و کوئری‌ها
• نرخ خطاها، تایم‌اوت‌ها و مدت‌زمان تکمیل خاموشی سیستم