เมื่อเร็ว ๆ นี้หากคุณต้องการทดสอบจำนวนสูงสุดพร้อมกันภายใต้ OpenFire คุณต้องเปิดเธรดจำนวนมากเพื่อจำลองไคลเอนต์ ฉันมักจะงงงวยเกี่ยวกับจำนวนเธรดที่อินสแตนซ์ JVM สามารถเปิดได้ดังนั้นฉันจึงวางแผนที่จะทดสอบและค้นหาปัจจัยต่อไปนี้ที่มีผลต่อจำนวนเธรด:
-xms | ขนาดฮีปจาวา |
-xmx | ขนาดกอง Java สูงสุด |
-xss | ขนาดสแต็กสำหรับแต่ละเธรด |
ข้อ จำกัด ของระบบ | จำนวนเธรดสูงสุดที่สามารถเปิดได้ในระบบ |
โปรแกรมทดสอบมีดังนี้: รหัส Java:
นำเข้า java.util.concurrent.atomic.atomicinteger; Public Class TestThread ขยายเธรด {Private Static Final Atomicinteger Count = New Atomicinteger (); โมฆะคงที่สาธารณะหลัก (สตริง [] args) {ในขณะที่ (จริง) (ใหม่ testThread ()). start (); } @Override โมฆะสาธารณะ Run () {system.out.println (count.incrementandget ()); ในขณะที่ (จริง) ลอง {thread.sleep (integer.max_value); } catch (interruptedException e) {break; - สภาพแวดล้อมการทดสอบ: ระบบ: Ubuntu 10.04 เคอร์เนล Linux 2.6 (32 บิต)
หน่วยความจำ: 2G
JDK: 1.7
ผลการทดสอบ:
Øไม่มีการพิจารณาข้อ จำกัด ของระบบ
-xms | -xmx | -xss | ผลลัพธ์ |
1024m | 1024m | 1024K | 2280 |
1024m | 1024m | 64K | 26077 |
512m | 512m | 64K | 31842 |
256m | 256m | 64K | 31842 |
เมื่อจำนวนเธรดที่สร้างขึ้นถึง 31,842 จะไม่สามารถสร้างเธรดในระบบได้
จากผลการทดสอบข้างต้นจะเห็นได้ว่าการเพิ่มหน่วยความจำฮีป (-xms, -xmx) จะลดจำนวนเธรดที่สามารถสร้างได้และการเพิ่มหน่วยความจำสแต็กเธรด (-xss ค่าต่ำสุดของพารามิเตอร์นี้ในระบบ 32 บิตคือ 60K) จะลดจำนวนเธรดที่สามารถสร้างได้
Øรวมกับข้อ จำกัด ของระบบ
ขีด จำกัด ของจำนวนเธรด 31842 ถูกกำหนดโดยจำนวนสูงสุดของเธรดที่ระบบสามารถสร้าง:/proc/sys/เคอร์เนล/เธรด-แม็ก
-xms | -xmx | -xss | ผลลัพธ์ |
256m | 256m | 64K | 9761 |
ในกรณีนี้หมายความว่าสามารถกำหนดค่าเธรดได้มากที่สุดเท่าที่จะเป็นไปได้หรือไม่? ทำการดัดแปลงอื่น: Echo 10,00000>/Proc/Sys/Kernel/Threads-Max ผลการทดสอบที่ได้รับการแก้ไขมีดังนี้:
-xms | -xmx | -xss | ผลลัพธ์ |
256m | 256m | 64K | 32279 |
128m | 128m | 64K | 32279 |
พบว่าจำนวนเธรดจะไม่เพิ่มขึ้นอีกต่อไปหลังจากถึง 32279 หลังจากตรวจสอบจำนวนสูงสุดของ PID ที่สามารถสร้างได้โดยระบบ Linux 32 บิตคือ 32678 ค่านี้สามารถปรับเปลี่ยนผ่าน/proc/sys/kernel/pid_max (วิธีการปรับเปลี่ยนที่มีขนาดใหญ่กว่า เมื่อเธรด-แม็กซ์แน่นอนผลการทดสอบสำหรับการแก้ไข pid_max มีดังนี้:
pid_max | -xms | -xmx | -xss | ผลลัพธ์ |
1,000 | 128m | 128m | 64K | 582 |
10,000 | 128m | 128m | 64K | 9507 |
สถานการณ์บน Windows ควรจะคล้ายกัน แต่จำนวนเธรดที่สามารถสร้างได้บน Windows อาจมีขนาดเล็กกว่า Linux เซิร์ฟเวอร์ที่ใช้โมเดลเธรดจะถูก จำกัด ด้วยจำนวนเธรดเสมอ
จำนวนสูงสุดที่สามารถสร้างได้ใน JVM ได้รับผลกระทบจากขนาดหน่วยความจำฮีปของ JVM ขนาดหน่วยความจำสแต็กของเธรดและจำนวนเธรดสูงสุดที่ระบบสามารถสร้างได้ จำนวนเงินที่เฉพาะเจาะจงสามารถประมาณได้ตามหน่วยความจำสูงสุดที่กระบวนการ Java สามารถเข้าถึงได้ (โดยทั่วไป 2G ในระบบ 32 บิต) หน่วยความจำฮีปและหน่วยความจำสแต็กของเธรด
ลำดับ:
ทดสอบในระบบ Linux 64 บิต (หน่วยความจำ Centos6, 3G) ฉันพบว่ามีพารามิเตอร์อื่นที่ จำกัด จำนวนเธรด: MaxuserProcess (สามารถดูได้ผ่าน ULIMITA ค่าเริ่มต้นคือ 1024 และค่านี้สามารถแก้ไขได้ผ่าน ULIMITU) ค่านี้ไม่ จำกัด ในสภาพแวดล้อมการทดสอบ Ubuntu 32 บิตข้างต้น
แก้ไข Threads -Max, PID_MAX, MaxUserProcess, พารามิเตอร์ทั้งสามเป็น 100000, -XMS, -XMX มีขนาดเล็กที่สุดเท่าที่จะเป็นไปได้ (128m, 64m) และ -xSS มีขนาดเล็กที่สุด (104K ที่ 64 บิตค่าอาจเป็น 128K) คาดการณ์ล่วงหน้าในสภาพแวดล้อมการทดสอบนี้จำนวนเธรดจะถูก จำกัด เฉพาะขนาดหน่วยความจำ (3G) ของสภาพแวดล้อมการทดสอบ อย่างไรก็ตามผลการทดสอบที่แท้จริงคือเมื่อจำนวนเธรดมาถึง 32K (32768 จำนวนสูงสุดที่สร้างขึ้นคือประมาณ 33,000), JVM ส่งคำเตือน: TiveToAllocatestackGuardguard ล้มเหลวและจากนั้น OutofMemoryError หลังจากตรวจสอบหน่วยความจำฉันพบว่ายังมีเวลาว่างมากดังนั้นจึงไม่ควรเกิดจากความจุหน่วยความจำ คำเตือนของ Google นั้นไร้ผล ฉันไม่รู้ว่าทำไมและต้องการการวิจัยเพิ่มเติม
ขั้นตอนที่ 2:
ฉันค้นพบบทความโดยไม่ตั้งใจ [7] วันนี้และลองทันที แน่นอนว่าปัจจัยนี้จะส่งผลกระทบต่อจำนวนการสร้างเธรด ตามคำอธิบายในบทความจำนวน/proc/sys/vm/max_map_count เพิ่มขึ้นเป็นสองเท่าจาก 65536 ถึง 131072 จำนวนเธรดที่สร้างขึ้นทั้งหมดถึง 65000+ คอมพิวเตอร์โดยทั่วไปจะต้องติดอยู่ (หน่วยความจำ 3G) ... ฉันตรวจสอบฟังก์ชั่นของพารามิเตอร์นี้สั้น ๆ และคำอธิบายใน [8] มีดังนี้:
“ ไฟล์นี้มีจำนวนสูงสุดของหน่วยความจำ memorymapareasprocessmayhave.memorymapareasareusedasaside-effect-effect-effect-effect โดยตรง bymmapandmprotect โดยตรง Andalso เมื่อโหลดไลบรารีที่ใช้ร่วมกัน
ในขณะที่แอปพลิเคชันส่วนใหญ่จำเป็นต้องใช้น้อยกว่าแผนที่บางโปรแกรมโดยเฉพาะอย่างยิ่ง Mallocdebuggers อาจบริโภคตูดเช่น uptooneortwomapsperallocation
TheDefaultValueis65536 "
ตกลงปัญหานี้ได้รับการแก้ไขอย่างสมบูรณ์ในที่สุด ในที่สุดปัจจัยที่มีผลต่อจำนวนเธรด Java ได้สรุปไว้:
Java Virtual Machine เอง: -xms, -xmx, -xss;
ข้อ จำกัด ของระบบ:
/proc/sys/kernel/pid_max
/proc/sys/kernel/thread-max
max_user_process (ulimit-u)
/proc/sys/vm/max_map_count
สรุป
ข้างต้นคือทั้งหมดที่เกี่ยวกับการทดสอบอย่างง่ายของ JVM ที่รองรับจำนวนเธรดสูงสุด ฉันหวังว่ามันจะเป็นประโยชน์กับทุกคน เพื่อนที่สนใจสามารถอ้างถึงหัวข้ออื่น ๆ ที่เกี่ยวข้องในเว็บไซต์นี้ต่อไป หากมีข้อบกพร่องใด ๆ โปรดฝากข้อความไว้เพื่อชี้ให้เห็น