2025-11-20T20:19:15.373671

CPU-Limits kill Performance: Time to rethink Resource Control

Shetty, Chakraborty, Franke et al.

Research in compute resource management for cloud-native applications is dominated by the problem of setting optimal CPU limits -- a fundamental OS mechanism that strictly restricts a container's CPU usage to its specified CPU-limits . Rightsizing and autoscaling works have innovated on allocation/scaling policies assuming the ubiquity and necessity of CPU-limits . We question this. Practical experiences of cloud users indicate that CPU-limits harms application performance and costs more than it helps. These observations are in contradiction to the conventional wisdom presented in both academic research and industry best practices. We argue that this indiscriminate adoption of CPU-limits is driven by erroneous beliefs that CPU-limits is essential for operational and safety purposes. We provide empirical evidence making a case for eschewing CPU-limits completely from latency-sensitive applications. This prompts a fundamental rethinking of auto-scaling and billing paradigms and opens new research avenues. Finally, we highlight specific scenarios where CPU-limits can be beneficial if used in a well-reasoned way (e.g. background jobs).

academic

CPU-Limits कार्यक्षमता को नष्ट करते हैं: संसाधन नियंत्रण पर पुनर्विचार का समय

मूल जानकारी

पेपर ID: 2510.10747
शीर्षक: CPU-Limits kill Performance: Time to rethink Resource Control
लेखक: Chirag Shetty (UIUC), Sarthak Chakraborty (UIUC), Hubertus Franke (IBM Research), Larisa Shwartz (IBM Research), Chandra Narayanaswami (IBM Research), Indranil Gupta (UIUC), Saurabh Jha (IBM Research)
वर्गीकरण: cs.DC (वितरित कंप्यूटिंग), cs.OS (ऑपरेटिंग सिस्टम), cs.PF (कार्यक्षमता)
प्रकाशन समय: अक्टूबर 2025 (arXiv प्रीप्रिंट)
पेपर लिंक: https://arxiv.org/abs/2510.10747

सारांश

यह पेपर क्लाउड-नेटिव अनुप्रयोगों में कंप्यूटिंग संसाधन प्रबंधन के मूल तंत्र — CPU सीमा (CPU-Limits) — पर मौलिक प्रश्न उठाता है। हालांकि शैक्षणिक अनुसंधान और औद्योगिक अभ्यास आमतौर पर CPU सीमा को आवश्यक मानते हैं, लेखकों ने अनुभवजन्य साक्ष्य के माध्यम से प्रदर्शित किया है कि CPU सीमा वास्तव में अनुप्रयोग कार्यक्षमता को नुकसान पहुंचाती है और लागत बढ़ाती है। पेपर तर्क देता है कि विलंबता-संवेदनशील अनुप्रयोगों को पूरी तरह से CPU सीमा को त्यागना चाहिए, जिसके लिए स्वचालित स्केलिंग और बिलिंग मॉडल में मौलिक पुनर्विचार की आवश्यकता है, साथ ही विशिष्ट परिदृश्यों (जैसे पृष्ठभूमि कार्य) में CPU सीमा के तर्कसंगत उपयोग को इंगित करता है।

अनुसंधान पृष्ठभूमि और प्रेरणा

समस्या परिभाषा

कंटेनरीकृत माइक्रोसर्विसेज़ की CPU संसाधन प्रबंधन क्लाउड कंप्यूटिंग का एक मूल समस्या है। वर्तमान मुख्यधारा का दृष्टिकोण CPU-Limits (c.limit) तंत्र के माध्यम से कंटेनर के CPU उपयोग को सख्ती से सीमित करना है, जो Linux के cpu.cfs_quota_us पर आधारित है। हालांकि, लेखकों ने वास्तविक तैनाती में सिद्धांत और व्यवहार के बीच महत्वपूर्ण विसंगति देखी है।

समस्या की महत्ता

