ในระบบคอมพิวเตอร์UNIX โหลดของระบบคือการวัดปริมาณงานคำนวณที่ระบบคอมพิวเตอร์ดำเนินการโหลดเฉลี่ยแสดงถึงโหลดเฉลี่ยของระบบในช่วงเวลาหนึ่ง โดยทั่วไปจะแสดงในรูปแบบตัวเลขสามตัว ซึ่งแสดงถึงโหลดของระบบในช่วงเวลา 1 นาที 5 นาที และ 15 นาทีที่ผ่านมา

ตัวเลขโหลดของ Unix หมายถึงจำนวนกระบวนการที่กำลังใช้งานหรือรอใช้งานCPUกล่าวคือ จำนวนกระบวนการในคิวพร้อมทำงาน (Ready Queue ) หรือคิวทำงาน (Run Queue ) คอมพิวเตอร์ที่ไม่ได้ใช้งานจะมีตัวเลขโหลดเป็น 0 (กระบวนการที่ไม่ได้ใช้งานจะไม่ถูกนับ) แต่ละกระบวนการที่กำลังทำงานจะเพิ่มตัวเลขโหลดขึ้น 1 แต่ละกระบวนการที่สิ้นสุดการทำงานจะลดตัวเลขโหลดลง 1 ระบบ UNIX ส่วนใหญ่จะนับเฉพาะกระบวนการที่อยู่ในสถานะกำลังทำงาน (ใช้งาน CPU) หรือพร้อมที่จะทำงาน (รอใช้งาน CPU) (สถานะ R) เท่านั้น

นอกจากกระบวนการในสถานะ "R" แล้วLinuxยังรวมถึงกระบวนการในสถานะการนอนหลับที่ไม่สามารถขัดจังหวะได้ (โดยปกติจะรอ การทำงาน ของดิสก์สถานะ "D") ซึ่งอาจนำไปสู่ผลลัพธ์ที่แตกต่างกันอย่างมากหากมีกระบวนการจำนวนมากยังคงถูกบล็อกในI/Oเนื่องจากระบบ I/O ยุ่งหรือหยุดชะงัก^{[ 1 ]}ตัวอย่างเช่น รวมถึงกระบวนการที่ถูกบล็อกเนื่องจาก ความล้มเหลวของเซิร์ฟเวอร์ NFS หรือ สื่อที่ช้าเกินไป(เช่น อุปกรณ์จัดเก็บข้อมูล USB 1.x) สถานการณ์ดังกล่าวอาจส่งผลให้ค่าเฉลี่ยโหลดสูงขึ้น ซึ่งไม่ได้สะท้อนถึงการใช้งาน CPU ที่เพิ่มขึ้นจริง แนวคิดเบื้องหลังการรวมไว้คือ แม้ว่าการรอดิสก์จะไม่เหมือนกับการรอ CPU แต่ก็ยังสะท้อนให้เห็นว่าผู้ใช้ต้องรอนานแค่ไหน

ในระบบ UNIX สมัยใหม่ การจัดการเธรดโดยคำนึงถึงค่าเฉลี่ยโหลดจะแตกต่างกันไป บางระบบถือว่าเธรดเป็นกระบวนการสำหรับการคำนวณค่าเฉลี่ยโหลด: แต่ละเธรดที่รอการทำงานจะเพิ่มโหลด 1 อย่างไรก็ตาม ระบบอื่นๆ โดยเฉพาะระบบที่ใช้เธรดแบบ M:Nจะใช้กลยุทธ์ที่แตกต่างกัน เช่น การนับกระบวนการเพียงครั้งเดียวสำหรับการคำนวณโหลด (โดยไม่คำนึงถึงจำนวนเธรด) หรือการนับเฉพาะเธรดที่ตัวกำหนดตารางเวลาเธรดของผู้ใช้เปิดเผยต่อเคอร์เนล ซึ่งอาจขึ้นอยู่กับระดับการทำงานพร้อมกันที่ตั้งไว้ในกระบวนการ Linux ดูเหมือนจะนับแต่ละเธรดแยกกันโดยเพิ่มโหลด 1 ^{[ 2 ]}

