उच्च CPU उपयोग लेकिन कम लोड औसत

Question

हम एक अजीब व्यवहार में भाग रहे हैं जहां हम उच्च सीपीयू उपयोग देखते हैं लेकिन काफी कम लोड औसत।

हमारे निगरानी प्रणाली से निम्नलिखित रेखांकन द्वारा व्यवहार का सबसे अच्छा चित्रण किया गया है।

लगभग 11:57 पर CPU उपयोग 25% से 75% हो जाता है। लोड औसत में काफी बदलाव नहीं हुआ है।

हम 2 हाइपर थ्रेड्स के साथ 12 कोर वाले सर्वर चलाते हैं। ओएस इसे 24 सीपीयू के रूप में देखता है।

CPU उपयोग डेटा /usr/bin/mpstat 60 1प्रत्येक मिनट चलाकर एकत्र किया जाता है । allपंक्ति और %usrस्तंभ का डेटा ऊपर के चार्ट में दिखाया गया है। मैं कुछ इस सीपीयू डेटा प्रति औसत, दिखाता है कर रहा हूँ नहीं "खड़ी" उपयोग। जब हम चार्ट में 75% उपयोग देखते हैं, तो हम एक प्रक्रिया देखते हैं जिसमें लगभग 2000% "स्टैक्ड" सीपीयू का उपयोग होता है top।

लोड औसत आंकड़ा /proc/loadavgप्रत्येक मिनट से लिया जाता है ।

uname -a देता है:

Linux ab04 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

लिनक्स डिस्ट है Red Hat Enterprise Linux Server release 6.3 (Santiago)

हम मशीनों पर काफी भारी भार के तहत जावा वेब अनुप्रयोगों के एक जोड़े को चलाते हैं, प्रति मशीन 100 अनुरोध / एस सोचते हैं।

यदि मैं CPU उपयोग डेटा की सही ढंग से व्याख्या करता हूं, जब हमारे पास 75% CPU उपयोग होता है तो इसका मतलब है कि हमारे CPU औसतन 75% समय में एक प्रक्रिया निष्पादित कर रहे हैं। हालाँकि, यदि हमारा CPU 75% व्यस्त है, तो क्या हमें उच्च लोड औसत नहीं देखना चाहिए? सीपीयू 75% व्यस्त कैसे हो सकता है, जबकि हमारे पास रन कतार में केवल 2-4 नौकरियां हैं?

क्या हम अपने डेटा की सही व्याख्या कर रहे हैं? इस व्यवहार का क्या कारण हो सकता है?

Comments

