%CPU उपयोग दर एक भ्रम है
(brendanlong.com)- आमतौर पर सर्वर की performance limit का आकलन
topजैसे monitoring tools के % CPU उपयोग दर से किया जाता है, लेकिन वास्तव में यह metric performance को linear तरीके से reflect नहीं करता - Ryzen 9 5900X environment में stress-ng से किए गए test के नतीजों में, 50% उपयोग दर पर भी वास्तविक workload 60~100% तक पहुंच गया, यानी metric और वास्तविकता के बीच बड़ा अंतर था
- इसके मुख्य कारण hyperthreading और turbo boost हैं, जहां logical cores के बीच resource sharing और clock speed में बदलाव metric को विकृत कर देते हैं
- इसलिए साधारण CPU उपयोग दर की जगह, वास्तव में process किए जा सकने वाले workload के benchmark और current throughput की तुलना ज्यादा सटीक संकेतक है
- CPU उपयोग दर को linear रूप से समझने पर performance estimation में बड़ी गलती हो सकती है, इसलिए system planning में benchmark-based approach जरूरी है
सर्वर की CPU उपयोग दर और वास्तविक throughput के बीच असंगति
- सर्वर चलाते समय, बहुत से लोग यह जानना चाहते हैं कि सिस्टम maximum utilization के कितना करीब है
- आमतौर पर
topजैसे monitoring tools के जरिए network, memory, CPU utilization में से सबसे ऊंचे मान को देखा जाता है - लेकिन व्यवहार में CPU utilization का आंकड़ा और process किया जा सकने वाला workload linear रूप से नहीं बढ़ता
टेस्ट environment और तरीका
- Ubuntu desktop + Ryzen 9 5900X (12कोर/24थ्रेड) आधारित experiment
- Precision Boost Overdrive(Turbo) enabled
- stress-ng से अलग-अलग load (1~24 worker, 1~100% utilization) simulate किए गए
- मापे गए metric: सिस्टम द्वारा report की गई CPU utilization और वास्तविक computation amount (Bogo ops)
नतीजों का सार
- सामान्य CPU load: 50% utilization पर वास्तविक 60~65% throughput
- 64-bit integer operations: 50% utilization पर 65~85% throughput
- matrix operations (Matrix math): 50% utilization पर 80~100% throughput
- व्यवहार में, अतिरिक्त worker performance में योगदान न दें तब भी CPU utilization बढ़ता है
कारण विश्लेषण
-
hyperthreading
- 12 physical core + 12 logical core संरचना
- 12 या उससे कम worker physical cores पर सबसे बेहतर तरीके से रखे जाते हैं, लेकिन उससे ज्यादा होने पर logical core sharing से performance घटती है
- खासकर SIMD operations (matrix operations) में shared resources न होने से performance gain संभव नहीं
-
turbo boost
- कम load पर 4.9GHz → full load पर 4.3GHz तक 15% clock reduction
- CPU utilization calculation formula (
= busy cycles / total cycles) में विकृति पैदा होती है- denominator (total cycle count) घटने पर utilization में बढ़ोतरी वास्तविक workload की तुलना में ज्यादा दिखाई देती है
निहितार्थ
- CPU utilization performance का absolute metric नहीं है
- सर्वर capacity planning और performance prediction करते समय:
- 1. benchmark से maximum throughput मापें
- 2. real-time throughput monitor करें
- 3. दोनों की तुलना कर यह तय करें कि सिस्टम performance limit के कितना करीब है
- CPU architecture (AMD vs Intel), hyperthreading efficiency, turbo behavior के अनुसार काफी बड़ा अंतर हो सकता है, इसलिए processor-specific analysis जरूरी है
निष्कर्ष
- CPU utilization सिर्फ busy cycle ratio है, यह वास्तविक processing performance को सटीक रूप से नहीं दिखाता
- efficient utilization की स्थिति में "50% utilization" पर भी सिस्टम पहले से maximum performance के 80~100% स्तर पर हो सकता है
- इसलिए performance monitoring और system planning का केंद्र CPU utilization नहीं, बल्कि benchmark-based workload throughput होना चाहिए
3 टिप्पणियां
वास्तविक HPC कॉन्फ़िगरेशन वातावरण में आमतौर पर hyperthreading बंद करके cluster कॉन्फ़िगर किया जाता है।
Hacker News राय
मुझे नहीं लगता कि CPU utilization झूठ है, क्योंकि यह एक स्पष्ट रूप से परिभाषित मात्रा को मापता है। लेकिन जब लोग इससे capacity model बनाने के लिए extrapolate करते हैं, तब अक्सर वास्तविकता और अपेक्षा में अंतर दिखता है।
Hyperthreading(SMT) और Turbo(क्लॉक स्केलिंग) उन कई variables में से सिर्फ कुछ हैं जो nonlinearity पैदा करते हैं। कोरों के बीच साझा होने वाली memory bandwidth, interconnect capacity, और processor cache जैसे संसाधन भी load बढ़ने पर ‘खत्म’ होने लगते हैं।
सॉफ़्टवेयर स्तर पर भी, जैसे spinlock जैसी घटनाएँ utilization पर nonlinear असर डाल सकती हैं।
ज़्यादातर CPU utilization metrics कई सेकंड से 1 मिनट तक का लंबा average लेते हैं, जबकि latency-sensitive servers की performance के लिए महत्वपूर्ण घटनाएँ दर्जनों से सैकड़ों milliseconds के भीतर होती हैं।
इसलिए multi-second average utilization burst pattern और smooth pattern में फर्क नहीं कर पाता।
लेकिन जो तरीका प्रस्तावित किया गया है—यानी "errors या unacceptable latency आने से पहले server कितना काम कर सकता है, इसका benchmark करना"—वह भी मूल रूप से unstable है।
जिस बिंदु पर server unstable होना शुरू करता है, उसे खोजने की कोशिश में measurements बहुत noisy हो जाते हैं, और queueing theory के हिसाब से भी threshold के पास हर noise amplify हो जाता है।
साथ ही, “server अभी कितना काम कर रहा है” यह भी अक्सर स्थिर रूप से परिभाषित नहीं होता (क्या वह RPS है? हर request की cost अलग है, और IPC भी समय के साथ बदलता है)।
आख़िरकार, load test approach से निकलने वाले confidence interval भी utilization metrics से empirical model बनाने जितने ही अनिश्चित होते हैं। इसकी बुनियादी शर्त यही है कि utilization को सही तरह से मापा जाए।
अगर आपको perf या ftrace चलाना आता है, तो आप कम समय में बहुत detailed processor metrics पा सकते हैं और cache miss, memory access की वजह से होने वाला CPU stall, scheduler effects जैसी कई चीज़ें सीधे देख सकते हैं।
लेकिन ज़्यादातर लोग IPC, cache hit rate जैसे metrics मिलने पर भी नहीं जानते कि उनके साथ करना क्या है।
अंत में, ज़्यादातर लोगों की असली दिलचस्पी latency और utilization में ही होती है।
मोटे तौर पर कहें तो, अधिकतर workloads में CPU utilization 80% पार करने तक latency में कोई बड़ी समस्या नहीं आती।
लेकिन उससे ऊपर utilization जाने पर workload latency पर गंभीर असर शुरू हो जाता है।
latency पर कितना असर पड़ेगा, यह अपने workload को नापे बिना पता नहीं चलता।
latency के प्रति कितनी संवेदनशीलता है, यह organization और goals पर निर्भर करता है, और कभी-कभी throughput optimization ज़्यादा महत्वपूर्ण हो सकता है।
अगर latency और throughput दोनों की चिंता है, तो दोनों को मापिए और उचित trade-off खुद तय कीजिए।
मुझे लगता है कि “काम की मात्रा” की परिभाषा ही हिलती रहती है, यही मुख्य बिंदुओं में से एक है।
उदाहरण के लिए, क्या हम किसी public-facing service में real user requests संभाल रहे हैं, या backend में जमा डेटा को आराम से compute करने वाले AI training workload की बात कर रहे हैं—दोनों बहुत अलग हैं।
मेरा तरीका यह है कि आधुनिक multicore hyperthreaded CPU environment में, जहाँ bursts अक्सर होना तय हैं, CPU utilization 60% हो तो मैं उसे पहले से ‘high load’ server मानता हूँ।
अगर दिन के काफ़ी हिस्से में यह 60% से ऊपर रहता है, तो मुझे लगता है कि काम बाँटना उचित है (मुख्यतः user requests संभालने वाली services के संदर्भ में)।
पहले ऐसे मानदंड cloud autoscaling पर गंभीरता से सोचने की वजह बनते थे।
आजकल 100-core से बड़े servers भी लगभग $30k में मिल जाते हैं, इसलिए स्थिति और जटिल हो गई है।
आज के हिसाब से, मैं थोड़ा overprovisioned real server hardware रखना और ज़रूरत पड़ने पर cloud services (या Kubernetes-आधारित internal cloud) तक expand होने वाला hybrid तरीका पसंद करूँगा।
StackOverflow ने शुरुआती दिनों में dedicated racks और 10Gbps uplink के साथ भारी traffic को बहुत efficiently संभाला था, और आज यह उससे भी आसान है।
निष्कर्षतः, मेरे हिसाब से अगर CPU load 65% पर 30 मिनट से ज़्यादा बना रहे, तो मैं उसे व्यावहारिक रूप से 100% effective usage मानता हूँ और जल्द scaling की ज़रूरत समझता हूँ।
हाल की IEEE Hot Interconnects keynote में Ultra Ethernet की latency tuning case study का भी ज़िक्र था।
2 सेकंड या 5 सेकंड के window में सब कुछ flat दिख सकता है, लेकिन 100ms scale पर देखने पर frame burst साफ़ नज़र आता है।
यानी अगर profiling की measurement window वास्तविक workload से मेल नहीं खाती, तो false negative के कारण ग़लत निष्कर्ष निकल सकते हैं, और इससे समस्या और बढ़ सकती है।
मैं ऊपर कही बात से पूरी तरह सहमत हूँ।
CPU utilization की non-linear प्रकृति की वजह से उसका % वास्तविकता से कटने लगता है।
यानी दावा यह है कि % के रूप में मापा गया CPU utilization ही झूठा है।
अगर दो workloads दोनों 100% CPU usage दिखाते हों, लेकिन उनमें से एक बहुत ज़्यादा power consume करे और CPU temperature भी काफ़ी बढ़ा दे, तो सवाल उठता है कि क्या वास्तव में वही workload ज़्यादा transistor resources इस्तेमाल नहीं कर रहा?
भले ही CPU utilization एक perfect metric नहीं है, फिर भी व्यवहार में यह उपयोगी साबित हुआ है।
साधारण SRE काम के अनुभव में भी, CPU-bound tasks के लिए queueing theory के साथ CPU utilization numbers जोड़कर बड़े events से पहले server sizing किया गया, और ज़्यादा “traditional” approach के बजाय कहीं अधिक conservative %CPU मानदंड अपनाने पर भी परिणाम काफ़ी cost-effective निकले।
असली बात यह है कि अगर कोई metric थोड़ा inaccurate हो लेकिन field में काम आता हो, तो उसके बारे में ज़्यादा चिंता किए बिना उसका उपयोग करना चाहिए।
फिर भी production environment में CPU utilization को 40% से ऊपर न जाने देने की वजह यह थी कि अलग-अलग परिस्थितियों के लिए कुछ headroom बचा रहे।
अफ़सोस की बात है कि लेखक ने “उच्च utilization को queueing theory के आधार पर avoid करना चाहिए” इसके लिए ठोस तर्क पर्याप्त नहीं दिया।
मेरा मानना है कि थोड़ा ढीला-ढाला metric भी अगर व्यवहार में ठीक इस्तेमाल हो जाए तो काफ़ी है।
उदाहरण के लिए, हर host के percentile metric का simple average/max सीधे इस्तेमाल करना हो, या host-level histogram का final aggregation percentile के रूप में करना हो—व्यावहारिक रूप से इनके बीच switch करने से operations पर बहुत बड़ा फर्क नहीं पड़ता, ऐसा मेरा अनुभव है।
कुछ लोग गणितीय शुद्धता को लेकर बहुत सख़्त रहते हैं, लेकिन वास्तविक operations में उसका असर हमेशा बड़ा नहीं होता।
40% तो असल में काफ़ी ढीला-ढाला, यानी बहुत headroom वाला utilization है।
मुझे लगता है कि CPU% और loadavg को साथ देखकर system state को काफ़ी अच्छे से समझा जा सकता है।
अगर loadavg ऊँचा हो लेकिन CPU% कम हो, तो system शायद network या I/O पर अटका हो, या system calls आदि में wait कर रहा हो।
ऐसी स्थिति में सिर्फ CPU% देखने से आप असली bottleneck मिस कर सकते हैं।
मुझे लगता है मैंने बिल्कुल यही बात पहले भी सुनी है।
लेखक ने जो कहा है, वह queueing theory की किताबों में दशकों से दोहराया जाता रहा है, इसलिए यह देखकर अजीब लगा कि इसे जैसे अभी-अभी खोजा गया हो।
Brendan Gregg का "CPU Utilization is Wrong" लेख याद आता है।
उस ब्लॉग का मुख्य बिंदु यह है कि CPU utilization केवल CPU के busy होने की “स्थिति” को मापता है, और कई बार CPU के प्रतीक्षा अवस्था में होने पर भी उसे busy मान लेता है।
वहीं IPC उस busy state के भीतर छिपे वास्तविक उपयोगी काम को समझने का metric है।
अगर कोई और Brendan भी है, तो उम्मीद है वह समझाएगा।
मेरा मानना है कि hyperthreading से मिलने वाली performance को दोगुना नहीं मानना चाहिए।
व्यवहार में, hyperthreading को अच्छी तरह इस्तेमाल करने पर भी अक्सर सिर्फ 15~30% अतिरिक्त performance मिलती है। इसके बदले latency दोगुनी हो सकती है।
core utilization बढ़ने पर clock reduction को भी ज़रूर ध्यान में रखना चाहिए, इसलिए वास्तविक दुनिया में nonlinearity के प्रति हमेशा सतर्क रहना चाहिए।
OS से मिलने वाली जानकारी भर से भी अगर hyperthreading effect और clock reduction को model किया जाए, तो utilization का कहीं अधिक accurate estimate संभव है।
उससे आगे cache/memory bandwidth limits या pipeline stalls जैसी performance degradation को model करना भी मुझे बहुत कठिन नहीं लगता।
बात को जटिल बनाने वाला एक कारण यह है कि hyperthreading efficiency CPU architecture और workload के हिसाब से बहुत अलग-अलग होती है।
उदाहरण के लिए AMD (खासकर नया Zen) implementation, Intel की तुलना में कहीं ज़्यादा independent performance देता है—बशर्ते memory bandwidth bottleneck न हो।
अगर application memory-bound हो, तो hyperthreading से बेहतर scaling देखना आसान होता है।
जिस renderer project पर मैंने पहले काम किया था, वह memory-bound था, और वहाँ सिर्फ hyperthreading से ही 60~70% performance gain मिला था।
मैंने कभी i7-3770K (4C/8T) पर POV-Ray से एक simple benchmark चलाया था।
1 thread → 2 threads पर बिल्कुल दोगुना, 2 → 4 पर भी दोगुना, लेकिन 4 → 8 पर सिर्फ 15% की बढ़त मिली।
अगर कोई अजीब benchmark हो जो जानबूझकर cache miss को बार-बार trigger करे, तो शायद SMT में लगभग दोगुनी performance निकाली जा सकती है, लेकिन उसकी practical relevance संदिग्ध है।
और हाँ, सोच रहा हूँ POV-Ray test फिर से चलाऊँ। बहुत समय हो गया, थोड़ी nostalgia भी है।
लगता है लेखक ने यह समझ लिया कि performance, %CPU utilization के साथ linear रूप से नहीं बढ़ती, और फिर निष्कर्ष निकाला कि %CPU utilization ही “झूठ” है।
hyperthreading या clock throttling न होने पर भी, और Apple silicon जैसे अपेक्षाकृत कम-variables वाले cases में भी, बिल्कुल proportional scaling नहीं मिलती।
जैसे ही कई cores साथ इस्तेमाल होने लगते हैं, data transfer overhead जैसे CPU के बाहर के resource bottlenecks बार-बार समस्या बनते हैं, इसलिए ऐसी स्थिति आम है।
लेखक जिस तरह core शब्द का उपयोग कर रहा है, वह confusing है और standard से अलग है।
वह 5900X को 24-core system कह रहा है, जबकि वास्तव में उसमें 12 physical cores और 24 hyperthreads चलते हैं।
12 physical cores हैं, और बाकी 12 उन्हीं cores से जुड़े threads हैं।
चाहे instruction pipeline के 2 set हों, internal functional units फिर भी shared होते हैं।
कुछ साल पहले, जब मैं अपने छोटे भाई को hyperthreading समझाने की कोशिश कर रहा था, तब एक तुलना सूझी थी जो याद रह गई—यह जैसे दो-परत वाला toilet paper roll हो।
आप 24 को अलग-अलग units की तरह नहीं निकाल सकते, लेकिन 12 वाले सेट को लगभग दोगुना उपयोगी बना सकते हैं।
feedback मिलने के बाद मैंने इसे 12 cores / 24 threads के रूप में ठीक कर दिया।
लेकिन मेरा OS utilization को 24 cores के हिसाब से दिखाता था, इसलिए भ्रम हुआ था।
अगर Intel software-defined cores लेकर आए तो दिलचस्प होगा।
यह hyperthreading का logical उल्टा होगा, जहाँ दो या अधिक cores resources share करके ‘एक बड़ा core’ बन जाएँ।
नीचे patent link देखें।
https://patents.google.com/patent/EP4579444A1/en
अगर SMT pair एक ही तरह के workload चलाएँ, तो internal resources और execution units पर contention के कारण SMT effect कम हो जाता है।
अगर workloads पूरी तरह अलग हों, तो boost उल्टा और बड़ा हो सकता है।
अब modern CPUs में P-core, E-core, turbo/non-turbo जैसे variables भी जुड़ जाते हैं, तो तस्वीर और जटिल हो जाती है।
एक study थी जिसमें कहा गया था कि SMT जोड़ने से performance-per-watt का लाभ turbo जोड़ने से ज़्यादा मिलता है, जो मुझे बहुत रोचक लगा।
यह बात सच में बहुत relatable है।
कभी एक दिन मैंने manager को समझाया कि server CPU 60% तक भर चुका है और अब ज़्यादा headroom नहीं बचा, तो उसने मुझे कुछ अजीब नज़र से देखा।
तब अगर ऐसी कोई व्याख्या होती, तो बहुत काम आती।
अगर साथ में queueing theory भी समझा दें, तो असर और अच्छा होता है।
60% से नीचे queueing delay लगभग नगण्य होता है।
70% पार करते ही delay स्पष्ट महसूस होने लगता है, और 80% से ऊपर तो लगभग दोगुना हो जाता है।
मेरे अनुभव में, मैंने P95 time के आधार पर 65% को target रखा, और यह काफ़ी हद तक theoretical expectation से मेल खाता था।
नतीजतन, “60% usable limit है, 80% से latency explode करती है” एक practical rule बन जाता है।
लेकिन यह workload के अनुसार पूरी तरह बदल सकता है।
खासकर आज के समय में, जब servers में 32-core CPU आम हो रहे हैं, यह और भी सही है।
CPU utilization अक्सर उम्मीद के मुताबिक काम नहीं करता।
इस तरह के लेख से आम तौर पर Linux/Windows पर utilization reporting की चर्चा की उम्मीद होती, लेकिन हक़ीक़त में RAM bottleneck के कारण CPU कई बार खाली प्रतीक्षा में रहता है या downclock हो जाता है।
असल में CPU utilization सिर्फ यही मापता है कि OS (चाहे Windows हो या Linux) हर core को कितना thread time दे रहा है।
लेकिन अगर वह thread
memcpyमें 100% wait कर रहा हो, तब भी utilization दर्ज होगा।hyperthreading का फ़ायदा यह है कि अगर एक thread AVX/vector units में फँसा हो और दूसरा thread simple
memcpy/RAM पर अटका हो, तो दोनों मिलकर अलग-अलग units का उपयोग बढ़ा सकते हैं, जिससे कुल performance और utilization दोनों बढ़ते हैं।निष्कर्ष यह है कि CPU Utilization लंबे समय से सहज रूप से समझना कठिन विषय रहा है, और हर बार इस पर कोई नया नज़रिया सामने आता रहता है।
फिर भी यह हमेशा दिलचस्प विषय है।
असली “झूठ” यह मानना है कि hyperthread core बिल्कुल real core की तरह काम करता है।
20 साल से ज़्यादा समय तक इसे इस्तेमाल करते-करते हम इसकी मूल प्रकृति भूल गए, और बार-बार हैरान होते हैं कि performance measurements अजीब क्यों लगते हैं।
एक और बात यह है कि processor मूल रूप से या तो “चल रहा” होता है (100%) या “इंतज़ार” में होता है (0%)।
उसके बीच में % देना दरअसल सिर्फ किसी समय-अवधि का average है—यह बात फिर से याद आती है।
मैंने पहले ऐसी बातचीत की है।
manager: CPU utilization 100% है, क्या server को बड़े instance पर नहीं ले जाना चाहिए?
मैं: "लेकिन क्या CPU अभी सच में कोई उपयोगी काम कर रहा है?"
आख़िरकार, busy waiting भी CPU utilization में गिना जाता है, इसलिए कई बार वास्तविक उपयोगी काम से असंबंधित होते हुए भी सिर्फ number बढ़ जाता है।
यह सही अभिव्यक्ति है।