ไม่มีวิธีมาตรฐานในการหาความยาวของคิวรันในระบบที่คล้าย Unix ต่างๆ^{[ a ]}แต่โดยทั่วไปแล้ววิธีหนึ่งที่ใช้กันคือการวิเคราะห์เอาต์พุตของ คำสั่ง psโดยเฉพาะps -ax -o statและนับจำนวนบรรทัดที่ขึ้นต้นด้วย "R" (ซึ่งสอดคล้องกับกระบวนการที่อยู่ในสถานะ "R") หากต้องการ คุณสามารถเพิ่มสถานะรอ "ดิสก์" ที่ไม่สามารถขัดจังหวะได้ ซึ่งมีป้ายกำกับว่า "D" บน Linux และ FreeBSD และ "U" บนmacOS อาจ-Mใช้เพื่อรับข้อมูลต่อเธรดบน Linux และ macOS แต่ไม่ใช่ FreeBSD ซึ่งตัวเลือกจะเป็นแทน-H[ ^{4 ] (}โหลดที่รายงานจะไม่เป็น 0 เนื่องจากpsมีการนับกระบวนการเอง หากต้องการโหลดที่แท้จริง ให้ลบหนึ่งออกจากจำนวนนับ)

โดยเฉพาะบน Linux ไฟล์procfs/proc/statจะมีสองบรรทัดprocs_runningและprocs_blockedซึ่งสอดคล้องกับเอนทิตีการจัดกำหนดการ (กระบวนการ/เธรด) ในสถานะ "R" และ "D" ตามลำดับ สามารถใช้เพื่ออ่านโหลดปัจจุบันแทนpsเช่นเดียวกับก่อนหน้านี้ โหลดที่รายงานจะรวมถึงโปรแกรมที่กำลังอ่านไฟล์ procfs อยู่ ดังนั้นให้ลบหนึ่งออกจากผลรวมเพื่อให้ได้โหลดที่แท้จริง^{[ 5 ]}

การศึกษาเปรียบเทียบดัชนีโหลดต่างๆ ที่ดำเนินการโดย Ferrari et al. รายงานว่าข้อมูลโหลด CPU ที่อิงตามความยาวคิว CPU ทำได้ดีกว่าในการปรับสมดุลโหลดเมื่อเทียบกับการใช้ CPU เหตุผลที่ความยาวคิว CPU ทำได้ดีกว่าอาจเป็นเพราะเมื่อโฮสต์มีโหลดมาก การใช้ CPU มีแนวโน้มที่จะใกล้เคียง 100% และไม่สามารถสะท้อนระดับโหลดที่แท้จริงของการใช้ CPU ได้ ในทางตรงกันข้าม ความยาวคิว CPU สามารถสะท้อนปริมาณโหลดบน CPU ได้โดยตรง ตัวอย่างเช่น ระบบสองระบบ ระบบหนึ่งมี 3 กระบวนการและอีกระบบหนึ่งมี 6 กระบวนการในคิว มีแนวโน้มที่จะมีการใช้ CPU ใกล้เคียง 100% แม้ว่าจะแตกต่างกันอย่างเห็นได้ชัดในแง่ของเวลารอของกระบวนการ^{[ 6 ]}

ระบบ Unix และระบบที่คล้าย Unix ทั้งหมดจะสร้างค่าเมตริก ไร้หน่วย ซึ่งประกอบด้วยตัวเลข "ค่าเฉลี่ยโหลด" สามตัวในเคอร์เนลผู้ใช้สามารถสอบถามผลลัพธ์ปัจจุบันได้ง่ายๆ จากเชลล์ Unixโดยเรียกใช้uptimeคำสั่ง:

$ uptime 14:34:03 up 10:43, 4 users, load average: 0.06, 0.11, 0.09

