การใช้งาน CPU สูง แต่ภาระเฉลี่ยต่ำ

เราพบกับพฤติกรรมแปลก ๆ ที่เราเห็นการใช้งาน CPU สูง แต่มีภาระเฉลี่ยค่อนข้างต่ำ

พฤติกรรมดังกล่าวจะแสดงให้เห็นได้ดีที่สุดจากกราฟต่อไปนี้จากระบบตรวจสอบของเรา

เมื่อเวลาประมาณ 11:57 น. การใช้งาน CPU เพิ่มขึ้นจาก 25% เป็น 75% โหลดเฉลี่ยไม่เปลี่ยนแปลงอย่างมีนัยสำคัญ

เราเรียกใช้เซิร์ฟเวอร์ที่มี 12 คอร์ที่มีเธรดไฮเปอร์ 2 ตัว ระบบปฏิบัติการเห็นว่านี่เป็น 24 CPUs

ข้อมูลการใช้งาน CPU จะถูกรวบรวมโดยเรียกใช้/usr/bin/mpstat 60 1ในแต่ละนาที ข้อมูลสำหรับallแถวและ%usrคอลัมน์จะแสดงในแผนภูมิด้านบน ฉันมั่นใจว่านี่จะแสดงค่าเฉลี่ยต่อข้อมูล CPU ไม่ใช่การใช้ "แบบซ้อน" ในขณะที่เราเห็นการใช้ 75% ในรูปที่เราเห็นเป็นกระบวนการที่แสดงจะใช้ประมาณ 2000% "ซ้อน" CPU 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

Linux dist คือ Red Hat Enterprise Linux Server release 6.3 (Santiago)

เราเรียกใช้เว็บแอปพลิเคชัน Java สองสามอันภายใต้ภาระงานที่ค่อนข้างหนักบนเครื่องคิดว่า 100 คำร้องขอต่อวินาที

ถ้าฉันตีความข้อมูลการใช้ CPU อย่างถูกต้องเมื่อเรามีการใช้ประโยชน์ CPU 75% หมายความว่า CPU ของเรากำลังประมวลผลกระบวนการ 75% โดยเฉลี่ย อย่างไรก็ตามหากซีพียูของเราไม่ว่าง 75% ของเวลาเราจะไม่เห็นค่าเฉลี่ยการโหลดที่สูงขึ้นหรือไม่ ซีพียูจะว่าง 75% ในขณะที่เรามีงาน 2-4 งานในคิวการทำงานได้อย่างไร?

เราตีความข้อมูลของเราถูกต้องหรือไม่? สิ่งที่สามารถทำให้เกิดพฤติกรรมนี้

อย่างน้อยบน Linux ค่าเฉลี่ยการโหลดและการใช้งาน CPU นั้นเป็นสองสิ่งที่แตกต่างกัน โหลดเฉลี่ยคือการวัดจำนวนงานที่รออยู่ในคิวรันเคอร์เนล (ไม่ใช่แค่เวลา CPU แต่รวมถึงกิจกรรมของดิสก์) ในช่วงเวลาหนึ่ง การใช้งาน CPU เป็นเครื่องวัดว่า CPU มีงานยุ่งเพียงใดในขณะนี้ โหลดมากที่สุดที่เธรด CPU เดี่ยวที่ตรึงที่ 100% เป็นเวลาหนึ่งนาทีสามารถ "มีส่วนร่วม" กับค่าเฉลี่ยการโหลด 1 นาทีคือ 1 ซีพียู 4 คอร์ที่มีไฮเปอร์เธรด (8 แกนเสมือนจริง) ทั้งหมดที่ 100% เป็นเวลา 1 นาที ค่าเฉลี่ยการโหลด 1 นาที

บ่อยครั้งที่ตัวเลขทั้งสองนี้มีรูปแบบที่สัมพันธ์กัน แต่คุณไม่สามารถคิดได้เหมือนกัน คุณสามารถโหลดสูงด้วยการใช้งาน CPU เกือบ 0% (เช่นเมื่อคุณมีข้อมูล IO จำนวนมากติดอยู่ในสถานะรอ) และคุณสามารถโหลด CPU 1 และ 100% เมื่อคุณมีกระบวนการเธรดเดียวที่ทำงานอยู่ เอียงเต็ม นอกจากนี้ในช่วงเวลาสั้น ๆ คุณสามารถดู CPU ได้ใกล้ 100% แต่การโหลดยังต่ำกว่า 1 เนื่องจากเมตริกโดยเฉลี่ยยังไม่ "ทัน"

