উচ্চ সিপিইউ ব্যবহার কিন্তু কম লোড গড়

Question

আমরা একটি অদ্ভুত আচরণে চলে আসছি যেখানে আমরা উচ্চ সিপিইউ ব্যবহার দেখতে পাই তবে বেশ লোড গড়।

আমাদের মনিটরিং সিস্টেম থেকে নিম্নলিখিত গ্রাফগুলি দ্বারা আচরণটি সর্বোত্তমভাবে ফুটিয়ে তোলা হয়েছে।

প্রায় 11:57 এ সিপিইউ ব্যবহার 25% থেকে 75% এ চলে যায়। লোড গড় উল্লেখযোগ্যভাবে পরিবর্তন করা হয় না।

আমরা প্রতিটি 2 টি হাইপার থ্রেড সহ 12 টি কোর দিয়ে সার্ভারগুলি পরিচালনা করি। ওএস এটিকে 24 সিপিইউ হিসাবে দেখে।

সিপিইউ ব্যবহারের ডেটা /usr/bin/mpstat 60 1প্রতিটি মিনিট চালিয়ে সংগ্রহ করা হয় । allসারি এবং %usrকলামের ডেটা উপরের চার্টে দেখানো হয়েছে। আমি নির্দিষ্ট এই CPU- র তথ্য প্রতি গড়, প্রদর্শন করে থাকি না "স্তুপীকৃত" ব্যবহার। চার্টে আমরা 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 টি অনুরোধ / গুলি ভাবেন think

যদি আমি সিপিইউ ব্যবহারের ডেটা সঠিকভাবে ব্যাখ্যা করি, যখন আমাদের 75% সিপিইউ ব্যবহার হয় তার অর্থ আমাদের সিপিইউগুলি গড়ে 75% সময় একটি প্রক্রিয়া সম্পাদন করে। তবে, যদি আমাদের সিপিইউগুলি 75 75% সময় ব্যস্ত থাকে, তবে কি আমাদের বেশি লোডের গড়টি দেখা উচিত নয়? আমাদের কেবল রান কাতারে 2-4 টি কাজ থাকা অবস্থায় সিপিইউগুলি কীভাবে 75% ব্যস্ত থাকতে পারে?

আমরা কি আমাদের ডেটা সঠিকভাবে ব্যাখ্যা করছি? এই আচরণের কারণ কী হতে পারে?

Comments

