Go, कंटेनर, और Linux शेड्यूलर

मूल लेख ↗ Hacker News चर्चा ↗

Containerized Go services अक्सर यह गलत आँकते हैं कि उनके पास वास्तव में कितना CPU है, जिससे Go runtime बहुत अधिक threads spawn कर देता है और Linux के CFS scheduler के तहत गंभीर throttling झेलता है। Commenters CPU quotas बनाम shares की तुलना करते हैं, इस पर बहस करते हैं कि Kubernetes/Docker limits पर निर्भर रहें या application-level tuning पर, और `automaxprocs` तथा cgroup-aware runtimes (जैसे Java और .NET में) को व्यावहारिक fixes के रूप में सुझाते हैं। व्यापक रूप से, यह चर्चा strict CPU limits, बेहतर utilization के लिए overcommit, और बड़े multi-tenant clusters में predictable latency के बीच trade-offs को उजागर करती है।

Go, CFS, और कंटेनर CPU सीमाएँ

  • मुख्य समस्या: Go का runtime दिखाई देने वाले cores से GOMAXPROCS का आकार तय करता है, cgroup CPU quotas को अनदेखा करता है, इसलिए containers में वह अक्सर वास्तविक उपलब्ध CPU समय के लिए बहुत अधिक OS threads spawn करता है।
  • इससे भारी CFS throttling, throughput और latency में गिरावट, और कई वर्षों से देखे जा रहे “wasted cores” व्यवहार पैदा होता है।
  • कुछ लोगों का तर्क है कि मूल बग Linux scheduler में नहीं, बल्कि Go के runtime में है (गलत metric का उपयोग)।

Docker/Kubernetes: quotas बनाम shares और flags

  • Docker में --cpus CFS quota/period से map होता है, cpuset से नहीं, और लगभग idle hosts पर भी hard throttling का कारण बन सकता है।
  • cpu.shares proportional/relative scheduling है, जिसका उपयोग केवल contention के दौरान होता है; quotas (cpu.cfs_quota_us) hard time limits हैं।
  • Kubernetes में: CPU request → shares; CPU limit → quota. कुछ लोग कहते हैं “limits मत सेट करो, केवल requests”; अन्य लोगों के लिए strong isolation के लिए quota आवश्यक है।
  • इस पर असहमति है कि CFS quota वास्तव में कब throttling करता है: कुछ कहते हैं “केवल contention के दौरान”; अन्य लोग docs और experiments का हवाला देते हैं जो दिखाते हैं कि यह एक hard cap है, चाहे जो भी हो।

Workarounds: GOMAXPROCS और cgroup probing

  • लोकप्रिय pattern: GOMAXPROCS को cgroup data से सेट करना (जैसे cpu.cfs_quota_us / cpu.cfs_period_us) या automaxprocs जैसी libraries का उपयोग करना।
  • ऐसा करने के बाद, दोनों स्थितियों — “no limit” और “with quota but no tuning” — की तुलना में latency और throughput में substantial gains की कई रिपोर्टें हैं।
  • अन्य लोग चेतावनी देते हैं कि GOMAXPROCS को quota तक सीमित करना burst handling को नुकसान पहुँचा सकता है और tail latency बढ़ा सकता है; “max parallelism को long-term CPU budget के बराबर नहीं होना चाहिए।”
  • सुझावों में शामिल हैं: GOMAXPROCS inject करने के लिए mutating webhooks, nproc/sched_getaffinity का उपयोग, या container-aware views के लिए /proc को fake करने हेतु lxcfs।

Debate: क्या आपको CPU limits का उपयोग करना चाहिए?

  • एक पक्ष: “CPU limits का उपयोग बंद करें; केवल reservations/requests का उपयोग करें।” तर्क: limits CPU बर्बाद करती हैं, host के idle होने पर भी throttling कराती हैं, और capacity व्यवहार को अप्रत्याशित बनाती हैं।
  • विरोधी पक्ष: limits ज़रूरी हैं ताकि:
    • noisy neighbors critical services को प्रभावित न करें।
    • उस “free burst CPU” पर निर्भर न रहना पड़े जो nodes भरने पर गायब हो सकता है।
    • वास्तविक capacity planning के लिए worst-case conditions का अनुकरण किया जा सके।
  • कई लोग नोट करते हैं कि overcommitment और latency-sensitive बनाम batch workloads को मिलाना स्वभावतः जटिल है; K8s abstractions कम अनुभवी ops teams को भ्रमित कर सकती हैं।

Other runtimes and container awareness

  • Java, .NET, और Rust ने container-aware logic जोड़ा है, cgroup limits का उपयोग करके thread pools, GC threads, आदि का आकार तय करने के लिए।
  • Java का व्यवहार shares से quotas का उपयोग करने तक विकसित हुआ है; ऐसे flags हैं जो नियंत्रित करते हैं कि container quota CPU count को प्रभावित करे या नहीं।
  • कुछ लोग सुझाव देते हैं कि Go पर भी ऐसे ही mechanisms या preloadable shims लागू किए जा सकते हैं।

Containers vs VMs/unikernels for Go

  • बार-बार उठने वाला प्रश्न: क्योंकि Go static binaries बनाता है, containers क्या मूल्य जोड़ते हैं?
  • pro-container बिंदु: standardized packaging, network/FS/process isolation, resource controls, orchestration compatibility (Kubernetes), और आसान CI/CD तथा multi-service setups।
  • skeptics का दृष्टिकोण: single Go services के लिए containers redundant “bloat” हो सकते हैं; Go binaries के साथ unikernels बेहतर fit हो सकते हैं, हालांकि tooling और deployment अभी भी कठिन हैं।
  • सहमति: ecosystem और workflow standardization प्रमुख कारण हैं कि Go apps फिर भी containers में समाप्त होते हैं।

Miscellaneous / unclear points

  • Kubernetes CPU manager policies (static vs none) और उनके visible CPU masks पर प्रभाव की कुछ चर्चा; अलग-अलग setups में behavior अलग होता है।
  • उभरते Linux schedulers (EEVDF) का उल्लेख, लेकिन thread में कोई concrete production experience रिपोर्ट नहीं की गई।
  • कुल मिलाकर, प्रतिभागी सहमत हैं कि language runtimes, CFS, cgroups, और orchestrators का interaction सूक्ष्म है और आसानी से misconfigure हो सकता है।