คำ สั่ง wและtopแสดงตัวเลขค่าเฉลี่ยโหลดสามตัวเดียวกัน เช่นเดียวกับ ยูทิ ลิตี้อินเทอร์เฟซผู้ใช้แบบกราฟิก ต่างๆ อินเทอร์เฟซพื้นฐานคือgetloadavg()ฟังก์ชัน C ที่มีอยู่ในระบบ UNIX ส่วนใหญ่ตั้งแต่ 4.3BSD-Reno ในปี 1990 (แต่ไม่ได้เป็นส่วนหนึ่งของPOSIX ) ^{[ 7 ]}โดยเฉพาะบน Linux เราสามารถอ่าน/proc/loadavgข้อมูลนี้ได้จากไฟล์นี้ ไฟล์นี้ยังให้ข้อมูลทันทีเกี่ยวกับจำนวนกระบวนการในสถานะ "R" จำนวนกระบวนการทั้งหมด และรหัสกระบวนการของกระบวนการที่สร้างขึ้นล่าสุด^{[ 8 ]}

ระบบจะคำนวณค่าเฉลี่ย โหลด โดยใช้ค่าเฉลี่ยเคลื่อนที่แบบถ่วงน้ำหนัก/ลดทอนแบบเอกซ์ โปเนนเชียลของ จำนวนโหลดค่าเฉลี่ยโหลดทั้งสามค่าหมายถึงการทำงานของระบบในช่วง 1, 5 และ 15 นาทีที่ผ่านมา^{[ 9 ]}

ในทางคณิตศาสตร์ ค่าทั้งสามค่านี้เป็นค่าเฉลี่ยของภาระระบบทั้งหมดตั้งแต่ระบบเริ่มทำงาน ค่าเหล่านี้จะลดลงแบบเอกซ์โปเนนเชียล แต่ลดลงด้วยความเร็ว ที่แตกต่างกัน กล่าว คือ ลดลงแบบเอกซ์โปเนนเชียลตาม ค่า eหลังจาก 1, 5 และ 15 นาที ตามลำดับ ดังนั้น ค่าเฉลี่ยภาระใน 1 นาที ประกอบด้วย 63% (หรือแม่นยำกว่านั้นคือ 1 - 1/ e ) ของภาระจากนาทีที่ผ่านมา และ 37% (1/ e ) ของภาระเฉลี่ยตั้งแต่เริ่มทำงาน โดยไม่รวมนาทีที่ผ่านมา สำหรับค่าเฉลี่ยภาระใน 5 และ 15 นาที จะคำนวณอัตราส่วน 63%/37% เดียวกันนี้สำหรับ 5 นาทีและ 15 นาที ตามลำดับ ดังนั้น ในทางเทคนิคแล้ว การกล่าวว่าค่าเฉลี่ยภาระใน 1 นาที รวมเฉพาะกิจกรรม 60 วินาทีที่ผ่านมานั้นไม่ถูกต้อง เพราะมันรวม 37% ของกิจกรรมในอดีต แต่การกล่าวว่าส่วนใหญ่ รวม กิจกรรมในนาทีที่ผ่านมานั้น ถูกต้องกว่า

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

ตัวอย่างเช่น เราสามารถตีความค่าเฉลี่ยโหลด "1.73 0.60 7.98" บนระบบซีพียูเดี่ยวได้ดังนี้:

• ในช่วงนาทีสุดท้าย ระบบเกิดการโอเวอร์โหลดโดยเฉลี่ย 73% (มีกระบวนการที่สามารถทำงานได้ 1.73 กระบวนการ ดังนั้นโดยเฉลี่ยแล้ว 0.73 กระบวนการต้องรอคิวเพื่อใช้ CPU ตัวเดียว)
• ในช่วง 5 นาทีที่ผ่านมา โดยเฉลี่ยแล้ว CPU อยู่ในสถานะไม่ได้ใช้งาน 40% ของเวลาทั้งหมด
• ในช่วง 15 นาทีที่ผ่านมา ระบบมีภาระงานเกินกำลังเฉลี่ย 698% (มีกระบวนการที่สามารถทำงานได้ 7.98 กระบวนการ ซึ่งหมายความว่าโดยเฉลี่ยแล้วมีกระบวนการ 6.98 กระบวนการที่ต้องรอคิวเพื่อใช้ CPU ตัวเดียว)