মনিটরিং সিস্টেমটি কি সাধারণ সিপিইউ লোড দেখাচ্ছে (লোড / # সিপিইউ)? নিয়মিত লিনাক্স সিপিইউ লোড সিস্টেমের মধ্যে বিভিন্ন কোর / সিপিইউ গণনাগুলির সাথে তুলনা করা শক্ত তাই কিছু সরঞ্জাম পরিবর্তে একটি সাধারণ সিপিইউ লোড ব্যবহার করে।

— ব্রায়ান

আপনার মানে কি প্রতিটি ডাটা পয়েন্ট সিপিইউর সংখ্যার সাথে ভাগ করা? অর্থাৎ আমাদের ক্ষেত্রে লোডভিগ / 24? যদি সহায়তা করে তবে আমি সহজেই ডেটা থেকে এমন একটি চার্ট তৈরি করতে পারি।

— কে এরল্যান্ডসন

আমি প্রস্তাব দিচ্ছিলাম আপনার চার্টটি ইতিমধ্যে এটি প্রদর্শিত হতে পারে।

— ব্রায়ান

আহ, আপনাকে ভুল বোঝার জন্য দুঃখিত। এটি একটি দুর্দান্ত ব্যাখ্যা হতে পারে, তবে দুর্ভাগ্যক্রমে এটি সিস্টেম-প্রশস্ত লোড গড় দেখানো হয়। আমি শুধু ট্রিপল চেক।

— কে এরল্যান্ডসন

Answer 1

লিনাক্সে কমপক্ষে, লোড গড় এবং সিপিইউ ব্যবহার আসলে দুটি ভিন্ন জিনিস। লোড এভারেজ হ'ল একটি সময়কালে কার্নেল রান কাতারে (কেবল সিপিইউ সময় নয় তবে ডিস্ক ক্রিয়াকলাপে) কতগুলি কাজ অপেক্ষা করা হয় তার একটি পরিমাপ। সিপিইউ ব্যবহার এখন সিপিইউ কতটা ব্যস্ত তার একটি পরিমাপ। এক মিনিটের জন্য একক সিপিইউ থ্রেডটি 100% এ যে সর্বাধিক বোঝা ফেলেছে তা 1 মিনিটের লোড গড়কে "অবদান" করতে পারে is 1 মিনিটের লোড গড়।

প্রায়শই এই দুটি সংখ্যার প্যাটার্ন থাকে যা একে অপরের সাথে সম্পর্কিত, তবে আপনি এগুলি একই হিসাবে ভাবতে পারবেন না। আপনার প্রায় 0% সিপিইউ ব্যবহারের সাথে উচ্চ লোড থাকতে পারে (যেমন আপনি যখন ওয়েট স্টেটে প্রচুর আইও ডেটা আটকে থাকেন) এবং আপনার যখন একক থ্রেড প্রক্রিয়া চলছে তখন আপনার 1 এবং 100% সিপিইউ লোড থাকতে পারে পূর্ণ ঢাল. এছাড়াও স্বল্প সময়ের জন্য আপনি সিপিইউ 100% এর কাছাকাছি দেখতে পাবেন কিন্তু লোডটি এখনও 1 এর নীচে রয়েছে কারণ গড় মেট্রিকগুলি এখনও "ধরা পড়ে" নি।

আমি দেখেছি যে একটি সার্ভারে 15,000 এরও বেশি লোড রয়েছে (হ্যাঁ এটি আসলে টাইপোর নয়) এবং 0% এর কাছাকাছি সিপিইউ%। এটি ঘটেছে কারণ একটি সাম্বা শেয়ারের সমস্যা ছিল এবং প্রচুর এবং প্রচুর ক্লায়েন্ট একটি আইও ওয়েট অবস্থায় আটকা শুরু করেছিল। সম্ভাবনাগুলি হ'ল যদি আপনি কোনও নিয়মিত সিপিইউ ক্রিয়াকলাপ সহ নিয়মিত উচ্চ লোড নম্বর দেখছেন, আপনার কোনও ধরণের স্টোরেজ সমস্যা হচ্ছে। ভার্চুয়াল মেশিনে এর অর্থ এইও হতে পারে যে একই ভিএম হোস্টে স্টোরেজ সংস্থানগুলির জন্য প্রচুর পরিমাণে প্রতিযোগিতামূলক অন্যান্য ভিএম রয়েছে।

উচ্চ চাপও অগত্যা কোনও খারাপ জিনিস নয়, বেশিরভাগ সময় এর অর্থ হ'ল সিস্টেমটি তার সম্পূর্ণ ক্ষমতাতে ব্যবহার করা হচ্ছে বা সম্ভবত চালিয়ে যাওয়ার সামর্থ্যের বাইরে (যদি লোডের সংখ্যা প্রসেসরের কোরগুলির সংখ্যার চেয়ে বেশি হয়)। যে জায়গায় আমি সিসাদমিন থাকতাম, তাদের এমন কেউ ছিলেন যারা নাগিওসের চেয়ে কাছাকাছি সময়ে তাদের প্রাথমিক সিস্টেমে লোড গড় দেখেছেন watched যখন লোড বেশি ছিল, তারা আমাকে এসএমটিপি বলতে পারার চেয়ে 24/7 দ্রুত কল করবে। বেশিরভাগ সময় আসলে কিছুই ভুল ছিল না, তবে তারা লোড নম্বরটিকে কিছু ভুল হওয়ার সাথে যুক্ত করেছিল এবং এটিকে বাজপাখির মতো দেখেছিল। চেক করার পরে, আমার প্রতিক্রিয়াটি ছিল সাধারণত সিস্টেমটি এটির কাজ করে। অবশ্যই এটি একই জায়গা যেখানে লোড 15000 এর উপরে উঠেছে (যদিও একই সার্ভারটি নয়) তাই কখনও কখনও এর অর্থ কিছু ভুল হয়। আপনাকে আপনার সিস্টেমের উদ্দেশ্য বিবেচনা করতে হবে। যদি এটি একটি workhorse হয়, তবে বোঝা স্বাভাবিকভাবে বেশি হবে।

Comments

আপনি কীভাবে বোঝাতে চাই যে আমার একক থ্রেডেড প্রক্রিয়া সহ 1 এবং 100% সিপিইউ থাকতে পারে? আপনি কোন ধরণের থ্রেডের কথা বলছেন? যদি আমরা আমাদের জাভা প্রক্রিয়াগুলি বিবেচনা করি, তবে তাদের প্রচুর থ্রেড রয়েছে, তবে আমি এই ধারণার অধীনে ছিলাম যে থ্রেডগুলি ওএসের দৃষ্টিকোণ থেকে প্রক্রিয়া হিসাবে বিবেচিত হয়েছিল (তাদের সর্বোপরি লিনাক্সে পৃথক পিআইডি রয়েছে)। এটি কি এমন হতে পারে যে কোনও একক মাল্টি থ্রেডেড জাভা প্রক্রিয়াটি কোনও লোড গড় দৃষ্টিকোণ থেকে কেবল একটি কাজ হিসাবে গণ্য হয়?

— কে এরল্যান্ডসন

আমি কেবল নিজের মতো করে একটি পরীক্ষা করেছি, জাভা প্রক্রিয়ার থ্রেডগুলি লোড গড়কে অবদান রাখে যেন তারা পৃথক প্রক্রিয়াগুলি (অর্থাত্ একটি জাভা শ্রেণি যা একটি ব্যস্ত-অপেক্ষা লুপে 10 টি থ্রেড চালায় আমাকে 10 এর কাছাকাছি একটি লোড দেয়)। আপনি উপরে উল্লিখিত থ্রেডযুক্ত প্রক্রিয়া সম্পর্কে একটি স্পষ্টতার প্রশংসা করব। ধন্যবাদ!

— কে এরল্যান্ডসন

আমি বোঝাতে চাইছি যদি আপনার একটি নন-মাল্টিথ্রেডিং প্রক্রিয়া থাকে (যেমন, এটি কেবল একবারে একটি সিপিইউ ব্যবহার করে)। উদাহরণস্বরূপ, যদি আপনি কেবল একটি ব্যস্ত লুপ চালিত একটি সাধারণ সি প্রোগ্রাম লিখেন, এটি কেবল একটি একক থ্রেড চলমান এবং একবারে মাত্র 1 সিপিইউ ব্যবহার করে।

— ডেল্টারে

আমি যে সমস্ত তথ্য পেয়েছি তা বলছে যে কার্নেল থেকে দেখা এবং লোড গণনার সময় থ্রেডগুলি পৃথক প্রক্রিয়া হিসাবে গণনা করা হয় count অতএব আমি দেখতে পাই যে আমি কীভাবে সম্পূর্ণ টিলে একাধিক থ্রেড প্রক্রিয়া করতে পারি যার ফলে একটি মাল্টি-সিপিইউ সিস্টেমে 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)। এখনও তৈরি না করা টাস্কগুলি 'রান'যোগ্য' স্টেটের দিকে গণনা করতে পারে না, তবুও সিপিইউয়ের সময় তারা% স্পেস গ্রহণ করবে।