कार्यक्षमता प्रभाव: CPU सीमा के कारण थ्रॉटलिंग से अनुप्रयोग विलंबता में तीव्र गिरावट आती है, जो कैस्केडिंग विफलता को भी ट्रिगर कर सकती है
लागत समस्या: थ्रॉटलिंग से बचने के लिए निर्धारित सुरक्षा मार्जिन 25-45% संसाधन अधिप्रावधान का कारण बनता है
संचालन जटिलता: DevOps कर्मचारियों को कई सूक्ष्म-दानेदार CPU सीमाओं के बीच जटिल व्यापार-बंद करने की आवश्यकता है

मौजूदा विधियों की सीमाएं

मौजूदा स्वचालित स्केलिंग अनुसंधान (जैसे FIRM, Cilantro, Autothrottle आदि) सभी CPU सीमा की आवश्यकता की धारणा पर निर्मित हैं, जो सीमा मानों को अनुकूलित करने पर ध्यान केंद्रित करते हैं न कि तंत्र को चुनौती देने पर। लेखकों ने विश्लेषण के माध्यम से पाया कि ये सभी विधियां CPU सीमा को हटाने के बाद विफल हो जाती हैं।

अनुसंधान प्रेरणा

SRE (साइट विश्वसनीयता इंजीनियरों) के साथ साक्षात्कार और ऑनलाइन चर्चाओं के सर्वेक्षण के माध्यम से, लेखकों ने पाया कि संचालन समुदाय CPU सीमा के बारे में असहमत है। कई व्यावहारिकतावादियों ने पहले से ही कार्यक्षमता में सुधार के लिए CPU सीमा को हटाना शुरू कर दिया है, जो शैक्षणिक समुदाय के मुख्यधारा के दृष्टिकोण के विपरीत है।

मूल योगदान

पारंपरिक विचारों को चुनौती देना: पहली बार विलंबता-संवेदनशील अनुप्रयोगों में CPU सीमा की आवश्यकता पर व्यवस्थित रूप से सवाल उठाना, पर्याप्त अनुभवजन्य साक्ष्य प्रदान करना
कार्यक्षमता विश्लेषण: विलंबता, विश्वसनीयता और लागत पर CPU सीमा के नकारात्मक प्रभाव तंत्र का गहन विश्लेषण
वैकल्पिक समाधान डिजाइन: केवल CPU-Requests (c.req) का उपयोग करके संसाधन प्रबंधन की व्यवहार्यता और लाभ साबित करना
नया प्रतिमान प्रस्ताव: कार्यक्षमता-आधारित बिलिंग मॉडल और असीमित स्वचालित स्केलिंग डिजाइन प्रस्तावित करना
प्रोटोटाइप कार्यान्वयन: YAAS (Yet Another AutoScaler) प्रोटोटाइप का निर्माण, 51% संसाधन बचत प्राप्त करना
अनुप्रयोग परिदृश्य विभाजन: CPU सीमा के तर्कसंगत उपयोग परिदृश्यों को स्पष्ट रूप से परिभाषित करना (जैसे पृष्ठभूमि कार्य, CPU-बाउंड आदि)

विधि विवरण

कार्य परिभाषा

अनुसंधान का लक्ष्य कंटेनर CPU संसाधन प्रबंधन तंत्र को पुनः डिजाइन करना है, CPU सीमा का उपयोग किए बिना, CPU-Requests और नोड उपयोग को अनुकूलित करके बेहतर कार्यक्षमता-लागत व्यापार-बंद प्राप्त करना।

मूल तर्क ढांचा

लेखकों ने एक निर्णय वृक्ष (चित्र 1) का निर्माण किया है जो CPU सीमा के विभिन्न कॉन्फ़िगरेशन परिदृश्यों का व्यवस्थित विश्लेषण करता है:

limit = req: लागत में वृद्धि, 25-45% सुरक्षा मार्जिन की आवश्यकता
limit > req:
- यदि सीमा कभी नहीं छुई जाती, तो अनावश्यक है
- यदि सीमा छुई जा सकती है, तो स्वचालित स्केलिंग कंटेनर को "हैंग" करने या विलंबता में तीव्र गिरावट का कारण बनता है

CPU-Requests पर्याप्तता प्रमाण

लेखकों ने दो स्तरों पर केवल CPU-Requests की पर्याप्तता साबित की है:

CFS शेड्यूलर गारंटी: Linux CFS शेड्यूलर आनुपातिक निष्पक्षता गारंटी प्रदान करता है, यह सुनिश्चित करता है कि CPU-Requests r_i वाला Pod P_i कुल CPU C वाले नोड पर कम से कम (r_i/Σr_j) × C CPU समय प्राप्त करता है।

ऑर्केस्ट्रेटर गेटिंग: Kubernetes जैसे ऑर्केस्ट्रेटर सुनिश्चित करते हैं कि नोड पर सभी कंटेनरों के CPU-Requests का योग नोड क्षमता से अधिक नहीं है, जिससे CPU-Requests एक निरपेक्ष न्यूनतम गारंटी बन जाता है।

YAAS प्रोटोटाइप डिजाइन

YAAS दो मुख्य नियंत्रण चर पर आधारित है:

Overage (U-R): Pod वास्तविक उपयोग और आवंटित मात्रा के बीच अंतर
नोड उपयोग दर (N): Pod के नोड का कुल CPU उपयोग दर

मूल रणनीति:

overage ≥ 0 बनाए रखें, केवल SLO उल्लंघन के निकट होने पर संसाधन बढ़ाएं
Pod माइग्रेशन के माध्यम से नोड उपयोग दर को अनुकूलित करें
ऊर्ध्वाधर और क्षैतिज स्केलिंग को संयोजित करें

प्रयोगात्मक सेटअप

डेटासेट

DeathStarBench से दो माइक्रोसर्विसेज़ अनुप्रयोग का उपयोग:

HotelReservation (HR): होटल बुकिंग सिस्टम
SocialNetwork (SN): सामाजिक नेटवर्क अनुप्रयोग

प्रयोगात्मक वातावरण

मंच: Amazon EC2 क्लस्टर
लोड पैटर्न: परिवर्तनशील अनुरोध लोड, वास्तविक उत्पादन वातावरण का अनुकरण
मूल्यांकन मेट्रिक्स:
- अंत-से-अंत पूंछ विलंबता (P99)
- CPU संसाधन उपयोग
- स्केलिंग संख्या और अभिसरण समय
- लागत दक्षता

तुलना विधियां

पारंपरिक CPU सीमा-आधारित HPA (Horizontal Pod Autoscaler)
मैन्युअल रूप से अनुकूलित CPU सीमा कॉन्फ़िगरेशन
विभिन्न सुरक्षा मार्जिन सेटिंग्स (20%-30%)

प्रयोगात्मक परिणाम

मुख्य परिणाम

विलंबता प्रभाव:

केवल एक Pod (कुल 19 में से) पर CPU सीमा सेट करने से अंत-से-अंत पूंछ विलंबता में 5 गुना गिरावट आती है
CPU सीमा दो तंत्रों के माध्यम से कार्यक्षमता को नुकसान पहुंचाती है: एकल-अनुरोध थ्रॉटलिंग और अनुरोध-पार कतार निर्माण

लागत विश्लेषण:

थ्रॉटलिंग से बचने के लिए 25-45% संसाधन अधिप्रावधान की आवश्यकता है
CPU सीमा को सरलता से हटाने से 38% संसाधन बचत हो सकती है
YAAS आगे 51% संसाधन बचत प्राप्त करता है

स्केलिंग कार्यक्षमता:

25% लोड वृद्धि पर, स्केलिंग थ्रेशोल्ड 60% से 70% तक बढ़ने से SLO पूर्ति समय 4 गुना बढ़ जाता है
CPU सीमा के स्वचालित स्केलिंग संवेदनशीलता पर प्रभाव को प्रदर्शित करता है

विलोपन प्रयोग

सुरक्षा मार्जिन विश्लेषण: विभिन्न अनुप्रयोगों को विभिन्न सुरक्षा मार्जिन की आवश्यकता है:

nginx-thrift: 30%
user-timeline-service: 45%

कतार निर्माण तंत्र: सिद्धांत विश्लेषण और प्रयोगात्मक सत्यापन के माध्यम से यह प्रदर्शित किया गया कि CPU सीमा कम लोड पर कतार कैसे बनाती है, जबकि CPU-Requests ऐसी समस्या नहीं बनाता है।