นี่หมายความว่าระบบนี้สามารถจัดการงานทั้งหมดที่กำหนดไว้สำหรับนาทีสุดท้ายได้ หากมันเร็วกว่านี้ 1.73 เท่า

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

ในระบบ Linux ค่าเฉลี่ยโหลดไม่ได้คำนวณในแต่ละรอบการทำงานของนาฬิกา แต่จะถูกขับเคลื่อนด้วยค่าตัวแปรที่ขึ้นอยู่กับHZการตั้งค่าความถี่และทดสอบในแต่ละรอบการทำงานของนาฬิกา การตั้งค่านี้กำหนดอัตราการทำงานของนาฬิกาเคอร์เนลในหน่วยเฮิรตซ์ (ครั้งต่อวินาที) และค่าเริ่มต้นคือ 100การทำงานของ เคอร์เนลใช้จำนวนรอบการทำงานนี้ในการจับเวลา โดยเฉพาะอย่างยิ่งcalc_load()ฟังก์ชัน (ใน loadavg.h ซึ่งเดิมคือ sched.h) ที่คำนวณค่าเฉลี่ยโหลด จะทำงานทุกๆ รอบการทำงานตามที่กำหนด กล่าวคือ LOAD_FREQ (5*HZ+1)นานกว่านั้นเล็กน้อย5วินาที

extern unsigned long avenrun []; /* โหลดค่าเฉลี่ย */ extern void get_avenrun ( unsigned long * loads , unsigned long offset , int shift );#define FSHIFT 11 /* จำนวนบิตของความแม่นยำ */ #define FIXED_1 (1<<FSHIFT) /* 1.0 ในรูปแบบจุดคงที่ */ #define LOAD_FREQ (5*HZ+1) /* ช่วงเวลา 5 วินาที */ #define EXP_1 1884 /* 1/exp(5sec/1min) ในรูปแบบจุดคงที่ */ #define EXP_5 2014 /* 1/exp(5sec/5min) */ #define EXP_15 2037 /* 1/exp(5sec/15min) *//* a1 = a0 * e + a * (1 - e) */ static inline unsigned long calc_load ( unsigned long load , unsigned long exp , unsigned long active ) { unsigned long newload ;newload = load * exp + active * ( FIXED_1 - exp ); if ( active >= load ) newload += FIXED_1 -1 ;return newload / FIXED_1 ; }extern unsigned long calc_load_n ( unsigned long load , unsigned long exp , unsigned long active , unsigned int n );#define LOAD_INT(x) ((x) >> FSHIFT) #define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)

อาร์เรย์ avenrun ประกอบด้วยค่าเฉลี่ย 1 นาที 5 นาที และ 15 นาทีcalc_load()ฟังก์ชันนี้ให้การอัปเดตค่าเฉลี่ยโหลดที่ถูกต้องสำหรับอัตราการอัปเดตเริ่มต้นของLOAD_FREQ (5*HZ+1). ^{[ 10 ]}มันถูกใช้ใน loadavg.c (เดิมคือ sched.c) ดังนี้: ^{[ 11 ]}

void calc_global_load ( void ) { unsigned long sample_window ; long active , delta ;sample_window = READ_ONCE ( calc_load_update ); if ( time_before ( jiffies , sample_window + 10 )) return ;/*  * พับเดลต้า NO_HZ 'เก่า' เพื่อรวมซีพียู NO_HZ ทั้งหมด */ delta = calc_load_nohz_read (); if ( delta ) atomic_long_add ( delta , & calc_load_tasks );active = atomic_long_read ( & calc_load_tasks ); active = active > 0 ? active * FIXED_1 : 0 ;avenrun [ 0 ] = calc_load ( avenrun [ 0 ], EXP_1 , active ); avenrun [ 1 ] = calc_load ( avenrun [ 1 ], EXP_5 , active ); avenrun [ 2 ] = calc_load ( avenrun [ 2 ], EXP_15 , active );WRITE_ONCE ( calc_load_update , sample_window + LOAD_FREQ );/*  * ในกรณีที่เราใช้ NO_HZ สำหรับช่วง LOAD_FREQ หลายช่วง * ให้ปรับค่าให้ตรงกันทั้งหมด */ calc_global_nohz (); }