সুতরাং, উত্তরটি সত্যিই আপনার ক্ষেত্রে হতে পারে যে যা কিছু কাজ করা হচ্ছে তা দ্রুত উত্তরাধিকারের (থ্রেড, বা প্রক্রিয়াগুলি) প্রচুর সংখ্যক কাজকে সজ্জিত করে।

Comments

পরামর্শের জন্য তোমাকে ধন্যবাদ। আমার প্রশ্নের চার্টটি% ব্যবহারকারীর সময় দেখায় (সিপিইউ সিস্টেমের সময় বাদ দেওয়া হয়, আমরা কেবলমাত্র সিস্টেমের সময়ের মধ্যে খুব সামান্য বৃদ্ধি দেখতে পাচ্ছি)। অনেকগুলি ছোট কাজই কি ব্যাখ্যা হতে পারে? যদি লোড গড় প্রতি 5 সেকেন্ডে নমুনা হয় তবে এমপিস্ট্যাট দ্বারা প্রদত্ত সিপিইউ ব্যবহারের ডেটা কি আরও ঘন ঘন নমুনা দেওয়া হয়?

— কে এরল্যান্ডসন

সেখানে সিপিইউ স্যাম্পলিং কীভাবে করা হয় তার সাথে আমি পরিচিত নই। এটি সম্পর্কিত কার্নেল উত্সটি পড়বেন না। আমার উদাহরণে% usr ছিল 70% + এবং% sys 15% ছিল।

