โหลดเฉลี่ยที่ยอมรับได้

เราปรับใช้เซิร์ฟเวอร์อีเมล Linux / Exim / Spamassassin ใหม่ของเราในวันศุกร์ (ควรทำการปรับใช้หนึ่งวันก่อนวันหยุดยาวเมื่อไม่มีผู้ดูแลระบบ) โหลดได้รับการโฉบรอบ 1.3 โดยเฉลี่ย 15 นาที

เครื่องตอบสนองและจัดส่งอีเมลในเวลาที่เหมาะสม เราสามารถสันนิษฐานได้ว่าสิ่งนี้เป็นที่ยอมรับได้หรือไม่?

ปริมาณที่กำหนดให้ถือว่ายอมรับได้หรือไม่ยอมรับเป็นอย่างไร มีการใช้เมตริกอะไรบ้าง

กฎพื้นฐานง่ายๆ: หากระบบตอบสนองหากทำงานได้ตามกำหนดเวลาแสดงว่าคุณไม่เป็นไร

โหลดต่ำกว่าสองไม่ต้องกังวลมาก ฉันมีระบบที่ตีสี่หรือห้าและยังทำงานได้ดีแม้ว่าจะเป็นตัวบ่งชี้ว่ามีปัญหาการเข้าคิวกับเครือข่ายหรือไดรฟ์จำนวนมาก (ปัญหา I / O อาจทำให้โหลดสูงถึงแม้ว่าระบบจะตอบสนองได้ดีก็ตาม)

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

คุณสามารถทำอะไรกับการหาค่าเฉลี่ยของดิสก์และข้อมูล I / O เครือข่าย แต่ถ้าคุณไม่เห็นปัญหาการจัดส่ง (ฉันส่งข้อความเมื่อสิบห้านาทีที่แล้วและมันยังมาไม่ถึง!) และคุณสามารถทำงานบนระบบผ่านคอนโซล ( หรือ ssh) โดยไม่มีความล่าช้ามากคุณควรจะปรับ

โหลดเฉลี่ยเป็นค่าที่ให้แนวคิดเกี่ยวกับจำนวนตัวประมวลผลที่เคอร์เนลต้องการเพื่อให้สามารถรันงานทั้งหมดเมื่อพวกเขาต้องการโดยไม่ต้องรอ
ในกรณีที่คุณมี CPU / Core 2 ตัวขึ้นไป ไม่มีปัญหา. หากคุณมี CPU เพียง 1 ตัวที่มี 1 Core หมายความว่ามีเวลา "มากเกินไป" ระหว่างเวลาที่แอปของคุณต้องการเรียกใช้และเวลาที่เคอร์เนลรัน การโหลด "จำนวน cpu / core" จะไม่เป็นปัญหาสำหรับระบบเมลจนกว่าจะถึงค่าที่สูงเกินไปเป็นเวลานานเกินไป
แน่นอนว่าพวกเขาไม่มีกฎเกณฑ์และคุณค่าที่จะให้และในขณะที่คุณได้รับอีเมลในเวลาอันสั้นมันก็โอเค แต่คุณอาจต้องเริ่มมองเซิร์ฟเวอร์ของคุณอย่างใกล้ชิดเมื่อโหลดสูงกว่า 2 * จำนวนซีพียู / คอร์มากเกินไปบ่อยครั้งเป็นระยะเวลานาน (~ 1 ชั่วโมง)
อีกครั้งสำหรับเมลเซิร์ฟเวอร์สิ่งนี้จะไม่เป็นปัญหาใหญ่ แต่มันจะเริ่มหมายความว่าเซิร์ฟเวอร์ของคุณโอเวอร์โหลดไปเล็กน้อย

เช่นเดียวกับการปรับคำถามที่เกี่ยวข้องไม่มีคำตอบใช่ / ไม่ใช่ทุกอย่างขึ้นอยู่กับ :-)

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

ในที่สุดถ้าอย่างที่คุณพูดข้อความจะถูกส่งในเวลาที่กำหนดแล้วประสิทธิภาพก็ดี :-)

top

จะให้ตัวชี้วัดพื้นฐานแก่คุณในเวลาใกล้พอจริง

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

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