ฉันเคยเห็นเซิร์ฟเวอร์มีโหลดมากกว่า 15,000 (ใช่จริง ๆ นั่นไม่ใช่การพิมพ์ผิด) และ CPU% ใกล้เคียงกับ 0% มันเกิดขึ้นเพราะการแชร์แซมบ้ากำลังมีปัญหาและลูกค้าจำนวนมากเริ่มติดอยู่ในสถานะรอ IO โอกาสเกิดขึ้นถ้าคุณเห็นหมายเลขโหลดสูงปกติโดยไม่มีกิจกรรม CPU ที่สอดคล้องกันแสดงว่าคุณกำลังประสบปัญหาหน่วยความจำบางอย่าง บนเครื่องเสมือนนี่อาจหมายถึงว่ามี VM อื่น ๆ ที่แข่งขันกันอย่างหนักสำหรับทรัพยากรหน่วยเก็บข้อมูลบนโฮสต์ VM เดียวกัน

การโหลดสูงนั้นไม่จำเป็นต้องเป็นเรื่องเลวร้ายส่วนใหญ่แล้วมันหมายถึงว่าระบบกำลังถูกใช้งานอย่างเต็มประสิทธิภาพหรืออาจเกินความสามารถในการติดตาม (ถ้าจำนวนโหลดสูงกว่าจำนวนแกนประมวลผล) ในสถานที่ที่ฉันเคยเป็นดูแลระบบพวกเขามีคนที่ดูค่าเฉลี่ยการโหลดบนระบบหลักของพวกเขาใกล้กว่า Nagios เมื่อโหลดสูงพวกเขาจะโทรหาฉันเร็วกว่า 24/7 คุณจะพูดว่า SMTP ส่วนใหญ่ไม่มีอะไรผิดปกติจริง ๆ แต่พวกเขาเชื่อมโยงหมายเลขโหลดกับสิ่งที่ผิดและดูมันเหมือนเหยี่ยว หลังจากการตรวจสอบการตอบสนองของฉันมักจะเป็นที่ระบบเพิ่งจะทำงาน แน่นอนว่านี่เป็นสถานที่เดียวกันที่โหลดเพิ่มขึ้นกว่า 15,000 (ไม่ใช่เซิร์ฟเวอร์เดียวกัน) ดังนั้นบางครั้งมันก็หมายความว่ามีบางอย่างผิดปกติ คุณต้องพิจารณาจุดประสงค์ของระบบของคุณ หากเป็น workhorse ให้คาดหวังว่าภาระจะสูงตามธรรมชาติ

โหลดเป็นจำนวนที่หลอกลวงมาก เอาไปด้วยเม็ดเกลือ

หากคุณวางไข่หลายงานอย่างรวดเร็วอย่างต่อเนื่องซึ่งเสร็จสมบูรณ์อย่างรวดเร็วจำนวนกระบวนการในคิวการทำงานมีขนาดเล็กเกินไปที่จะลงทะเบียนการโหลดสำหรับพวกเขา (เคอร์เนลนับจำนวนการโหลดทุก ๆ ห้าวินาที)

