ฉันควรระบุกระบวนการจำนวนเท่าใดใน WSGIDaemonProcess ขณะเรียกใช้ Django ผ่าน mod_wsgi


23

สมมติว่าฉันมี 2 ไซต์ (Superuser และ Serverfault) ทำงานจากโฮสต์เสมือน Apache ของพวกเขาในหนึ่งกล่อง 2 ไซต์นี้ขับเคลื่อนโดย Django และทำงานบน Apache พร้อม mod-wsgi ไฟล์กำหนดค่าทั่วไปสำหรับหนึ่งในไซต์จะมีลักษณะดังต่อไปนี้:

WSGIDaemonProcess serverfault.com user=www-data group=www-data processes=5

โฮสต์เป็นเครื่อง linux ที่มี RAM ขนาด 4GB ที่ใช้งาน Ubuntu ทุกคนสามารถแนะนำจำนวนกระบวนการที่ฉันควรระบุด้านบนสำหรับ 2 ไซต์ของฉันได้หรือไม่ สมมติว่าพวกเขามีปริมาณการใช้งานเช่นเดียวกับไซต์ Superuser และ Serverfault ที่เกิดขึ้นจริง

คำตอบ:


22

ด้วยวิธีการจราจรมากไม่จริง Superuser และ Serverfault เว็บไซต์ได้? สมมุติไม่ได้ใช้มากนักหากพวกเขาไม่มีข้อมูลเพียงพอที่จะทำให้คำตอบง่ายขึ้น ...

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

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

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

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

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

คุณมีประสบการณ์หลายปีในการปรับเว็บไซต์ที่กลั่นเป็นโพสต์ SF ขนาดเล็กและเรียบง่าย


ปัจจัยสำคัญอีกประการหนึ่งสำหรับจำนวนกระบวนการ / เธรดคือระยะเวลาที่แต่ละคำขอสามารถจัดการได้และการแพร่กระจายโดยรวมในระยะเวลาที่เป็นไปได้ทั้งหมด กล่าวอีกนัยหนึ่งจำนวนคำขอในแต่ละครั้งต้องได้รับการจัดการซึ่งใช้เวลาตอบสนองมากกว่าปกติ ดังนั้นมันจึงไม่ง่ายเหมือนคำขอทางทฤษฎี / วินาทีเนื่องจากผลกระทบของคำขอที่ทำงานนานกว่านั้นอาจมีความสำคัญและกำหนดพารามิเตอร์การกำหนดค่าโดยรวมอย่างไม่เหมาะสม FWIW mod_wsgi 3.0 จะมีการรวบรวมสถิติในตัวเพื่อลองและจับข้อมูลเกี่ยวกับสิ่งนี้เพื่อช่วยในการกำหนดค่า
เกรแฮม Dumpleton

@ เกรแฮม: อ่านคำตอบของฉันอีกครั้งฉันพูดถึงเรื่องนี้อย่างละเอียด คำร้องขอ / วินาทีเป็นเพียงส่วนกลับของเวลาตอบสนองและง่ายกว่าที่จะหารด้วยจำนวนเต็ม req / วินาทีง่ายกว่าการคูณด้วยทศนิยม
womble

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

3
ปัญหาอาจเป็นได้ว่าคุณกำลังดูกระบวนการเฉพาะที่ฉันเป็นห่วงเกี่ยวกับวิธีเธรดแต่ละกระบวนการใช้ปัจจัยในนั้นและที่ไม่ง่าย กล่าวอีกนัยหนึ่งคือคำสั่ง WSGIDaemonProcess ระบุ 5 กระบวนการที่แต่ละกระบวนการเป็นค่าเริ่มต้นโดยใช้ 15 เธรด เท่าที่ฉันอ่านลงในคำอธิบายของคุณมันคือการสมมติว่ากระบวนการเธรดเดียว ถ้าไม่บอกให้ฉันทราบว่าแบบจำลองของคุณสำคัญกับเธรดอย่างไรรวมถึงประเด็นการโต้แย้ง / การปรับขนาดรอบ GIL ดังนั้นจึงมีคุณสมบัติที่คำอธิบายของคุณใช้ได้สำหรับกระบวนการเธรดเดี่ยวเท่านั้นและฉันจะไม่โต้แย้ง
เกรแฮม Dumpleton

2
"multithreaded-Apache + multiprocess-wsgi" ไม่ใช่ทางออกที่ดีที่สุดจนกว่าคุณจะแน่ใจ 99% ว่ารหัส Python ของคุณและการอ้างอิงทั้งหมดนั้นปลอดภัยต่อเธรดหรือไม่
Tomasz Zieliński

9

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

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

A) เว็บไซต์ CMS & ไมโครไซต์

เราเรียกใช้เว็บไซต์ลูกค้าหลายแห่งส่วนใหญ่ส่วนใหญ่เป็นเว็บไซต์เนื้อหาหรือเว็บไซต์ขนาดเล็กที่โฮสต์ django CMS, รูปแบบที่กำหนดเองและบางครั้งคื่นฉ่ายสำหรับงานพื้นหลังที่กำหนดไว้ ไซต์เหล่านี้ไม่ได้หิวโหยสำหรับทรัพยากรหลายแห่งทำงานอย่างมีความสุขพร้อม ๆ กันบน Intel Core Xeon 4 คอร์ที่มี RAM ขนาด 32 GB นี่คือการกำหนดค่าที่เราใช้สำหรับไซต์แต่ละประเภทนี้:

WSGIDaemonProcess example.com user=www-data processes=2 maximum-requests=100

ฉันกำลังพูดถึงเว็บไซต์ประมาณ 40 แห่งบนเซิร์ฟเวอร์เดียวโดยส่วนใหญ่เป็นไซต์ Staging ที่ทำงานในโหมดสแตนด์บาย ด้วย 2 กระบวนการ (มี 15 เธรดโดยค่าเริ่มต้น) ไซต์นั้นมีความเป็นมิตรแม้ว่าจะมีข้อ จำกัด ในความสามารถในการจัดสรรทรัพยากรเซิร์ฟเวอร์ เหตุใดการตั้งค่านี้จึงเพียงพอสามารถพิสูจน์ได้ด้วยลักษณะที่เรียบง่ายของแอปพลิเคชัน (CMS): คาดว่าจะไม่มีการร้องขอใด ๆ ที่จะใช้เวลานานกว่าสองสามมิลลิวินาที Apache จะยังคงผ่อนคลายอยู่ตลอดเวลาและจะเป็นภาระของ CPU

B) เว็บไซต์อีคอมเมิร์ซ

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

สำหรับสถานการณ์เหล่านั้นเราได้ลองใช้6กระบวนการโดยไม่เห็นความแตกต่างมากและท้ายที่สุดเราก็ได้12เห็นการเพิ่มประสิทธิภาพและความมั่นคงในการทำงานที่ไม่มีใครเทียบได้

WSGIDaemonProcess example.com user=www-data processes=12 maximum-requests=100

บางการทดสอบความเร็วในการโหลดง่ายด้วย 150 และผู้ใช้ 250 คนขนานจะจัดการได้อย่างง่ายดายโดยเว็บไซต์ที่ตอบสนองต่อการเข้าพักดี (ในขณะที่มี2กระบวนการเว็บไซต์ที่มีการใช้ไม่ได้ทำอาหารรับประทานเองผู้ใช้ 50 คนในแบบคู่ขนาน) 2 CPU 6 Core Intel Xeon ที่มี RAM 32 GB ทำงานได้ดีกว่าการใช้งาน CPU ต่ำกว่า 25% ภายใต้โหลดนั้นการใช้ RAM เกือบจะคงที่ที่น้อยกว่า 25% เช่นกัน โปรดทราบว่าเราใช้เครื่องเฉพาะสำหรับไซต์เดียวที่นี่ดังนั้นเราจะไม่ขโมยทรัพยากรที่ไซต์อื่น ๆ อาจต้องการ

ข้อสรุป

การใช้กระบวนการจำนวนมากขึ้นเป็นการแลกเปลี่ยนระหว่างการอนุญาตให้ Apache ใช้ประโยชน์จากทรัพยากรระบบที่มีอยู่หรือไม่ หากคุณต้องการรักษาระบบเซิร์ฟเวอร์ให้มั่นคง (ไม่ใช่เว็บไซต์!) ภายใต้เงื่อนไข "การโจมตี" จะรักษาหมายเลขให้อยู่ในระดับต่ำ หากคุณต้องการให้ Apache ช่วยคุณใช้ทรัพยากรระบบ (CPU, RAM) เมื่อต้องการให้เลือกจำนวนที่สูงกว่า คุณสามารถไปคำนวณได้สูงแค่ไหนในคำตอบที่ได้รับการยอมรับข้างต้นและถูก จำกัด ด้วยพลัง CPU และ RAM ในที่สุด

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


โพสต์ที่ยอดเยี่ยม แต่ทำไมคุณไม่ตั้งค่าจำนวนกระทู้? เนื่องจาก GIL ของ Python คัดค้านข้อดีมากมายของเธรดฉันคิดว่าคุณต้องการมีกระบวนการมากกว่าเธรด แต่มีข้อดีใดบ้างที่ระบุการนับจำนวนเธรด?
Cerin

หมายเลขเริ่มต้นของthreads15 ตามเอกสาร ฉันไม่คิดว่าจะมีข้อได้เปรียบในการระบุอย่างชัดเจน ในความเป็นจริงฉันจำได้ว่าทิ้งมันไว้ด้วยเหตุผล: มีบางโพสต์เกี่ยวกับ SO หรือเอกสารบางส่วนที่แนะนำให้ละเว้นค่าเพื่อหลีกเลี่ยงผลข้างเคียง (ฉันรู้ว่าฟังดูแปลก) น่าเสียดายที่ฉันไม่พบที่มาในตอนนี้ สำหรับคำถามที่เหลือของคุณ (GIL) คุณอาจมีความเชี่ยวชาญมากกว่าฉันขอโทษ
Peterino

ขอบคุณสำหรับการกำหนดค่าเชิงประจักษ์นี้ อย่างไรก็ตามโปรดจำไว้ว่าตามโพสต์นี้ You should never use maximum-requests in a production system unless you understand the implications and have a specific temporary need.
raratiru
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.