— ম্যাথু ইফে

ভাল উদাহরণ!

— জাভিয়ের লুকাস

Answer 3

যদি লোড গড় বেশি না বাড়ায় তবে এর অর্থ হ'ল আপনার হার্ডওয়্যার স্পেস এবং প্রসেস করা টাস্কগুলির প্রকৃতি একটি ভাল সামগ্রিক থ্রুপুট ফলস্বরূপ, কিছু সময়ের জন্য টাস্কের কাতারে পাইল করা এড়ানো এড়ানো।

যদি কোনও বিতর্কিত ঘটনা ঘটে থাকে কারণ উদাহরণস্বরূপ গড় টাস্ক জটিলতা খুব বেশি হয় বা টাস্ক এভারেজ প্রসেসিংয়ের সময় অনেক বেশি সিপিইউ চক্র নেয় তবে হ্যাঁ, লোড গড় বৃদ্ধি পাবে।

হালনাগাদ :

এটি আমার মূল উত্তরে পরিষ্কার নাও হতে পারে, তাই আমি এখনই স্পষ্ট করছি:

লোড গড় হিসাব সঠিক সূত্র: loadvg = tasks running + tasks waiting (for cores) + tasks blocked।

আপনি অবশ্যই একটি ভাল থ্রুপুট পেতে পারেন এবং 24 এর লোড গড়ের কাছাকাছি যেতে পারেন তবে কার্য প্রক্রিয়া করার সময় দন্ড ছাড়াই। অন্যদিকে আপনি 2-4 পর্যায়ক্রমিক কাজগুলি পর্যাপ্ত পরিমাণে সম্পূর্ণ না করেও দেখতে পারেন, তারপরে আপনি টাস্কের অপেক্ষার সংখ্যা (সিপিইউ চক্রের জন্য) বাড়তে দেখবেন এবং শেষ পর্যন্ত আপনি উচ্চ লোডের গড়তে পৌঁছবেন। ঘটতে পারে এমন আরেকটি জিনিস হ'ল কাজগুলি অসামান্য সিঙ্ক্রোনাস আই / ও ক্রিয়াকলাপগুলি পরিচালনা করে তারপরে একটি কোরকে অবরুদ্ধ করে, থ্রুপুটটি কমিয়ে ওয়েটিং টাস্কের সারি বাড়িয়ে তোলে (সেই ক্ষেত্রে আপনি iowaitমেট্রিক পরিবর্তন দেখতে পাবেন )

