دسکتاپ، Worker و محاسبات محلی · فصل ۴ — Grants، Resource Envelope و Power · 187
Resource Envelope و Protected Primary
اپ یا worker محلی را اجرا می‌کند اما device identity، privilege، offline state و fleet behavior را طراحی نکرده است. موضوع جاری: «Resource Envelope و Protected Primary». می‌تواند «Resource Envelope و Protected Primary» را برای یک node محلی با identity، state، privilege و recovery boundary مناسب طراحی کند.
خلاصهٔ درس
اپ یا worker محلی را اجرا می‌کند اما device identity، privilege، offline state و fleet behavior را طراحی نکرده است. موضوع جاری: «Resource Envelope و Protected Primary».
می‌تواند «Resource Envelope و Protected Primary» را برای یک node محلی با identity، state، privilege و recovery boundary مناسب طراحی کند.
خروجی این درس
می‌تواند «Resource Envelope و Protected Primary» را برای یک node محلی با identity، state، privilege و recovery boundary مناسب طراحی کند.
پیش‌نیازها
1. درست اجراشدن Worker کافی نیست
یک Worker پس‌زمینه ممکن است از نظر تابعی کاملاً درست باشد، اما CPU، حافظه یا I/O را طوری مصرف کند که تجربه‌ی کاربر در برنامه‌ی اصلی خراب شود. در این درس «موفقیت Worker» با «حفاظت از workload اصلی» یکی نیست. خروجی ما یک Node Resource Envelope & Primary Protection Budget v1 است: مجموعه‌ای versioned از حدود و شواهد که مشخص می‌کند Worker چه‌قدر حق مصرف دارد، چه headroomای برای کار اصلی باید باقی بماند، و در فشار چه زمانی باید degrade یا pause شود.
2. مرز مالکیت LOC-014
این درس فقط Resource Envelope و Protected Primary را مالک است. مجوز کنترل Node متعلق به LOC-013 است و power transition متعلق به LOC-015. پس حتی اگر این درس بگوید Worker باید pause شود، درباره‌ی اختیار خاموش‌کردن Node یا grant اپراتور تصمیم نمی‌گیرد. این جداسازی باعث می‌شود هر تصمیم به شواهد خودش قابل ردیابی باشد.
3. Envelope باید versioned و قابل ممیزی باشد
Envelope را با envelope_version، worker_class و window اندازه‌گیری ثبت کنید. CPU، memory، I/O و concurrency باید فیلدهای مستقل داشته باشند. تغییر threshold بدون نسخه‌ی جدید، مقایسه‌ی قبل/بعد را خراب می‌کند. یک تصمیم قابل ممیزی باید بتواند بگوید کدام نسخه از Envelope، در کدام window، با چه telemetryای ارزیابی شده است.
4. CPU weight با CPU hard cap یکی نیست
وزن CPU یک سهم نسبی در رقابت با workloadهای دیگر است؛ hard cap یک سقف زمانی/پهنای‌باند است. در Linux cgroup v2، cpu.max سقف bandwidth را بیان می‌کند. در Windows Job Objects نیز حالت‌های weight-based، hard-cap و min/max semantics متفاوت دارند. اگر عدد «30» را در دو مدل ببینید، نباید فرض کنید اثر اجرایی یکسانی دارد. تصمیم باید cpu_mode و effective control را ثبت کند، نه فقط یک درصد مبهم.
5. memory.low، memory.high و memory.max سه معنا دارند
در cgroup v2، memory.low حفاظت best-effort در برابر reclaim است؛ memory.high ناحیه‌ی فشار و throttling/reclaim را ایجاد می‌کند؛ memory.max hard limit است. عبور از memory.high در حالی که هنوز زیر memory.max هستیم، به‌خودی‌خود «hard-limit failure» نیست؛ اما evidence کافی برای فشار و degrade است. رسیدن یا عبور از hard ceiling باید مسیر شدیدتری مثل pause یا recovery را فعال کند.
6. I/O و concurrency را جداگانه محدود کنید
Worker می‌تواند زیر سقف CPU و memory باشد ولی با I/O burst یا concurrency زیاد، UI یا compile اصلی را کند کند. بنابراین io_weight/io_budget و concurrency_cap باید جدا ثبت شوند. Envelope تک‌عددی قابل دفاع نیست؛ workload چندمنبعی نیاز به کنترل چندبعدی دارد.
7. Protected Primary یک رزرو صریح است
Primary headroom باید measurable باشد: مثلاً حداقل CPU headroom، حداقل memory headroom یا سقف latency تعاملی. هدف این نیست که Worker تا آخرین واحد ظرفیت ماشین پیش برود؛ هدف این است که primary workload حاشیه‌ی امن اعلام‌شده را حفظ کند. اگر Worker هنوز زیر cap خودش است ولی latency اصلی از budget رد شده، protection نقض شده و تصمیم نمی‌تواند RUN باقی بماند.
8. Configured limit با Effective limit فرق دارد
ثبت موفق یک API یا config فقط می‌گوید درخواست تنظیم انجام شده است. باید evidence جداگانه برای effective control داشته باشید: state query، accounting، notification یا telemetry. Windows Job Objects هم resource accounting و limit notifications دارند؛ این یعنی configured constraint و observed behavior را می‌توان و باید جدا نگه داشت. اگر effective state نامشخص است، تصمیم UNKNOWN است نه RUN.
9. Telemetry باید Worker و Primary را با هم ببیند
برای Worker حداقل observed CPU، memory pressure و I/O را ثبت کنید؛ برای primary workload latency و headroom را. فقط نگاه‌کردن به Worker کافی نیست. Protected Primary زمانی اثبات می‌شود که هم حدود Worker رعایت شوند و هم معیار primary در window موردنظر سالم بماند.
10. Degrade قبل از Pause معنا دارد
Soft pressure می‌تواند degrade ایجاد کند: کاهش concurrency، کاهش batch size یا کاهش cadence. اگر فشار پایدار است ولی hard ceiling یا primary protection هنوز نقض نشده، degrade از pause متناسب‌تر است. اما hard-limit breach، شکستن primary headroom یا latency شدید می‌تواند pause را لازم کند. تصمیم باید reason و recheck trigger داشته باشد.
11. یک Decision Table قابل بازتولید بسازید
هر ردیف باید Envelope version، CPU mode/limit، memory boundaries، I/O budget، concurrency، primary headroom، observed values، effective-limit evidence، violation، degrade/pause state و reason را کنار هم نگه دارد. هدف جدول این است که شخص دیگری بدون دانستن reasoning پنهان بتواند همان state را بازسازی کند.
12. Windows و Linux فقط mapping اجرایی هستند
در Linux می‌توانید conceptها را به cgroup v2 map کنید؛ در Windows به Job Objects و CPU rate control. اما thresholdهای MAKNOW از مستندات سیستم‌عامل استخراج نمی‌شوند. OS می‌گوید primitive چه معنایی دارد؛ پروژه تعیین می‌کند برای workload خودش چه headroom و چه degrade/pause policyای مناسب است.
13. مثال کارشده: inference کنار compile
فرض کنید Worker inference روی workstation اجرا می‌شود. Envelope می‌گوید hard CPU cap برابر 35٪، memory.high برابر 6GB، memory.max برابر 8GB، I/O budget برابر 80MB/s و concurrency حداکثر 2 است. Primary latency budget برابر 120ms است. اگر Worker به 6.7GB برسد ولی memory.max را نشکند و latency اصلی 105ms بماند، state DEGRADED است: فشار soft داریم، نه hard failure. اگر latency به 180ms برسد حتی با CPU=30٪، PAUSE لازم است چون Protected Primary نقض شده است.
14. Failure Probeهای تعیین‌کننده
چهار shortcut را رد کنید: (1) عبور از memory.high را با OOM یکی نگیرید؛ (2) رعایت cap خود Worker را معادل سلامت primary ندانید؛ (3) CPU weight را سقف درصدی تفسیر نکنید؛ (4) موفقیت config را معادل effective enforcement ندانید. Lab همین تفاوت‌ها را با fixtureهای deterministic بررسی می‌کند و expected labelها در سطح learner نمایش داده نمی‌شوند.
15. Transfer به لپ‌تاپ کم‌رم
همان Worker را به لپ‌تاپی با RAM کمتر، باتری و latency سخت‌گیرانه‌تر منتقل کنید. ساختار Envelope ثابت می‌ماند اما اعداد باید از نو محاسبه شوند: memory.high/max پایین‌تر، concurrency کمتر، CPU window مناسب‌تر و primary latency budget سخت‌تر. تصمیم baseline را کپی نکنید؛ از evidence جدید state را دوباره بسازید. این انتقال نشان می‌دهد invariant واقعی، «حفاظت قابل اندازه‌گیری از primary» است نه یک عدد ثابت.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
LOC-014-Q1 application
Build a resource envelope for a worker that is below memory.max but above memory.high. What state is justified and what is not yet proven?
LOC-014-Q2 diagnosis
The worker is under its own CPU hard cap, but primary interactive latency exceeds its budget. What should the resource decision do and why?
LOC-014-Q3 decision
A CPU weight value is 3 and observed CPU reaches 55%. Why can the weight not be treated as a 30% hard cap?
LOC-014-Q4 transfer
Rebuild the envelope for a lower-memory laptop with a tighter latency budget; identify which fields remain invariant and which values must be recomputed.
ملاک‌های ارزیابی (rubric)
A sufficient submission must:
- keep relative CPU weight, hard CPU cap, memory pressure, hard memory ceiling, I/O budget, and concurrency as distinct controls;
- keep configured/requested controls separate from effective enforcement evidence;
- preserve the declared primary headroom or latency budget as an independent gate;
- classify soft pressure as DEGRADED when appropriate rather than fabricating a hard-limit failure;
- PAUSE on a hard resource breach or protected-primary breach;
- preserve UNKNOWN when effective enforcement or decisive telemetry is not confirmed;
- recompute the laptop transfer rather than copying workstation thresholds or decisions.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
Implement evaluate(case) in starter.py using only the visible synthetic evidence.
Return these fields: envelope_state, cpu_state, memory_state, io_state, primary_state, effective_state, decision, and reason.
Keep relative CPU weight separate from a hard cap. Keep soft memory pressure separate from the hard memory ceiling. A configured limit is not enough without effective-limit evidence, and worker compliance does not prove that the primary workload is protected.