ลองพิจารณาตัวอย่างนี้บนโฮสต์ของฉันที่มีลอจิคัล 8 คอร์สคริปต์ไพ ธ อนนี้จะลงทะเบียนการใช้งาน CPU ขนาดใหญ่ด้านบน (ประมาณ 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()

การใช้งานอื่น ๆ อันนี้หลีกเลี่ยงwaitในกลุ่ม 8 (ซึ่งจะเอียงการทดสอบ) ที่นี่ผู้ปกครองจะพยายามรักษาจำนวนลูกตามจำนวน CPU ที่ใช้งานอยู่เสมอซึ่งจะทำให้ยุ่งกว่าวิธีแรกและหวังว่าจะแม่นยำมากขึ้น

/* 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");
  }
}

สาเหตุของพฤติกรรมนี้คืออัลกอริธึมใช้เวลาสร้างกระบวนการลูกมากกว่าที่จะทำภารกิจจริง (นับเป็น 10,000) งานที่ยังไม่ได้สร้างไม่สามารถนับรวมสู่สถานะ 'runnable' แต่จะใช้เวลา% sys ในเวลา CPU ตามที่วางไข่

ดังนั้นคำตอบอาจเป็นจริงในกรณีของคุณว่าสิ่งใดก็ตามที่ทำงานเสร็จแล้ววางไข่เป็นจำนวนมากในงานอย่างต่อเนื่อง (เธรดหรือกระบวนการ)

หากค่าเฉลี่ยการโหลดไม่เพิ่มขึ้นมากแสดงว่ารายละเอียดฮาร์ดแวร์ของคุณและลักษณะของงานที่ต้องดำเนินการส่งผลให้มีปริมาณงานโดยรวมที่ดีหลีกเลี่ยงการถูกรวบรวมไว้ในคิวงานเป็นระยะเวลาหนึ่ง

หากมีการโต้แย้งปรากฏการณ์เพราะตัวอย่างเช่นความซับซ้อนของงานโดยเฉลี่ยสูงเกินไปหรือเวลาประมวลผลงานเฉลี่ยใช้รอบ CPU มากเกินไปดังนั้นใช่ค่าเฉลี่ยของภาระจะเพิ่มขึ้น

อัปเดต:

มันอาจจะไม่ชัดเจนในคำตอบเดิมของฉันดังนั้นฉันชี้แจงตอนนี้:

loadvg = tasks running + tasks waiting (for cores) + tasks blockedสูตรที่แน่นอนของการคำนวณค่าเฉลี่ยโหลด:

คุณสามารถรับส่งข้อมูลได้ดีและใกล้เคียงกับค่าเฉลี่ยการโหลด 24 แต่ไม่มีค่าปรับในการประมวลผลงาน ในทางกลับกันคุณสามารถมีงานเป็นระยะ ๆ 2-4 งานที่ไม่เสร็จเร็วพอจากนั้นคุณจะเห็นจำนวนงานที่รอ (สำหรับรอบการทำงานของ CPU) เพิ่มขึ้นและในที่สุดคุณจะมีภาระงานเฉลี่ยสูง อีกสิ่งหนึ่งที่สามารถเกิดขึ้นได้คือการมีงานที่ใช้งานการดำเนินการ I / O ซิงโครนัสที่โดดเด่นจากนั้นทำการปิดกั้นคอร์ลดปริมาณงานและทำให้คิวงานที่รอการเติบโต (ในกรณีนี้คุณอาจเห็นการiowaitเปลี่ยนแปลงเมตริก)

ค่าเฉลี่ยการโหลดรวมงานที่ถูกบล็อกบนดิสก์ IO ดังนั้นคุณสามารถมีการใช้งานซีพียูได้อย่างง่ายดายและค่าเฉลี่ยการโหลด 10 เพียงแค่มี 10 งานทั้งหมดพยายามอ่านจากดิสก์ที่ช้ามาก ดังนั้นจึงเป็นเรื่องปกติที่เซิร์ฟเวอร์ไม่ว่างที่จะเริ่มการฟาดดิสก์และการค้นหาทั้งหมดทำให้งานที่ถูกบล็อกจำนวนมากทำให้ค่าเฉลี่ยการโหลดเพิ่มขึ้นขณะที่การใช้ cpu ลดลงเนื่องจากงานทั้งหมดถูกบล็อกบนดิสก์

ในขณะที่คำตอบของ Matthew Ife นั้นมีประโยชน์มากและนำเราไปในทิศทางที่ถูกต้อง แต่นั่นไม่ใช่สิ่งที่ทำให้เกิดพฤติกรรมในกรณีของเรา ในกรณีของเราเรามีแอพพลิเคชั่น Java หลายเธรดที่ใช้การรวมเธรดทำไมงานไม่เสร็จสิ้นการสร้างงานจริง

อย่างไรก็ตามงานจริงที่เธรดทำนั้นมีอายุสั้นและรวมถึงการรอ IO หรือการซิงโครไนซ์รอ ในขณะที่แมทธิวกล่าวถึงคำตอบของเขาค่าเฉลี่ยของโหลดจะถูกสุ่มตัวอย่างโดยระบบปฏิบัติการ

ฉันสร้างโปรแกรม Java ที่สร้างพฤติกรรมขึ้นมาใหม่ คลาส Java ต่อไปนี้สร้างการใช้งาน CPU 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();
    }

}

โดยสรุปทฤษฎีก็คือเธรดในแอปพลิเคชันของเราไม่มีการใช้งานจำนวนมากและทำงานระยะสั้นทำไมงานตัวอย่างจึงไม่ถูกต้องตัวอย่างโดยการคำนวณค่าเฉลี่ยของโหลด

โหลดเฉลี่ยคือจำนวนกระบวนการโดยเฉลี่ยในคิว CPU มันมีความเฉพาะเจาะจงสำหรับแต่ละระบบคุณไม่สามารถพูดได้ว่า LA หนึ่งระบบนั้นสูงในทุกระบบและอีกระบบหนึ่งอยู่ในระดับต่ำ ดังนั้นคุณมี 12 คอร์และสำหรับแอลเอที่จะเพิ่มขึ้นอย่างมีนัยสำคัญจำนวนกระบวนการจะต้องสูงมาก

คำถามอื่นคือกราฟ "การใช้ CPU" มีความหมายอย่างไร ถ้ามันมาจาก SNMP อย่างที่ควรจะเป็นและการใช้ SNMP ของคุณนั้นก็คือnet-snmpเพียงแค่โหลดซีพียูจากซีพียูทั้ง 12 ตัวของคุณ ดังนั้นสำหรับnet-snmpจำนวนโหลด CPU ทั้งหมดคือ 1200%

หากสมมติฐานของฉันถูกต้องแสดงว่าการใช้งาน CPU ไม่เพิ่มขึ้นอย่างมีนัยสำคัญ ดังนั้นหลุยเซียไม่ได้เพิ่มขึ้นอย่างมีนัยสำคัญ

สถานการณ์ที่นี่ไม่ได้คาดหวังเป็นพิเศษแม้ว่ามันจะผิดปกติเล็กน้อย สิ่งที่ซาเวียร์สัมผัสอยู่ แต่ไม่พัฒนามากนักคือแม้ว่า Linux (โดยค่าเริ่มต้น) และรสชาติส่วนใหญ่ของ Unix ใช้มัลติทาสกิ้งแบบ pre-emptive บนเครื่องที่มีสุขภาพดีงานจะไม่ค่อยได้รับการจัดการล่วงหน้า แต่ละงานถูกแบ่งเป็นช่วงเวลาสำหรับการครอบครอง CPU มันจะถูกจองไว้ล่วงหน้าหากเกินเวลานี้และมีงานอื่น ๆ ที่รอการทำงาน (โปรดทราบว่าโหลดรายงานจำนวนเฉลี่ยของกระบวนการทั้งใน CPU และรอการทำงาน) . ส่วนใหญ่แล้วกระบวนการจะให้ผลมากกว่าที่จะถูกขัดจังหวะ

(โดยทั่วไปคุณต้องกังวลเกี่ยวกับโหลดเมื่อจำนวนซีพียูใกล้หมด - เช่นเมื่อตัวกำหนดตารางเวลาเริ่มภารกิจการล้างข้อมูลล่วงหน้า)

หากซีพียูของเราไม่ว่าง 75% ของเวลาเราจะไม่เห็นค่าเฉลี่ยการโหลดที่สูงขึ้นหรือไม่

ทุกอย่างเกี่ยวกับรูปแบบของกิจกรรมเพิ่มการใช้ CPU อย่างชัดเจนโดยงานบางอย่าง (ส่วนใหญ่เป็นเรื่องเล็ก ๆ น้อย ๆ ) ไม่ได้มีผลกระทบต่อการประมวลผลของงานอื่น ๆ หากคุณสามารถแยกธุรกรรมที่กำลังดำเนินการอยู่ฉันคาดว่าคุณจะเห็นกลุ่มใหม่เกิดขึ้นในระหว่างการชะลอตัวในขณะที่ชุดงานที่มีอยู่ไม่ได้รับผลกระทบ

ปรับปรุง

สถานการณ์ทั่วไปหนึ่งที่ CPU สูงสามารถเกิดขึ้นได้โดยไม่ต้องโหลดเพิ่มขึ้นมากคือที่ที่ทริกเกอร์งานหนึ่ง (หรือลำดับ) ของงานอื่น ๆ เช่นเมื่อได้รับคำขอเครือข่ายตัวจัดการกำหนดเส้นทางการร้องขอไปยังเธรดแยกต่างหากเธรดแยก จากนั้นทำการเรียกแบบอะซิงโครนัสไปยังกระบวนการอื่น ๆ ... การสุ่มตัวอย่างของ runqueue ทำให้โหลดรายงานน้อยกว่าที่เป็นจริง - แต่มันไม่ได้เพิ่มขึ้นในเชิงเส้นตรงกับการใช้งาน CPU - ห่วงโซ่ของภารกิจที่ทริกเกอร์จะไม่สามารถทำงานได้ เหตุการณ์เริ่มต้นและเนื่องจากเกิดขึ้น (มากหรือน้อย) ตามลำดับคิวการรันจะไม่ขยายออก