Comments

এটি আমার বোঝার বিষয় যে লোড এভারেজটিতে বর্তমানে সম্পাদন করা কার্যগুলিও অন্তর্ভুক্ত রয়েছে। এর অর্থ হ'ল আমরা অবশ্যই সিপিইউগুলির জন্য প্রকৃত বিবাদ ছাড়াই লোডের গড় বৃদ্ধি পেতে পারি। নাকি আমি আপনাকে ভুল / ভুল বোঝাবুঝি করছি?

— কে এরল্যান্ডসন

আপনি নিখুঁতভাবে ঠিক আছেন আসল সূত্রটি লোডভগ = টাক্স চলমান + টাস্ক অপেক্ষা (উপলব্ধ কোরগুলির জন্য) + টাস্ক অবরুদ্ধ। এর অর্থ হ'ল আপনার গড় লোড গড় 24 থাকতে পারে, কোনও কাজ অপেক্ষায় বা অবরুদ্ধ হতে পারে, এইভাবে কোনও "সম্পূর্ণ ব্যবহার" বা কোনও বিতর্ক ছাড়াই আপনার হার্ডওয়্যার ক্ষমতা রয়েছে। আপনি যেমন সিপিইউ ব্যবহারের তুলনায় লোড গড় বনাম প্রক্রিয়াগুলির সংখ্যা সম্পর্কে বিভ্রান্ত বলে মনে হচ্ছিলেন, আমি মূলত আমার উত্তরটি সামগ্রিকভাবে কয়েকটি চলমান প্রক্রিয়া দিয়ে কীভাবে একটি লোড গড় এখনও বাড়তে পারে সে সম্পর্কে ব্যাখ্যাগুলিতে মনোনিবেশ করেছি। এটি পুনরায় পড়ার পরে এটি স্পষ্টভাবে নাও হতে পারে।

— জাভিয়ের লুকাস

Answer 4

লোড গড়ের মধ্যে ডিস্ক আইওতে অবরুদ্ধ কাজগুলি অন্তর্ভুক্ত থাকে, সুতরাং আপনি খুব ধীর ডিস্ক থেকে পড়ার চেষ্টা করে 10 টি কাজ করে কেবল শূন্য সিপিইউ ব্যবহার এবং 10 এর একটি লোড গড় পেতে পারেন। সুতরাং, ব্যস্ত সার্ভারের জন্য ডিস্কটি ছিন্ন করা আর সমস্ত অনুসন্ধানের ফলে প্রচুর অবরুদ্ধ কার্য হয়, লোড গড় চালিত হয় এবং সিপিইউ ব্যবহার হ্রাস পায়, যেহেতু ডিস্কে সমস্ত কাজ অবরুদ্ধ থাকে।

Answer 5

যদিও ম্যাথিউ ইফের উত্তরটি খুব সহায়ক ছিল এবং আমাদেরকে সঠিক দিকে নিয়ে গেছে, আমাদের ক্ষেত্রে আচরণের কারণটি ঠিক তা নয়। আমাদের ক্ষেত্রে আমাদের কাছে একটি মাল্টি থ্রেডেড জাভা অ্যাপ্লিকেশন রয়েছে যা থ্রেড পুলিং ব্যবহার করে, কেন আসল কাজগুলি তৈরি করে কোনও কাজ করা হয় না।

যাইহোক, থ্রেডগুলি প্রকৃত কাজটি স্বল্পস্থায়ী এবং এতে আইও অপেক্ষা বা সমলয়করণের জন্য অপেক্ষা করে। ম্যাথু তাঁর উত্তরে যেমন উল্লেখ করেছেন, লোড গড় ওএস দ্বারা নমুনাযুক্ত হয়, সুতরাং স্বল্পস্থায়ী কাজগুলি মিস করা যায়।