क्या निगरानी प्रणाली सामान्यीकृत सीपीयू लोड (लोड / # एसीयू) दिखा रही है? नियमित लिनक्स सीपीयू लोड को विभिन्न कोर / सीपीयू के साथ पूरे सिस्टम की तुलना करना कठिन है, इसलिए कुछ उपकरण सामान्यीकृत सीपीयू लोड का उपयोग करते हैं।

— ब्रायन

क्या आप सीपीयू की संख्या के साथ प्रत्येक डेटा बिंदु को विभाजित करने का मतलब है? यानी लोडवाग / 24 हमारे मामले में? मैं आसानी से डेटा से ऐसा चार्ट बना सकता हूं यदि वह मदद करता है।

— के एरलैंडसन

मैं सुझाव दे रहा था कि आपका चार्ट पहले से ही दिख रहा है।

— ब्रायन

आह, आपको गलतफहमी के लिए खेद है। यह एक अच्छा स्पष्टीकरण होता, लेकिन दुर्भाग्य से यह सिस्टम-वाइड लोड औसत है जो दिखाया गया है। मैंने सिर्फ ट्रिपल चेक किया।

— के एरलैंडसन

Answer 1

लिनक्स पर कम से कम, लोड औसत और सीपीयू उपयोग वास्तव में दो अलग-अलग चीजें हैं। लोड औसत एक माप है कि कितने कार्य कर्नेल रन कतार में (न केवल सीपीयू समय बल्कि डिस्क गतिविधि भी) समय की अवधि में प्रतीक्षा कर रहे हैं। सीपीयू उपयोग एक उपाय है कि सीपीयू अभी कितना व्यस्त है। एक मिनट के लिए 100% पर एक एकल सीपीयू थ्रेड जो सबसे अधिक लोड करता है वह "योगदान" कर सकता है 1 मिनट लोड औसत 1 है। 1 मिनट के लिए 100% पर हाइपरथ्रेडिंग (8 आभासी कोर) के साथ एक 4 कोर सीपीयू 8 में योगदान देगा 1 मिनट लोड औसत।

अक्सर कई बार इन दो नंबरों में पैटर्न होते हैं जो एक दूसरे से संबंधित होते हैं, लेकिन आप उन्हें एक जैसा नहीं समझ सकते। आपके पास लगभग 0% CPU उपयोग के साथ एक उच्च भार हो सकता है (जैसे कि जब आपके पास प्रतीक्षा स्थिति में बहुत अधिक IO डेटा अटक जाता है) और आपके पास 1 और 100% CPU का भार हो सकता है, जब आपके पास एक एकल थ्रेडेड प्रक्रिया चल रही हो पूरा झुकाव। साथ ही थोड़े समय के लिए आप सीपीयू को 100% के करीब देख सकते हैं लेकिन लोड अभी भी 1 से नीचे है क्योंकि औसत मैट्रिक्स अभी तक "पकड़ा नहीं" गया है।

मैंने देखा है कि एक सर्वर पर 15,000 से अधिक का लोड होता है (हाँ वास्तव में यह एक टाइपो नहीं है) और 0% के करीब सीपीयू% है। ऐसा इसलिए हुआ क्योंकि सांबा के हिस्से में समस्याएँ थीं और बहुत सारे और बहुत सारे ग्राहक आईओ प्रतीक्षा स्थिति में फंसने लगे थे। संभावना है कि यदि आप बिना किसी सीपीयू गतिविधि के साथ एक नियमित रूप से उच्च लोड संख्या देख रहे हैं, तो आपको किसी प्रकार की भंडारण समस्या हो सकती है। आभासी मशीनों पर इसका मतलब यह भी हो सकता है कि एक ही वीएम होस्ट पर भंडारण संसाधनों के लिए अन्य वीएम भारी प्रतिस्पर्धा कर रहे हैं।

उच्च भार भी आवश्यक रूप से एक बुरी चीज नहीं है, ज्यादातर समय इसका मतलब है कि सिस्टम का उपयोग पूरी क्षमता से किया जा रहा है या शायद यह परे रखने की क्षमता से परे है (यदि लोड संख्या प्रोसेसर कोर की संख्या से अधिक है)। एक ऐसी जगह पर जहाँ मैं एक सिसडमिन हुआ करता था, उनके पास कोई ऐसा व्यक्ति था जो नागों की तुलना में अपने प्राथमिक सिस्टम पर लोड औसत देखता था। जब लोड अधिक था, तो वे मुझे SMTP कह सकते हैं, की तुलना में मुझे 24/7 तेजी से कॉल करेंगे। अधिकांश समय वास्तव में कुछ भी गलत नहीं था, लेकिन उन्होंने लोड संख्या को कुछ गलत होने के साथ जोड़ा और इसे बाज की तरह देखा। जाँच के बाद, मेरी प्रतिक्रिया आम तौर पर यह थी कि सिस्टम बस काम कर रहा था। बेशक यह वही जगह थी जहां 15000 से अधिक लोड हुआ (हालांकि एक ही सर्वर नहीं है) इसलिए कभी-कभी इसका मतलब है कि कुछ गलत है। आपको अपने सिस्टम के उद्देश्य पर विचार करना होगा। यदि यह एक वर्कहॉर्स है, तो लोड स्वाभाविक रूप से उच्च होने की उम्मीद करें।

Comments

आप कैसे मतलब है कि मैं एक पिरोया प्रक्रिया के साथ 1 और 100% CPU का भार हो सकता है? आप किस तरह के धागों की बात कर रहे हैं? यदि हम अपनी जावा प्रक्रियाओं पर विचार करते हैं, तो उनके पास थ्रेड्स होते हैं, लेकिन मैं इस धारणा के तहत था कि थ्रेड्स को ओएस के परिप्रेक्ष्य से प्रक्रियाओं के रूप में माना गया था (उनके पास लिनक्स पर अलग-अलग पीआईडी ​​हैं)। क्या ऐसा हो सकता है कि एक एकल बहु थ्रेडेड जावा प्रक्रिया को केवल लोड एवरेज परिप्रेक्ष्य से एक कार्य के रूप में गिना जाए?

— के एरलैंडसन

मैंने सिर्फ अपने दम पर एक परीक्षण किया था, एक जावा प्रक्रिया में थ्रेड्स लोड औसत में योगदान करते हैं जैसे कि वे जहां अलग-अलग प्रक्रियाएं (यानी एक जावा वर्ग जो एक व्यस्त-प्रतीक्षा लूप में 10 धागे चलाता है, मुझे 10 के करीब लोड देता है)। मैं आपके द्वारा उल्लिखित थ्रेडेड प्रक्रिया के बारे में स्पष्टीकरण की सराहना करूंगा। धन्यवाद!

— के एरलैंडसन

मेरा मतलब है कि यदि आपके पास एक गैर-मल्टीथ्रेडिंग प्रक्रिया है (यानी, एक बार में केवल एक सीपीयू का उपयोग करता है)। उदाहरण के लिए यदि आप सिर्फ एक साधारण सी प्रोग्राम लिखते हैं जो एक व्यस्त लूप चलाता है, तो इसका सिर्फ एक ही धागा चल रहा है और एक समय में केवल 1 सीपीयू का उपयोग करता है।

— प्रात

मुझे मिली सभी जानकारी कहती है कि धागे कर्नेल से देखे जाने पर और लोड की गणना करते समय अलग-अलग प्रक्रियाओं के रूप में गिने जाते हैं। इसलिए मैं यह देखने में विफल हूं कि मैं पूर्ण झुकाव पर एक बहु थ्रेडेड प्रक्रिया कैसे कर सकता था जिसके परिणामस्वरूप एक बहु-सीपीयू प्रणाली पर 1 लोड और 100% सीपीयू था। क्या आप कृपया मुझे यह समझने में मदद कर सकते हैं कि आपका क्या मतलब है?

— के एरलैंडसन

किसी के लिए और अधिक विस्तार की तलाश में: ब्रेंडन ग्रेग द्वारा "लिनक्स लोड एडवर्स: सॉल्विंग द मिस्ट्री" में वे सभी उत्तर थे जिनकी मुझे कभी आवश्यकता थी।

— निकोले

Answer 2

लोड एक बहुत ही भ्रामक संख्या है। नमक के साथ ले।

यदि आप बहुत जल्दी उत्तराधिकार में कई कार्यों को पूरा करते हैं जो बहुत जल्दी पूरा हो जाता है, तो रन क्यू में प्रक्रियाओं की संख्या उनके लिए लोड को दर्ज करने के लिए बहुत कम है (कर्नेल प्रत्येक पांच सेकंड में एक बार लोड की गणना करता है)।

इस उदाहरण पर विचार करें, मेरे मेजबान पर जिसमें 8 तार्किक कोर हैं, यह अजगर स्क्रिप्ट शीर्ष (लगभग 85%) में एक बड़े सीपीयू उपयोग को पंजीकृत करेगा, फिर भी शायद ही कोई भार।

import os, sys

while True:
  for j in range(8):
    parent = os.fork()
    if not parent:
      n = 0
      for i in range(10000):
        n += 1
      sys.exit(0)
  for j in range(8):
    os.wait()

एक और कार्यान्वयन, यह एक wait8 के समूहों में बचा जाता है (जो परीक्षण को तिरछा करेगा)। यहां माता-पिता हमेशा सक्रिय सीपीयू की संख्या पर बच्चों की संख्या को बनाए रखने का प्रयास करते हैं, क्योंकि यह पहली विधि की तुलना में बहुत अधिक व्यस्त होगा और उम्मीद है कि अधिक सटीक होगा।

/* Compile with flags -O0 */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#include <err.h>
#include <errno.h>

#include <sys/signal.h>
#include <sys/types.h>
#include <sys/wait.h>

#define ITERATIONS 50000

int maxchild = 0;
volatile int numspawned = 0;

void childhandle(
    int signal)
{
  int stat;
  /* Handle all exited children, until none are left to handle */
  while (waitpid(-1, &stat, WNOHANG) > 0) {
    numspawned--;
  }
}

/* Stupid task for our children to do */
void do_task(
    void)
{
  int i,j;
  for (i=0; i < ITERATIONS; i++)
    j++;
  exit(0);
}

int main() {
  pid_t pid;

  struct sigaction act;
  sigset_t sigs, old;

  maxchild = sysconf(_SC_NPROCESSORS_ONLN);

  /* Setup child handler */
  memset(&act, 0, sizeof(act));
  act.sa_handler = childhandle;
  if (sigaction(SIGCHLD, &act, NULL) < 0)
    err(EXIT_FAILURE, "sigaction");

  /* Defer the sigchild signal */
  sigemptyset(&sigs);
  sigaddset(&sigs, SIGCHLD);
  if (sigprocmask(SIG_BLOCK, &sigs, &old) < 0)
    err(EXIT_FAILURE, "sigprocmask");

  /* Create processes, where our maxchild value is not met */
  while (1) {
    while (numspawned < maxchild) {
      pid = fork();
      if (pid < 0)
        err(EXIT_FAILURE, "fork");

      else if (pid == 0) /* child process */
        do_task();
      else               /* parent */
        numspawned++;
    }
    /* Atomically unblocks signal, handler then picks it up, reblocks on finish */
    if (sigsuspend(&old) < 0 && errno != EINTR)
      err(EXIT_FAILURE, "sigsuspend");
  }
}

इस व्यवहार का कारण यह है कि एल्गोरिथ्म बाल प्रक्रियाओं को बनाने में अधिक समय व्यतीत करता है, क्योंकि यह वास्तविक कार्य को चलाता है (10000 तक गिनती)। अभी तक बनाए गए कार्य n रननीय ’अवस्था की ओर नहीं आ सकते, फिर भी सीपीयू समय पर% sys लेंगे क्योंकि वे स्पॉन हैं।

तो, जवाब वास्तव में आपके मामले में हो सकता है कि जो भी काम किया जा रहा है वह त्वरित उत्तराधिकार (थ्रेड्स या प्रक्रियाओं) में बड़ी संख्या में कार्यों को जन्म देता है।

Comments

सुझाव के लिए धन्यवाद। मेरे प्रश्न में चार्ट% उपयोगकर्ता समय दिखाता है (CPU सिस्टम समय को बाहर रखा गया है, हम केवल सिस्टम समय में बहुत मामूली वृद्धि देखते हैं)। क्या कई छोटे-छोटे कामों की व्याख्या की जा सकती है? यदि लोड औसत हर 5 सेकंड में सैंपल किया जाता है, तो क्या सीपीयू उपयोग डेटा को एमपीस्टैट द्वारा अधिक बार नमूना लिया जाता है?

— के एरलैंडसन

सीपीयू का नमूना वहां कैसे किया जाता है, मैं इससे परिचित नहीं हूं। इसके बारे में कर्नेल स्रोत को कभी न पढ़ें। मेरे उदाहरण में% usr 70% + और% sys 15% था।

— मैथ्यू इफ

अच्छे उदाहरण!

— ज़ेवियर लुकास

Answer 3

यदि लोड औसत बहुत अधिक नहीं बढ़ता है, तो इसका मतलब है कि आपके हार्डवेयर चश्मा और कार्यों की प्रकृति को एक अच्छे समग्र थ्रूपुट में संसाधित करने का परिणाम है, जिससे उन्हें कुछ समय के लिए कार्य कतार में ढेर किया जा सकता है।

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

अद्यतन करें :

यह मेरे मूल उत्तर में स्पष्ट नहीं हो सकता है, इसलिए मैं अभी स्पष्ट कर रहा हूं:

लोड औसत गणना की सटीक सूत्र है: loadvg = tasks running + tasks waiting (for cores) + tasks blocked।

आप निश्चित रूप से एक अच्छा थ्रूपुट हो सकते हैं और 24 के लोड औसत के करीब हो सकते हैं, लेकिन कार्य प्रसंस्करण समय पर जुर्माना के बिना। दूसरी ओर आप 2-4 आवधिक कार्यों को भी जल्दी पूरा नहीं कर सकते हैं, फिर आपको कार्य की संख्या प्रतीक्षा करते हुए (सीपीयू चक्रों के लिए) बढ़ती हुई दिखाई देगी और आप अंततः एक उच्च भार औसत पर पहुंच जाएंगे। एक और चीज़ जो हो सकती है वह है बकाया सिंक्रोनस I / O संचालन चलाने वाले कार्य, फिर एक कोर को ब्लॉक करना, थ्रूपुट को कम करना और प्रतीक्षा कार्य की कतार को बढ़ाना (उस स्थिति में आप iowaitमीट्रिक को बदलते हुए देख सकते हैं )

Comments

यह मेरी समझ है कि लोड औसत में वर्तमान में निष्पादित कार्य भी शामिल हैं। इसका मतलब है कि हम निश्चित रूप से सीपीयू के लिए वास्तविक विवाद के बिना लोड औसत में वृद्धि कर सकते हैं। या मैं आपसे गलत / गलत समझ रहा हूँ?

— के एरलैंडसन

@ क्रिस्तोफेर आप पूरी तरह से सही हैं। वास्तविक फॉर्मूला लोडवग = टैक रनिंग + कार्य प्रतीक्षा (उपलब्ध कोर के लिए) + कार्य अवरुद्ध है। इसका मतलब है कि आपके पास 24 का लोड औसत हो सकता है, कोई कार्य प्रतीक्षा या अवरुद्ध नहीं हो सकता है, इस प्रकार बिना किसी विवाद के केवल "पूर्ण उपयोग" या आपकी हार्डवेयर क्षमता हो सकती है। जैसा कि आप बनाम CPU उपयोग से चलने वाली प्रक्रियाओं की लोड औसत बनाम संख्या के बारे में उलझन में थे, मैंने मुख्य रूप से स्पष्टीकरण के बारे में अपना जवाब केंद्रित किया कि कैसे लोड औसत अभी भी समग्र रूप से इतनी कम चलने वाली प्रक्रियाओं के साथ बढ़ सकता है। यह फिर से पढ़ने के बाद वास्तव में स्पष्ट नहीं हो सकता है।

— जेवियर लुकास

Answer 4

लोड औसत में ऐसे कार्य शामिल हैं जो डिस्क IO पर अवरुद्ध हैं, इसलिए आप आसानी से शून्य सीपीयू उपयोग और 10 के लोड औसत से 10 कार्य कर सकते हैं जो सभी बहुत धीमी डिस्क से पढ़ने की कोशिश कर रहे हैं। इस प्रकार एक व्यस्त सर्वर के लिए डिस्क को थ्रेश करना शुरू करना आम बात है और सभी बहुत से अवरुद्ध कार्यों का कारण बनता है, लोड औसत को बढ़ाता है, जबकि सीपीयू का उपयोग कम हो जाता है, क्योंकि सभी कार्य डिस्क पर अवरुद्ध हो जाते हैं।

Answer 5

जबकि मैथ्यू इफ का जवाब बहुत मददगार था और हमें सही दिशा में ले गया, यह वास्तव में हमारे मामले में व्यवहार का कारण नहीं था। हमारे मामले में हमारे पास एक बहु थ्रेडेड जावा एप्लिकेशन है जो थ्रेड पूलिंग का उपयोग करता है, वास्तविक कार्य बनाने के लिए कोई काम क्यों नहीं किया जाता है।

हालाँकि, थ्रेड्स का वास्तविक कार्य अल्पकालिक होता है और इसमें IO प्रतीक्षा या सिंक्रोनाइज़ेशन प्रतीक्षा शामिल होती है। जैसा कि मैथ्यू अपने जवाब में उल्लेख करता है, लोड औसत ओएस द्वारा नमूना लिया जाता है, इस प्रकार अल्पकालिक कार्यों को याद किया जा सकता है।

मैंने एक जावा प्रोग्राम बनाया जो व्यवहार को पुन: पेश करता है। निम्न जावा वर्ग हमारे एक सर्वर पर 28% (650% स्टैक्ड) का सीपीयू उपयोग उत्पन्न करता है। इसे करते समय, लोड औसत लगभग 1.3 है। यहां कुंजी थ्रेड के अंदर नींद () है, इसके बिना लोड गणना सही है।

import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class MultiThreadLoad {

    private ThreadPoolExecutor e = new ThreadPoolExecutor(200, 200, 0l, TimeUnit.SECONDS,
            new ArrayBlockingQueue<Runnable>(1000), new ThreadPoolExecutor.CallerRunsPolicy());

    public void load() {
        while (true) {
            e.execute(new Runnable() {

                @Override
                public void run() {
                    sleep100Ms();
                    for (long i = 0; i < 5000000l; i++)
                        ;
                }

                private void sleep100Ms() {
                    try {
                        Thread.sleep(100);
                    } catch (InterruptedException e) {
                        throw new RuntimeException(e);
                    }
                }
            });
        }
    }

    public static void main(String[] args) {
        new MultiThreadLoad().load();
    }

}

संक्षेप में, सिद्धांत यह है कि हमारे अनुप्रयोगों में थ्रेड्स बहुत बेकार हैं और फिर अल्पकालिक काम करते हैं, क्यों कार्यों को लोड औसत गणना द्वारा सही ढंग से नमूना नहीं लिया जाता है।

Answer 6

सीपीयू कतार में लोड औसत प्रक्रियाओं की औसत संख्या है। यह प्रत्येक प्रणाली के लिए विशिष्ट है, आप यह नहीं कह सकते हैं कि एक ला सभी प्रणालियों पर सामान्य रूप से उच्च है, और दूसरा निम्न है। तो आपके पास 12 कोर हैं, और एलए के लिए प्रक्रियाओं को बढ़ाने के लिए प्रक्रियाओं की संख्या वास्तव में अधिक होनी चाहिए।

एक और सवाल "CPU उपयोग" ग्राफ का क्या मतलब है। यदि यह एसएनएमपी से लिया गया है, जैसे यह होना चाहिए, और आपका एसएनएमपी कार्यान्वयन है net-snmp, तो अपने 12 सीपीयू में से प्रत्येक से बस सीपीयू-लोड को ढेर करें। तो net-snmpसीपीयू लोड की कुल राशि के लिए 1200% है।

अगर मेरी धारणा सही है, तो CPU उपयोग में उल्लेखनीय वृद्धि नहीं हुई है। इस प्रकार, LA में उल्लेखनीय वृद्धि नहीं हुई।

Comments

सीपीयू का उपयोग एमपीस्टैट, allपंक्ति से लिया गया है । मुझे पूरा यकीन है कि यह सभी सीपीयू में औसत है, यह स्टैक्ड नहीं है। उदाहरण के लिए, जब समस्या होती है, तो शीर्ष एक प्रक्रिया के लिए 2000% CPU उपयोग दिखाता है। वह ढेर उपयोग है।

— के एरलैंडसन

Answer 7

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

(सामान्य तौर पर आपको केवल सीपीयू की संख्या बंद होने पर लोड के बारे में चिंता करने की आवश्यकता होती है - यानी जब शेड्यूलर पूर्व-खाली कार्य शुरू करता है)।

यदि हमारा CPU 75% समय व्यस्त है, तो क्या हमें उच्च लोड औसत नहीं देखना चाहिए?

गतिविधि के पैटर्न के बारे में इसके सभी, कुछ कार्यों द्वारा स्पष्ट रूप से सीपीयू के उपयोग में वृद्धि हुई है (सबसे अधिक संभावना है कि एक छोटी सी mintority) अन्य कार्यों के प्रसंस्करण पर प्रतिकूल प्रभाव नहीं पड़ रहा है। यदि आप संसाधित किए जा रहे लेन-देन को अलग कर सकते हैं, तो मुझे उम्मीद है कि आप मंदी के दौरान एक नया समूह देखेंगे, जबकि मौजूदा कार्य सेट प्रभावित नहीं था।

अद्यतन करें

एक सामान्य परिदृश्य जहां उच्च सीपीयू भार में बड़ी वृद्धि के बिना हो सकता है, जहां एक कार्य अन्य कार्यों के एक (या अनुक्रम) को ट्रिगर करता है, उदाहरण के लिए नेटवर्क अनुरोध प्राप्त होने पर, हैंडलर एक अलग थ्रेड के लिए अनुरोध करता है, अलग धागा फिर अन्य प्रक्रियाओं के लिए कुछ अतुल्यकालिक कॉल करता है .... रनवे के नमूने के कारण लोड वास्तव में की तुलना में कम रिपोर्ट किया जाता है - लेकिन यह सीपीयू उपयोग के साथ रैखिक रूप से नहीं बढ़ता है - ट्रिगर किए गए कार्यों की श्रृंखला बिना चलने योग्य नहीं होती। प्रारंभिक घटना, और क्योंकि वे होते हैं (अधिक या कम) क्रमिक रूप से रन कतार फुलाया नहीं जाता है।

Comments

ओपी ने मूल रूप से संकेत दिया कि कुल सीपीयू% "2000%" था, यह सुझाव देते हुए कि केवल व्यस्त प्रक्रिया के बजाय सीपीयू का उपयोग करते हुए कई कार्य हैं। यदि यह एक मिनट के लिए लगातार 2000% था तो आप सामान्य रूप से लोड 20-ईश होने का अनुमान लगाएंगे।

— मैथ्यू इफ

... एक टिप्पणी में, सवाल में नहीं, और वह इस बारे में बहुत निश्चित नहीं है। 'ऑल' विकल्प की अनुपस्थिति में, एमपीस्टैट कुल% उपयोग की रिपोर्ट करता है औसत नहीं। लेकिन यह जवाब नहीं बदलता है - यह गतिविधि के पैटर्न के बारे में है।

— सिम्बियन

मैं 100% सकारात्मक हूं कि हम चार्ट में जो CPU उपयोग देखते हैं, वह "औसत प्रति CPU" है। Mpstat सभी के बिना चलाया जाता है, लेकिन यह केवल प्रति-सीपीयू जानकारी को छोड़ देता है, allपंक्ति अभी भी प्रति सीपीयू औसत दिखाती है। मैं प्रश्न स्पष्ट करूंगा।

— के एरलैंडसन

क्या आप कृपया पिछले भाग को थोड़ा विस्तृत कर सकते हैं? मैं समझ नहीं पा रहा हूं कि आपका क्या मतलब है, जबकि मेरे प्रश्न का जो हिस्सा आपने उद्धृत किया है वह वह हिस्सा है जिसे समझने में मुझे सबसे ज्यादा परेशानी होती है।

— के एरलैंडसन