โปรดสังเกตการจัดการซีพียู NO_HZ นี้ NO_HZ เป็นโหมดที่ออกแบบมาเพื่อลดจำนวนการขัดจังหวะนาฬิกาการจัดตารางเวลาบนโปรเซสเซอร์ที่ไม่ได้ใช้งาน ซึ่งจะช่วยเพิ่มประสิทธิภาพการใช้พลังงานและลดความผันผวนของนาฬิกา อย่างไรก็ตาม โหมดนี้อาจทำให้โปรเซสเซอร์พลาดรอบการอัปเดต ดังนั้น การนับงานจึงทำโดยใช้การดำเนินการแบบอะตอมิก ฟังก์ชันนี้calc_global_nohzจะจัดการการคำนวณในกรณีที่จำเป็นต้องตามให้ทันหลายรอบ โดยใช้ฟังก์ชันนี้:

/* [1] การประยุกต์ใช้ชุดเรขาคณิต: * n 1 - x^(n+1) * S_n := \Sum x^i = ------------- * i=0 1 - x */ unsigned long calc_load_n ( unsigned long load , unsigned long exp , unsigned long active , unsigned int n ) { return calc_load ( load , fixed_power_int ( exp , FSHIFT , n ), active ); }

ในที่นี้fixed_power_int(ไม่ได้รวมอยู่ในบทความ) เป็นการยกกำลัง exp ด้วยกำลัง n ในเลขคณิตจุดคงที่

การคำนวณค่าเฉลี่ยโหลดแบบ "สุ่มตัวอย่าง" เป็นพฤติกรรมที่ค่อนข้างพบได้ทั่วไปFreeBSDก็เช่นกัน จะรีเฟรชค่าทุกๆ ห้าวินาทีเท่านั้น โดยปกติแล้วช่วงเวลาจะไม่แน่นอน เพื่อไม่ให้รวมกระบวนการที่กำหนดให้ทำงานในเวลาใดเวลาหนึ่ง นี่คือเหตุผลสำหรับ "+1" ในโค้ด Linux ข้างต้น FreeBSD จะใช้ค่าชดเชยแบบสุ่มเทียมที่เพิ่มเข้าไปในช่วงเวลาแทน^{[ 12 ]}

loadavg.hนอกจากนี้ยังกล่าวถึงการใช้บิตเศษส่วน 11 บิตในการคำนวณจุดคงที่ข้างต้นเพื่อป้องกันการลดช่วงเวลา ( LOAD_FREQ) ให้ต่ำลงมาก ตัวอย่างเช่น ช่วงเวลาสองวินาทีจะทำให้ค่า EXP กลายเป็น 1981, 2034 และ 2043 ซึ่งเกือบจะเต็มความแม่นยำที่มีอยู่ (0–2047) ^{[ 10 ]}

Ripke Klaus ได้แสดงให้เห็นในปี 2011 ว่าการปรับค่า "+1" เพียงอย่างเดียวไม่เพียงพอที่จะหลีกเลี่ยง สิ่งผิดปกติ แบบมัวเรจากกระบวนการที่กำหนดไว้เป็นประจำ การทดลองของเขาชี้ให้เห็นว่า 4.61 เป็นค่าที่ดีกว่า: 0.61 ใกล้เคียงกับอัตราส่วนทองคำซึ่งช่วยกระจายจุดตัวอย่างในช่วงเวลาเศษส่วนของวินาที ในขณะเดียวกัน 4.61 ก็ใกล้เคียงกับ60/13ดังนั้นคุณสมบัติของ5 sเป็นเศษส่วนจำนวนเต็มของ60 วินาทีได้รับการรักษาไว้^{[ 13 ] [ 14 ]}การเปลี่ยนแปลงของ Ripke เป็นเรื่องปกติใน เคอร์เนล ระบบ Androidแม้ว่านิพจน์ที่ใช้ ( 4*HZ+61) จะถือว่า HZ เท่ากับ 100 ก็ตาม^{[ 15 ]}60*HZ/13จะเหมาะสมกว่าสำหรับค่า HZ ที่แตกต่างกัน ค่าใหม่จะเป็น: ^{[ 14 ]}