আমি একটি জাভা প্রোগ্রাম তৈরি করেছিলাম যা আচরণটি পুনরুত্পাদন করে। নিম্নলিখিত জাভা ক্লাসটি আমাদের একটি সার্ভারে একটি সিপিইউ 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 টি কোর রয়েছে এবং এলএর জন্য উল্লেখযোগ্যভাবে বাড়াতে প্রক্রিয়াগুলির সংখ্যা অবশ্যই বেশি হওয়া উচিত।

আরেকটি প্রশ্ন হ'ল "সিপিইউ ব্যবহার" গ্রাফ বলতে কী বোঝায়। যদি এটি এসএনএমপি থেকে নেওয়া হয়, যেমন এটি হওয়া উচিত এবং আপনার এসএনএমপি বাস্তবায়ন হয় net-snmp, তবে কেবল আপনার 12 সিপিইউ থেকে সিপিইউ-লোড স্ট্যাক করে। সুতরাং net-snmpমোট পরিমাণের জন্য সিপিইউ লোড 1200%।

যদি আমার অনুমানগুলি সঠিক হয়, তবে সিপিইউর ব্যবহার উল্লেখযোগ্যভাবে বাড়েনি। সুতরাং, এলএ উল্লেখযোগ্যভাবে বৃদ্ধি পায় নি।

Comments

সিপু ব্যবহারটি এমপিস্ট্যাট, allসারি থেকে নেওয়া হয় । আমি মোটামুটি নিশ্চিত যে এটি সমস্ত সিপিইউ জুড়ে গড়, এটি স্ট্যাক করা হয় না। উদাহরণস্বরূপ, যখন সমস্যা দেখা দেয়, শীর্ষগুলি একটি প্রক্রিয়ার জন্য 2000% সিপিইউ ব্যবহার দেখায়। এটি স্ট্যাকড ব্যবহার।

— কে এরল্যান্ডসন

Answer 7

কিছুটা অস্বাভাবিক হলেও এখানকার দৃশ্যপট বিশেষভাবে অপ্রত্যাশিত নয়। জাভিয়ার যা স্পর্শ করে, কিন্তু তেমন কিছু বিকাশ করে না তা হ'ল যদিও লিনাক্স (ডিফল্টরূপে) এবং ইউনিক্সের বেশিরভাগ স্বাদগুলি একটি স্বাস্থ্যকর মেশিনে প্রাক-এম্পেটিভ মাল্টি-টাস্কিং প্রয়োগ করে, কাজগুলি খুব কমই প্রাক-খালি হয়ে যায়। প্রতিটি কার্য সিপিইউ দখল করার জন্য একটি সময়ের স্লাইস বরাদ্দ করা হয়, এটি কেবল প্রাক-শূন্য করা হয় যদি এটি এই সময়ের চেয়ে বেশি হয়ে যায় এবং অন্যান্য কাজগুলি চালানোর জন্য অপেক্ষা করে থাকে (দ্রষ্টব্য যে লোড সিপিইউতে প্রসেসের গড় সংখ্যা এবং চালনার অপেক্ষায় প্রতিবেদন করে) । বেশিরভাগ সময়, কোনও প্রক্রিয়া বাধাগ্রস্থ হওয়ার চেয়ে ফলন করবে।

(সাধারণভাবে আপনাকে কেবল লোড সম্পর্কে চিন্তিত হওয়া দরকার যখন এটি সিপিইউগুলির সংখ্যার নিকটবর্তী হয় - অর্থাত শিডিয়ুলার প্রাক-খালি কাজগুলি শুরু করে)।

আমাদের সিপিইউগুলি যদি 75% সময় ব্যস্ত থাকে, তবে আমাদের কি উচ্চতর লোড গড় দেখা উচিত নয়?

