จำนวนที่เหมาะสมที่สุดสำหรับกระบวนการยูนิคอร์น CPU

เรากำลังเรียกใช้เว็บแอพ Ruby on Rails ในยูนิคอร์น แอปของเราไม่ได้เชื่อมโยงกับ CPU อย่างเคร่งครัด (เรามีระบบ Dual Xeon E5645 ที่มี 12 คอร์และค่าเฉลี่ยการโหลดสูงสุดอยู่ที่ประมาณ 6) เราเริ่มต้นด้วยคนงานยูนิคอร์น 40 คนในตอนแรก แต่การใช้งานหน่วยความจำเพิ่มขึ้นเมื่อเวลาผ่านไป ดังนั้นตอนนี้เราต้องลดจำนวนกระบวนการทำงาน ฉันคิดว่าสูตรมาตรฐาน (จำนวนคอร์ CPU + 1) ใช้กับยูนิคอร์นด้วย แต่เพื่อนร่วมงานของฉันพยายามโน้มน้าวให้ฉันฉันควรจองอินสแตนซ์ยูนิคอร์นต่อซีพียูมากขึ้นและระบุลิงก์นี้ แต่ฉันไม่แน่ใจว่าทำไมเราต้องใช้หน่วยความจำมากในกระบวนการยูนิคอร์นที่ไม่ได้ใช้งาน

คำถามของฉันคืออะไรเหตุผลที่มีมากกว่าหนึ่งตัวอย่างยูนิคอร์นต่อซีพียูคอร์? มันเป็นเพราะลักษณะทางสถาปัตยกรรมบางอย่างของยูนิคอร์นหรือไม่? ฉันทราบว่ากระบวนการ Unicorn ที่ยุ่งไม่สามารถยอมรับการเชื่อมต่อใหม่ (เราใช้ซ็อกเก็ตโดเมน UNIX เพื่อสื่อสารกับ Unicorn อินสแตนซ์ BTW) แต่ฉันคิดว่า Backlog ถูกนำมาใช้เพื่อแก้ไขปัญหานี้ เป็นไปได้ไหมที่จะเอาชนะยูนิคอร์นอินสแตนซ์ 2 ถึง 8 ตัวต่อกฎของ CPU ได้?

ตกลงฉันได้พบคำตอบในที่สุด จำนวนยูนิคอร์นที่เหมาะสมที่สุดไม่ได้เชื่อมต่อโดยตรงกับจำนวนคอร์ CPU มันขึ้นอยู่กับโหลดและโครงสร้างแอป / การตอบสนองภายในของคุณ โดยทั่วไปเราใช้การสุ่มตัวอย่าง profiler เพื่อกำหนดสถานะของคนงานเราพยายามที่จะทำให้แรงงานว่าง 70% และ 30% ทำงานจริง ดังนั้น 70% ของกลุ่มตัวอย่างควรจะ "กำลังรอการเรียก select () เพื่อรับการร้องขอจากเซิร์ฟเวอร์ส่วนหน้า" การวิจัยของเราแสดงให้เห็นว่ามีเพียง 3 สถานะที่มีประสิทธิภาพของคนงาน: 0-30% ของตัวอย่างไม่ได้ใช้งาน, 30-50% ของตัวอย่างไม่ได้ใช้งานและ 50-70% ของตัวอย่างไม่ได้ใช้งาน (ใช่เราจะได้รับตัวอย่างว่างมากขึ้น ไม่มีจุดจริงเพราะการตอบสนองของแอปพลิเคชันไม่เปลี่ยนแปลงอย่างมีนัยสำคัญ) เราพิจารณาสถานการณ์ 0-30% เป็น "โซนสีแดง" และสถานการณ์ 30-50% เป็น "โซนสีเหลือง"

คุณพูดถูกเกี่ยวกับ N + 1 สำหรับงานที่ใช้ CPU

ในทางตรงกันข้ามยูนิคอร์นไม่ได้ใช้เธรดดังนั้นทุก ๆ op ของ IO บล็อกกระบวนการและกระบวนการอื่นอาจเตะเข้าและแยกส่วนหัว HTTP เชื่อมสตริงและทำทุกงานที่ใช้ CPU มากซึ่งจำเป็นต้องให้บริการแก่ผู้ใช้

และคุณอาจต้องการมีเธรด / กระบวนการเพิ่มเติมจากแกนประมวลผล ลองนึกภาพสถานการณ์ต่อไปนี้: req ใช้เวลามากกว่าสิบเท่า B คุณมีคำขอ A พร้อมกันหลายคำขอและคำขอ B ที่รวดเร็วนั้นจะถูกจัดคิวรอให้ A-req ให้เสร็จสมบูรณ์ ดังนั้นหากคุณสามารถคาดการณ์จำนวนคำขอหนักคุณสามารถใช้หมายเลขนี้เป็นแนวทางอื่นในการปรับระบบ