ข้อแม้ที่ใหญ่ที่สุดที่ต้องจำคือกระบวนการที่กำลังรอดิสก์หรือเครือข่าย i / o แต่มิฉะนั้น runnable ยังคงปรากฏในภาระเฉลี่ย ดังนั้นหากคุณมีเซิร์ฟเวอร์ apache ให้ป้อน jpg ถึงผู้ใช้ 56k คุณสามารถเรียกใช้การโหลดเฉลี่ยที่สูงกว่าการให้ php / ตอบกลับสคริปต์ใด ๆ ไปยังพร็อกซี / loadbalancer ผ่าน gigabit LAN ในกรณีของคุณการเชื่อมต่อ smtp ไปยัง mailserver ที่ช้าซึ่งใช้เวลานานในการถ่ายโอนสิ่งที่แนบมาจะแสดงขั้นตอน 1 ขั้นตอนในคิวการทำงาน แต่อาจถูกขัดจังหวะยี่สิบครั้งเพื่อส่งอีเมลแบบซับไลน์ด่วนไปยัง Gmail

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

คุณมีกี่คอร์? cat / proc / cpuinfo | หน่วยประมวลผล grep ห้องสุขา -l

(ข้อแม้: การทำไฮเปอร์เธรดดูเหมือนแกนมากกว่า แต่ไม่ใช่)

หากระดับโหลดของคุณต่ำกว่าจำนวนโปรเซสเซอร์ของคุณแสดงว่าคุณตกลง

ดูที่ด้านบนแล้วกด '1' และคุณสามารถดูการโหลดแต่ละซีพียูได้

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

การตั้งค่าของเรานั้นแตกต่างกันเล็กน้อย เรามีเซิร์ฟเวอร์แยกต่างหากสำหรับ SpamAssassin ในขณะที่เซิร์ฟเวอร์ POP ของเราเรียกใช้ ClamAV เพื่อสแกนหาไวรัส โดยทั่วไปแล้วเซิร์ฟเวอร์ POP จะทำงานภายใต้โหลดเซิร์ฟเวอร์ 2 แต่ในบางครั้งอาจมีมากถึง 10 ครั้งขึ้นไป เซิร์ฟเวอร์ SpamAssassin ของเราตรงกันข้ามเคยใช้งานประมาณ 2 จนกว่าเราจะติดตั้งตัวกรอง Openprotect.com เมื่อมันเพิ่มการใช้งาน CPU เป็นสองเท่าและตอนนี้ทำงานต่ำกว่า 5 ด้วย spikes มากกว่า 15 นี่ยังยอมรับได้เพราะเราไม่ได้ มีความล่าช้าในจดหมายที่ส่งผลให้คิวจดหมายเพิ่มขึ้น (เราใช้ qmail สำหรับ SMTP ขาเข้า) และยังมีพื้นที่ว่างสำหรับการใช้งาน CPU / หน่วยความจำอย่างชาญฉลาด

บังเอิญฉันขอแนะนำMuninสำหรับการตรวจสอบเซิร์ฟเวอร์ของคุณ มันเป็นงานที่ยอดเยี่ยมในการแสดงข้อมูลทางประวัติศาสตร์และแสดงให้คุณเห็นว่าคุณต้องใช้ทรัพยากรอะไรบ้าง การตรวจสอบตามเวลาจริงด้วย Top (1) ไม่ได้ช่วยอะไรคุณมากนัก :)

การใช้งานในวันศุกร์ก่อนวันหยุดยาวเป็นวิธีที่ยอดเยี่ยมในการทำงานตลอดทั้งสัปดาห์ โดยเฉพาะอย่างยิ่งสำหรับระบบที่สำคัญเช่นเซิร์ฟเวอร์อีเมล

หน่วยความจำเป็นอย่างไร? มันมั่นคงหรือเติบโตหรือไม่

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

ใจคุณวันนี้จะเป็นการทดสอบจริงครั้งแรกของคุณ ฉันอาจจะตรวจสอบมันวันนี้เบา ๆ หากมีอะไรผิดพลาดเกิดขึ้นตอนนี้ก็ถึงเวลาแล้ว