केस विश्लेषण

बहु-किरायेदार परिदृश्य: प्रयोग दिखाते हैं कि जब दो अनुप्रयोग एक साथ मौजूद हों, तो CPU-Requests conformant अनुप्रयोगों को bursting अनुप्रयोगों से प्रभावी ढंग से सुरक्षित कर सकता है, जबकि CPU सीमा कार्यक्षमता को बदतर बनाता है।

कैस्केडिंग विफलता: CPU सीमा के कारण लंबी कतार Pod मेमोरी को सीमा से अधिक कर सकती है, Pod पुनरारंभ का कारण बन सकती है, जिससे अन्य Pods सीमा तक पहुंचते हैं या अनुरोध समय समाप्त हो जाते हैं।

निष्कर्ष और चर्चा

मुख्य निष्कर्ष

CPU सीमा हानिकारक है: विलंबता-संवेदनशील अनुप्रयोगों के लिए, CPU सीमा या तो हानिकारक है (थ्रॉटलिंग का कारण) या बेकार है (कभी नहीं छुई जाती)
CPU-Requests पर्याप्त है: आधुनिक ऑर्केस्ट्रेटर और शेड्यूलर की गारंटियां CPU-Requests को संसाधन अलगाव के लिए पर्याप्त बनाती हैं
नया डिजाइन स्पेस: CPU सीमा को हटाने से overage और नोड उपयोग दर के आधार पर नए अनुकूलन आयाम खुलते हैं
प्रतिमान परिवर्तन की आवश्यकता: स्वचालित स्केलिंग और बिलिंग मॉडल को पुनः डिजाइन करने की आवश्यकता है

सीमाएं

लागू क्षेत्र: मुख्य रूप से विलंबता-संवेदनशील अनुप्रयोगों के लिए, पृष्ठभूमि कार्य आदि परिदृश्यों में अभी भी CPU सीमा की आवश्यकता है
प्रयोग पैमाना: प्रयोग विशिष्ट माइक्रोसर्विसेज़ बेंचमार्क पर आधारित हैं, व्यापक सत्यापन की आवश्यकता है
उत्पादन तैनाती: प्रोटोटाइप YAAS को उत्पादन वातावरण के लिए उपयोग करने से पहले आगे इंजीनियरिंग की आवश्यकता है
पारिस्थितिकी तंत्र: ऑर्केस्ट्रेटर, निगरानी और बिलिंग सिस्टम के सहयोगी परिवर्तन की आवश्यकता है

भविष्य की दिशाएं

बुद्धिमान शेड्यूलिंग: माइक्रोआर्किटेक्चर संसाधनों (कैश, मेमोरी बैंडविड्थ) के हस्तक्षेप-जागरूक शेड्यूलिंग को संयोजित करना
कार्यक्षमता-आधारित बिलिंग: संसाधन उपयोग के बजाय SLO पूर्ति के आधार पर बिलिंग मॉडल
ऊर्ध्वाधर स्केलिंग: CPU सीमा-मुक्त वातावरण में ऊर्ध्वाधर स्केलिंग अनुकूलन
बहु-आयामी अनुकूलन: Pod स्केलिंग और नोड स्केलिंग का संयुक्त अनुकूलन

गहन मूल्यांकन

शक्तियां

विघ्नकारी दृष्टिकोण: क्षेत्र में मूल मान्यताओं को चुनौती देने का साहस, महत्वपूर्ण शैक्षणिक मूल्य
पर्याप्त अनुभवजन्य साक्ष्य: सिद्धांत विश्लेषण, प्रयोगात्मक सत्यापन और औद्योगिक सर्वेक्षण के माध्यम से बहु-आयामी समर्थन
व्यावहारिक मूल्य: ठोस वैकल्पिक समाधान और प्रोटोटाइप कार्यान्वयन प्रदान करता है, सीधे अनुप्रयोग मूल्य है
व्यवस्थित विश्लेषण: कार्यक्षमता, लागत, विश्वसनीयता आदि कई कोणों से समस्या का व्यापक विश्लेषण
संतुलित दृष्टिकोण: CPU सीमा के दुरुपयोग की आलोचना करता है, साथ ही इसके तर्कसंगत उपयोग परिदृश्यों को इंगित करता है