এগুলি সমস্ত ক্রিয়াকলাপের ধরণ সম্পর্কে, কিছু কাজ দ্বারা স্পষ্টতই সিপিইউর ব্যবহার বৃদ্ধি করা (সম্ভবত একটি ছোট মিন্টোরিটি) অন্যান্য কাজের প্রক্রিয়াজাতকরণে বিরূপ প্রভাব ফেলেনি। যদি আপনি লেনদেনগুলি প্রক্রিয়াজাতকরণকে পৃথক করতে পারতেন তবে আমি আশা করব যে আপনি মন্দার সময় নতুন একটি গ্রুপ উদীয়মান দেখবেন, যখন অতিরিক্ত টাস্ক সেটটি প্রভাবিত হয়নি।

হালনাগাদ

একটি সাধারণ পরিস্থিতি যেখানে লোডের বড় বৃদ্ধি ছাড়াই উচ্চ সিপিইউ দেখা দিতে পারে যেখানে কোনও কাজ অন্য কোনও কাজকে (বা একটি অনুক্রম) ট্রিগার করে, যেমন একটি নেটওয়ার্ক অনুরোধ প্রাপ্তির উপর, হ্যান্ডলারটি অনুরোধটিকে একটি পৃথক থ্রেডে আলাদা করে দেয়, পৃথক থ্রেড তারপরে অন্যান্য প্রক্রিয়াগুলিতে কিছু অ্যাসিনক্রোনাস কল করে .... রান্কিউয়ের নমুনা লোডকে তার চেয়ে কম রিপোর্ট করার কারণ ঘটায় - তবে এটি সিপিইউ ব্যবহারের সাথে রৈখিকভাবে উত্থিত হয় না - ট্রিগার করা কার্যগুলির শৃঙ্খলাটি ছাড়া চালানো যেত না would প্রাথমিক ইভেন্ট, এবং কারণ সেগুলি ঘটে (আরও বা কম) ধারাবাহিকভাবে রান সারিটি স্ফীত হয় না।

Comments

ওপি মূলত এমন ইঙ্গিত দিয়েছিল যে সমষ্টিগত সিপিইউ% "2000%" ছিল যার পরামর্শ দিয়েছিল যে কেবলমাত্র 1 ব্যস্ত প্রক্রিয়া না করে সিপিইউ ব্যবহার করার জন্য অনেকগুলি কাজ রয়েছে। যদি এটি এক মিনিটের জন্য ধারাবাহিক 2000% হয়ে থাকে তবে আপনি সাধারণত লোডটি 20-ইস্হ হওয়ার আশা করতে পারেন।

— ম্যাথু ইফে

... একটি মন্তব্যে, প্রশ্নে নয়, এবং তিনি সে সম্পর্কে খুব নিশ্চিত নন। 'সব' বিকল্পের অভাবে, এমপিস্ট্যাট মোট% ব্যবহারের গড় হিসাবে রিপোর্ট করে না। তবে এটি উত্তর পরিবর্তন করে না - এটি ক্রিয়াকলাপের ধরণ সম্পর্কে।

— সিমকিয়ান

আমি 100% ইতিবাচক যে সিপিইউ ব্যবহারের জন্য আমরা চার্টে দেখি তা হল "গড় প্রতি সিপিইউ"। এমপস্ট্যাট সমস্ত ছাড়াই চালিত হয় তবে এটি প্রতি-সিপিইউ তথ্যটি কেবল বের করে দেয়, allসারিটি এখনও প্রতি সিপিইউতে গড় দেখায়। আমি প্রশ্নটি পরিষ্কার করব।

— কে এরল্যান্ডসন

আপনি কি দয়া করে ইওরুর শেষ অংশটি কিছুটা ব্যাখ্যা করতে পারবেন? আপনি কী বলতে চাইছেন তা আমি বুঝতে ব্যর্থ হলাম, আপনি আমার প্রশ্নের যে অংশটি উদ্ধৃত করেছেন সে অংশটিই আমি বুঝতে সবচেয়ে সমস্যায় পড়েছি।

— কে এরল্যান্ডসন