อินสแตนซ์กับคอร์เมื่อใช้ EC2

ทำงานกับสิ่งที่มักเรียกว่าโครงการ "ข้อมูลขนาดกลาง" ฉันสามารถทำให้ขนานรหัสของฉัน (ส่วนใหญ่สำหรับการสร้างแบบจำลองและการทำนายใน Python) ในระบบเดียวจาก 4 ถึง 32 แกน ตอนนี้ฉันกำลังมองหาการปรับขนาดของกลุ่มบน EC2 (อาจเป็นกับ StarCluster / IPython แต่เปิดให้มีคำแนะนำอื่น ๆ เช่นกัน) และได้รับการงงงวยโดยวิธีการกระทบยอดการกระจายงานข้ามแกนในกรณีเทียบกับอินสแตนซ์ในคลัสเตอร์

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

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

เมื่อใช้ IPython คุณแทบไม่ต้องกังวลเกี่ยวกับมัน (เสียค่าใช้จ่ายในเรื่องประสิทธิภาพ / ค่าใช้จ่ายในการสื่อสารที่สูงกว่า) ปลั๊กอิน IPython แบบขนานใน StarCluster จะเริ่มต้นหนึ่งเอ็นจินต่อฟิสิคัลคอร์ในแต่ละโหนด (ฉันเชื่อว่านี่สามารถกำหนดค่าได้ แต่ไม่แน่ใจว่าอยู่ตรงไหน) คุณเพียงเรียกใช้สิ่งที่คุณต้องการในทุกเครื่องมือโดยใช้ DirectView api (map_sync, Apply_sync, ... ) หรือคำสั่งเวท px หากคุณใช้ IPython แบบขนานบนเครื่องหนึ่งการใช้งานบนคลัสเตอร์จะไม่แตกต่างกัน

การตอบคำถามเฉพาะของคุณ:

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

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

"ถ้าเป็นเช่นนั้นทุกคนสามารถให้ข้อดีข้อเสียอย่างรวดเร็วของการเรียกใช้อินสแตนซ์จำนวนมากที่มีคอร์ไม่กี่คอร์แต่ละตัวเปรียบเทียบกับคอร์ที่มีหลายคอร์หรือไม่? มีกฎง่ายๆสำหรับการเลือกอัตราส่วนที่เหมาะสมของอินสแตนซ์ " - ใช้อินสแตนซ์ c3 ที่ใหญ่ที่สุดสำหรับการคำนวณขอบเขตและขนาดเล็กที่สุดสำหรับปัญหาเกี่ยวกับหน่วยความจำแบนด์วิดท์ สำหรับปัญหาการ จำกัด ขอบเขตข้อความให้ใช้อินสแตนซ์ที่ใหญ่ที่สุด แต่พยายามแบ่งปัญหาเพื่อให้แต่ละพาร์ติชันทำงานบนเครื่องจริงหนึ่งเครื่องและการส่งข้อความส่วนใหญ่จะอยู่ในพาร์ติชันเดียวกัน ปัญหาที่จะทำงานช้าลงอย่างมีนัยสำคัญในอินสแตนซ์ของ N quadruple c3 มากกว่าใน 2N double c3 นั้นเป็นของหายาก (ตัวอย่างเทียมอาจใช้ฟิลเตอร์แบบง่ายหลายตัวในรูปภาพจำนวนมากซึ่งคุณจะผ่านรูปภาพทั้งหมดสำหรับแต่ละตัวกรอง ภาพเดียวกัน)

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

เมื่อถึงจุดหนึ่งการเพิ่มขนาดของเครื่องจักรหนึ่งเครื่องจะไม่ประหยัดเนื่องจากค่าใช้จ่ายของทรัพยากรเพิ่มเติมมีขนาดมากกว่าเชิงเส้น อย่างไรก็ตามจุดนี้ยังคงสูงอย่างน่าอัศจรรย์

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

สิ่งหนึ่งที่ต้องพิจารณาอย่างมากคือกระบวนทัศน์การคำนวณสามารถเปลี่ยนแปลงได้ค่อนข้างมากเมื่อคุณย้ายจากเครื่องหนึ่งไปยังหลายเครื่อง ตัวอย่างเช่นการแลกเปลี่ยนข้อมูลที่เกิดจากค่าใช้จ่ายในการสื่อสารอาจทำให้คุณต้องปรับกระบวนทัศน์ข้อมูลแบบขนาน นั่นหมายถึงทางเลือกของเครื่องมือและอัลกอริทึมที่แตกต่างกัน ตัวอย่างเช่น SGD มีลักษณะในหน่วยความจำและ Python แตกต่างจาก MapReduce ดังนั้นคุณต้องพิจารณาเรื่องนี้ก่อนที่จะทำการขนานกัน

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

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

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

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

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