कमियां

प्रयोग सीमाएं: प्रयोग मुख्य रूप से दो माइक्रोसर्विसेज़ अनुप्रयोगों पर आधारित हैं, अधिक व्यापक अनुप्रयोग प्रकारों का सत्यापन अभाव है
उत्पादन सत्यापन: बड़े पैमाने पर उत्पादन वातावरण के दीर्घकालिक सत्यापन डेटा का अभाव
संगतता: मौजूदा सिस्टम और टूल चेन में परिवर्तन की लागत विश्लेषण अपर्याप्त है
सुरक्षा विचार: CPU सीमा को हटाने से संभावित सुरक्षा जोखिमों पर चर्चा पर्याप्त नहीं है

प्रभाव

शैक्षणिक प्रभाव:

संसाधन प्रबंधन क्षेत्र में प्रतिमान परिवर्तन को ट्रिगर कर सकता है
स्वचालित स्केलिंग अनुसंधान के लिए नई डिजाइन सोच प्रदान करता है
दस से अधिक वर्षों के उद्योग सर्वोत्तम अभ्यास को चुनौती देता है

औद्योगिक प्रभाव:

क्लाउड सेवा प्रदाताओं को लागत अनुकूलन के नए तरीके प्रदान करता है
Kubernetes जैसे ऑर्केस्ट्रेटर के भविष्य डिजाइन को प्रभावित कर सकता है
कार्यक्षमता-आधारित बिलिंग मॉडल नवाचार को बढ़ावा देता है

लागू परिदृश्य

सीधे लागू:

विलंबता-संवेदनशील ऑनलाइन सेवाएं
लागत-संवेदनशील क्लाउड-नेटिव अनुप्रयोग
उच्च कार्यक्षमता गारंटी की आवश्यकता वाली माइक्रोसर्विसेज़ आर्किटेक्चर

सावधानी से आवश्यक:

बहु-किरायेदार वातावरण (अतिरिक्त अलगाव तंत्र की आवश्यकता)
पृष्ठभूमि कार्य युक्त मिश्रित कार्यभार
संसाधन उपयोग पर सख्त अनुपालन आवश्यकताओं वाले परिदृश्य

संदर्भ

पेपर 83 संबंधित संदर्भों का हवाला देता है, जो कंटेनर ऑर्केस्ट्रेशन, संसाधन प्रबंधन, स्वचालित स्केलिंग आदि कई क्षेत्रों के महत्वपूर्ण कार्य को कवर करते हैं। मुख्य संदर्भ साहित्य में शामिल हैं:

Kubernetes आधिकारिक दस्तावेज और सर्वोत्तम अभ्यास
हाल के शीर्ष सम्मेलनों का स्वचालित स्केलिंग अनुसंधान (OSDI, NSDI, EuroSys आदि)
Linux कर्नल CPU शेड्यूलिंग और नियंत्रण समूह संबंधित दस्तावेज
औद्योगिक अभ्यास अनुभव और केस अध्ययन

यह पेपर अपने विघ्नकारी दृष्टिकोण और पर्याप्त अनुभवजन्य विश्लेषण के साथ, क्लाउड-नेटिव संसाधन प्रबंधन क्षेत्र को महत्वपूर्ण चुनौती प्रस्तुत करता है। हालांकि CPU सीमा को पूरी तरह से हटाने के लिए पारिस्थितिकी तंत्र के व्यापक परिवर्तन की आवश्यकता हो सकती है, लेकिन यह प्रदान किए गए अंतर्दृष्टि और वैकल्पिक समाधान इस क्षेत्र के भविष्य विकास के लिए नई दिशा दर्शाते हैं। पेपर का मूल्य केवल तकनीकी योगदान में नहीं है, बल्कि उद्योग की स्थापित मान्यताओं पर गहन प्रतिबिंब में है।