#define LOAD_FREQ (60*HZ/13) /* 60/13 ~ ช่วงเวลา 4.61 วินาที */ #define EXP_1 1896 /* 1/exp(4.61sec/1min) = 1/exp(1/13) ในรูปแบบจุดคงที่ */ #define EXP_5 2017 /* 1/exp(4.61sec/5min) = 1/exp(1/13/5) */ #define EXP_15 2038 /* 1/exp(4.61sec/15min) = 1/exp(1/13/15) */

ดังที่เราได้กล่าวไปแล้ว เคอร์เนลส่วนใหญ่ใช้เลขคณิตแบบจุดคงที่ในการคำนวณค่าเฉลี่ยโหลดเพื่อประสิทธิภาพและความเรียบง่าย อย่างไรก็ตาม วิธีนี้จำกัดอัตราการอัปเดตและความแม่นยำที่ทำได้ เนื่องจากเราได้กำหนดวิธีการรับโหลดแบบทันทีจากพื้นที่ผู้ใช้แล้ว จึงเป็นไปได้ที่จะคำนวณค่าเฉลี่ยโหลดจากพื้นที่ผู้ใช้เช่นกัน โค้ดต่อไปนี้ทำเช่นนั้นในภาษา Python โดยใช้อัตราการรีเฟรช φ ≈ 1.618วินาที ในช่วงเวลาตั้งแต่ 10 วินาทีถึง 1 ชั่วโมง:

#!/usr/bin/env python3เวลานำเข้านำเข้าระบบปฏิบัติการจาก การนำเข้า datetime นำเข้าdatetimeจากmath นำเข้าexp และlogจากdataclasses นำเข้าdataclassLOGSYSPERIODS = [ log ( x ) for x in [ 60 , 300 , 900 ]]อัตราการรีเฟรช= (( 5 ** 0.5 ) + 1 ) / 2 # อัตราส่วนทองคำของริปเก้ช่วงเวลา= [ 10 , 30 , 60 , 120 , 300 , 900 , 1800 , 3600 ]COUNT_DISKWAIT = True # จะรวมการรอดิสก์ในการคำนวณโหลดหรือไม่@dataclassคลาสLoadEntry :เฉลี่ย: ทศนิยมเอ็กซ์พลิ เคชัน : ทศนิยมdef initialize_loads ( now : int | float , lavgs : dict [ int , LoadEntry ]):"""เริ่มต้นค่าเฉลี่ยโหลดโดยใช้การประมาณค่าเชิงเส้นจากค่าเฉลี่ยโหลดของระบบและจำนวนโหลดทันที"""sys = getloadavg ()ความชัน= (( sys [ 0 ] - now ) / 60 , ( sys [ 1 ] - sys [ 0 ]) / 240 , ( sys [ 2 ] - sys [ 1 ]) / 600 )สำหรับช่วงเวลาใน[ 10 , 30 , 60 , 120 , 300 , 900 , 1800 , 3600 ]:exp_factor = exp ( - REFRESH_RATE / period )ถ้าช่วงเวลา< 60 :est_avg = now + slopes [ 0 ] * ( period - 60 )ถ้าช่วงเวลาน้อยกว่า300 :est_avg = sys [ 0 ] + slopes [ 1 ] * ( period - 300 )อื่น:est_avg = sys [ 1 ] + slopes [ 2 ] * ( period - 900 )lavgs [ period ] = LoadEntry ( avg = max ( est_avg , 0 ), exp = exp_factor )def update_loads ( lavgs : dict [ int , LoadEntry ], current_load : int | float ) -> None :สำหรับ_ , รายการในlavgs . items ():entry.avg = entry.avg * entry.exp + current_load * ( 1 - entry.exp )​​​​​​​​ถ้าos.name == " posix " :อูนาเมะ= os ไม่ทราบชื่อ()[ 0 ] . ต่ำกว่า()getloadavg = os.getloadavg​​ถ้าuname == "linux" :def get_current_load () -> int :โหลด= 0with open ( "/proc/stat" , "r" ) as f :สำหรับบรรทัดในf :ถ้าบรรทัดเริ่มต้นด้วย"procs_running" :load += int ( line . split ()[ 1 ]) # อ่าน procs_runningโหลด-= 1 # ลบหนึ่งสำหรับตัวเราเองelif line.startswith ( " procs_blocked " ) and COUNT_DISKWAIT :load += int ( line . split ()[ 1 ]) # อ่าน procs_blockedโหลดกลับอื่น:PS_THREAD_OPTION = "-H" ถ้าos.uname ()[ 0 ] .lower () . endswith ( "bsd" ) มิเช่นนั้นจะเป็น" -M "PS_DISK_WAIT = "U" ถ้าos.uname ()[ 0 ] == "Darwin" มิเช่นนั้นจะเป็น" D"PS_STATES = ( "R" + PS_DISK_WAIT ) ถ้าCOUNT_DISKWAIT เป็นจริง มิฉะนั้นจะเป็น"R"def get_current_load () -> int :with os.popen ( f " ps { PS_THREAD_OPTION } ax -o stat" , " r" ) as f :states = map ( f , lambda line : line . split ()[ - 1 ]) # ดึงคอลัมน์สุดท้าย จำเป็นบน macOS!คืนค่าผลรวม( 1 ถ้าstate [ 0 ] อยู่ในPS_STATES มิฉะนั้น0 สำหรับstate ในstates ) - 1elif os.name == " nt " :# สามารถใช้ตัวนับประสิทธิภาพของ Windows เพื่อหาความยาวของคิวได้# อันที่จริง ไมโครซอฟต์แนะนำให้ใช้เป็นตัวชี้วัดเพิ่มเติมสำหรับการวัดภาระงาน นอกเหนือจากการใช้งาน CPU:# https://learn.microsoft.com/en-us/biztalk/technical-guides/using-the-performance-analysis-of-logs-pal-tool#processor-queue-length-analysis# การใช้มันทำให้เราได้โหลดที่คล้ายกับระบบ Unix ได้เช่นกันจากpyperfmon นำเข้าpyperfmonpm = pyperfmon.pyperfmon ( )​ncores = os.cpu_count ( )​get_counter = lambda x : pm . getCounter ( x )def get_current_load () -> float :กลับ(# เธรดที่รอการใช้งาน CPU ไม่ใช่เธรดที่กำลังทำงานget_counter ( r "ความยาวคิวของระบบ\โปรเซสเซอร์" )# จำนวนเธรดโดยประมาณที่ใช้ CPU+ get_counter ( r "Processor\_Total\% Processor Time" ) * ncores# เธรดที่รอการอ่าน/เขียนข้อมูลจากดิสก์+ get_counter ( r "PhysicalDisk\_Total\Current Disk Queue Length" )ถ้าCOUNT_DISKWAITมิฉะนั้น0)def getloadavg () -> tuple [ float , float , float ]:# ตัวอย่างการใช้งานสำหรับ Windowsโหลด= รับโหลดปัจจุบัน()ส่งคืน( โหลด, โหลด, โหลด)def main ():lavgs : dict [ int , LoadEntry ] = {}โหลดปัจจุบัน= รับโหลดปัจจุบัน()initialize_loads ( current_load , lavgs )heading = [ "SYSTIME" , " CURR" ] + [ str ( x ) for x in PERIODS ]พิมพ์( " \t " . join ( heading ))ในขณะที่เป็นจริง:# พิมพ์ผลลัพธ์ก่อนคำนวณใหม่เสมอรายการ= [ f " { datetime . now () . strftime ( '%H:%M:%S' ) } { current_load : .4f } " ]entries += [ f " { entry . avg : .4f } " for entry in lavgs . values ​​()]พิมพ์( " \t " . join ( entries ), flush = True )# นอนหลับและรอ โดยสมมติว่าเวลาที่ใช้ในการอัปเดตบรรทัดใหม่คือ# น้อยมากเมื่อเทียบกับเวลาที่นอนหลับ หากไม่ใช่เช่นนั้น...# ควรใช้การคำนวณแบบ sleepuntil()เวลา. นอนหลับ( อัตราการรีเฟรช)# พิมพ์โหลดปัจจุบัน= รับโหลดปัจจุบัน()อัปเดตโหลด( lavgs , โหลดปัจจุบัน)ถ้า__name__ == "__main__" :หลัก()

คำสั่งอื่นๆ สำหรับประเมินประสิทธิภาพของระบบ ได้แก่:

• uptime – ความน่าเชื่อถือของระบบและค่าเฉลี่ยโหลด
• top – เพื่อให้เห็นภาพรวมของระบบ
  • htop – โปรแกรมดูขั้นตอนการทำงานแบบโต้ตอบ
• btop – เครื่องมือแสดงภาพรวมระบบอีกตัวหนึ่ง
• vmstat – โปรแกรม vmstat รายงานข้อมูลเกี่ยวกับกระบวนการที่สามารถทำงานได้หรือถูกบล็อก หน่วยความจำ เพจจิ้ง การอ่านเขียนบล็อก กับดัก และ CPU
• dool(เดิมdstat) ^{[ 16 ]}atop  – ช่วยเชื่อมโยงข้อมูลทรัพยากรที่มีอยู่ทั้งหมดสำหรับกระบวนการ หน่วยความจำ เพจจิ้ง บล็อก I/O กับดัก และกิจกรรม CPU
• iftop – โปรแกรมดูข้อมูลการรับส่งเครือข่ายแบบโต้ตอบต่ออินเทอร์เฟซ
• nethogs – โปรแกรมดูข้อมูลการรับส่งข้อมูลเครือข่ายแบบโต้ตอบต่อกระบวนการ
• iotop – โปรแกรมดู I/O แบบโต้ตอบ^{[ 17 ]}
• iostat – สำหรับสถิติการรับส่งข้อมูล I/O ของระบบจัดเก็บข้อมูล
• netstat – สำหรับสถิติเครือข่าย
• mpstat – สำหรับสถิติการใช้งาน CPU
• tload – กราฟแสดงค่าเฉลี่ยโหลดสำหรับเทอร์มินัล
• xload – กราฟค่าเฉลี่ยโหลดสำหรับ X

• การใช้งาน CPU

• เบรนแดน เกร็ก (8 สิงหาคม 2017). "ค่าเฉลี่ยโหลดของ Linux: ไขปริศนา" . สืบค้นเมื่อ22 มกราคม 2018 .
• Neil J. Gunther . "UNIX Load Average – ตอนที่ 1: วิธีการทำงาน" (PDF) . TeamQuest . สืบค้นเมื่อ12 สิงหาคม 2552 .
• Andre Lewis (31 กรกฎาคม 2552). "ทำความเข้าใจภาระการทำงานของ CPU ใน Linux – คุณควรจะกังวลเมื่อใด?" . สืบค้นเมื่อ21 กรกฎาคม 2554 .อธิบายโดยใช้ภาพประกอบเปรียบเทียบกับสภาพการจราจร
• Ray Walker (1 ธันวาคม 2006). "การตรวจสอบค่าเฉลี่ยโหลด" . Linux Journal . สืบค้นเมื่อ 21 กรกฎาคม 2011 .
• Karsten Becker. "ชุดเครื่องมือตรวจสอบโหลดซอฟต์แวร์โอเพนซอร์สสำหรับ Linux" . LoadAvg.