เนื่องจาก Java 7 กำลังจะใช้การรวบรวมขยะ G1 ใหม่โดยค่าเริ่มต้น Java จะสามารถจัดการลำดับขนาดฮีปที่ใหญ่ขึ้นโดยไม่ควรหยุด GC ชั่วคราวได้หรือไม่? มีใครนำ G1 มาใช้จริงบ้างคุณมีประสบการณ์อย่างไรบ้าง?
เพื่อความเป็นธรรมครั้งเดียวที่ฉันได้เห็นการหยุด GC ที่ยาวนานจริงๆนั้นอยู่ในกองขนาดใหญ่มากเกินกว่าที่เวิร์กสเตชันจะมี เพื่อชี้แจงคำถามของฉัน G1 จะเปิดประตูสู่ฮีปในหลายร้อย GB หรือไม่ วัณโรค?
คำตอบ:
ดูเหมือนว่าจุดของ G1 จะมีเวลาหยุดชั่วคราวน้อยลงแม้กระทั่งถึงจุดที่มีความสามารถในการระบุเป้าหมายเวลาหยุดชั่วคราวสูงสุด
การเก็บขยะไม่ได้เป็นเพียงแค่ "เฮ้เต็มแล้วมาย้ายทุกอย่างพร้อมกันแล้วเริ่มต้นใหม่" จัดการอีกต่อไป - ระบบเธรดแบ็คกราวด์ซับซ้อนหลายระดับอย่างน่าอัศจรรย์ สามารถทำการบำรุงรักษาได้มากในพื้นหลังโดยไม่มีการหยุดเลยและยังใช้ความรู้เกี่ยวกับรูปแบบที่ระบบคาดไว้ในขณะรันไทม์เพื่อช่วยเช่นสมมติว่าวัตถุส่วนใหญ่ตายทันทีหลังจากสร้างเป็นต้น
ฉันจะบอกว่าเวลาหยุดชั่วคราวของ GC จะปรับปรุงต่อไปไม่แย่ลงพร้อมกับการเปิดตัวในอนาคต
แก้ไข:
ในการอ่านซ้ำเกิดขึ้นกับฉันที่ฉันใช้ Java ทุกวัน - Eclipse, Azureus และแอปที่ฉันพัฒนาและเป็นเวลานานมากแล้วที่ฉันเห็นการหยุดชั่วคราว ไม่ใช่การหยุดชั่วคราวที่สำคัญ แต่ฉันหมายถึงการหยุดชั่วคราวใด ๆ เลย
ฉันเคยเห็นการหยุดชั่วคราวเมื่อฉันคลิกขวาที่ windows explorer หรือ (เป็นครั้งคราว) เมื่อฉันเชื่อมต่อฮาร์ดแวร์ USB บางตัว แต่กับ Java - ไม่มีเลย
GC ยังคงเป็นปัญหากับใครหรือไม่?
ฉันได้ทำการทดสอบกับแอปพลิเคชั่นหนัก ๆ : 60-70GB จัดสรรให้กับฮีปโดยมีการใช้งาน 20-50GB ได้ตลอดเวลา ด้วยแอปพลิเคชั่นประเภทนี้การบอกว่าไมล์สะสมของคุณอาจแตกต่างกันไป ฉันใช้ JDK 1.6_22 บน Linux เวอร์ชันรองมีความสำคัญก่อนหน้าประมาณ 1.6_20 มีบั๊กใน G1 ที่ทำให้เกิด NullPointerExceptions แบบสุ่ม
ฉันพบว่ามันดีมากในการรักษาเป้าหมายหยุดชั่วคราวที่คุณให้ไว้เกือบตลอดเวลา ค่าเริ่มต้นดูเหมือนจะเป็นการหยุดชั่วคราว 100ms (0.1 วินาที) และฉันบอกให้ทำครึ่งหนึ่ง (-XX: MaxGCPauseMillis = 50) อย่างไรก็ตามเมื่อหน่วยความจำเหลือน้อยมากมันจะตื่นตระหนกและทำการเก็บขยะแบบหยุดโลกเต็มรูปแบบ ด้วย 65GB ซึ่งใช้เวลาระหว่าง 30 วินาทีถึง 2 นาที (จำนวนซีพียูอาจไม่ได้สร้างความแตกต่าง แต่อาจถูก จำกัด ด้วยความเร็วบัส)
เมื่อเทียบกับ CMS (ซึ่งไม่ใช่เซิร์ฟเวอร์เริ่มต้น GC แต่ควรเป็นสำหรับเว็บเซิร์ฟเวอร์และแอปพลิเคชันแบบเรียลไทม์อื่น ๆ ) การหยุดชั่วคราวโดยทั่วไปสามารถคาดเดาได้มากกว่าและสามารถทำได้สั้นกว่ามาก จนถึงตอนนี้ฉันโชคดีกว่ากับ CMS สำหรับการหยุดชั่วคราวครั้งใหญ่ แต่อาจเป็นแบบสุ่ม ฉันเห็นพวกเขาเพียงไม่กี่ครั้งทุกๆ 24 ชั่วโมง ฉันไม่แน่ใจว่าอันไหนจะเหมาะสมกว่าในสภาพแวดล้อมการผลิตของฉันในตอนนี้ แต่น่าจะเป็น G1 หาก Oracle ยังคงปรับจูนต่อไปฉันสงสัยว่าในที่สุด G1 จะเป็นผู้ชนะที่ชัดเจน
หากคุณไม่มีปัญหากับคนเก็บขยะที่มีอยู่ก็ไม่มีเหตุผลที่จะต้องพิจารณา G1 ในตอนนี้ หากคุณใช้งานแอปพลิเคชันที่มีเวลาแฝงต่ำเช่นแอปพลิเคชัน GUI G1 อาจเป็นตัวเลือกที่เหมาะสมโดยตั้งค่า MaxGCPauseMillis ไว้ต่ำมาก หากคุณใช้แอปพลิเคชันโหมดแบทช์ G1 จะไม่ซื้ออะไรให้คุณ
แม้ว่าฉันจะไม่ได้ทดสอบ G1 ในการผลิต แต่ฉันคิดว่าฉันจะแสดงความคิดเห็นว่า GC นั้นมีปัญหาอยู่แล้วสำหรับเคสที่ไม่มีฮีป "มหาศาล" บริการเฉพาะที่มีเพียง 2 หรือ 4 กิ๊กอาจได้รับผลกระทบอย่างรุนแรงจาก GC GC รุ่นใหม่มักจะไม่เป็นปัญหาเนื่องจากจบในหน่วยมิลลิวินาทีหลักเดียว (หรือมากที่สุดเป็นเลขสองหลัก) แต่คอลเลกชันรุ่นเก่าจะมีปัญหามากกว่าเนื่องจากใช้เวลาหลายวินาทีโดยมีขนาด 1 กิ๊กขึ้นไป
ตอนนี้: ตามทฤษฎีแล้ว CMS สามารถช่วยได้มากเนื่องจากสามารถเรียกใช้การดำเนินการส่วนใหญ่พร้อมกันได้ อย่างไรก็ตามเมื่อเวลาผ่านไปจะมีบางกรณีที่ไม่สามารถทำเช่นนี้ได้และต้องถอยกลับไปที่คอลเลคชัน "หยุดโลก" และเมื่อสิ่งนั้นเกิดขึ้น (หลังจากนั้นให้พูด 1 ชั่วโมง - ไม่บ่อย แต่ก็ยังบ่อยเกินไป) ให้จับหมวกของคุณไว้ อาจใช้เวลาอย่างน้อยหนึ่งนาที นี่เป็นปัญหาอย่างยิ่งสำหรับบริการที่พยายาม จำกัด เวลาแฝงสูงสุด แทนที่จะใช้เวลาพูดว่า 25 มิลลิวินาทีในการตอบสนองคำขอตอนนี้ใช้เวลาสิบวินาทีขึ้นไป หากต้องการเพิ่มการบาดเจ็บจากการดูถูกลูกค้าจากนั้นมักจะหมดเวลาการร้องขอและลองใหม่ซึ่งจะนำไปสู่ปัญหาต่อไป (หรือที่เรียกว่า "พายุอึ")
นี่เป็นพื้นที่หนึ่งที่ G1 หวังว่าจะช่วยได้มาก ฉันทำงานให้กับ บริษัท ใหญ่ที่ให้บริการคลาวด์สำหรับการจัดเก็บและการจัดส่งข้อความ และเราไม่สามารถใช้ CMS ได้เนื่องจากแม้ว่าเวลาส่วนใหญ่จะทำงานได้ดีกว่าพันธุ์คู่ขนาน แต่ก็มีการล่มสลายเหล่านี้ ประมาณหนึ่งชั่วโมงสิ่งที่ดี; จากนั้นสิ่งต่างๆก็เข้าสู่พัดลม ... และเนื่องจากการบริการเป็นไปตามคลัสเตอร์เมื่อโหนดหนึ่งมีปัญหาคนอื่น ๆ มักจะตามมา (เนื่องจากการหมดเวลาที่เกิดจาก GC ทำให้โหนดอื่น ๆ เชื่อว่าโหนดขัดข้องทำให้เกิดการเปลี่ยนเส้นทางใหม่)
ฉันไม่คิดว่า GC เป็นปัญหาสำหรับแอปมากนักและบางทีบริการที่ไม่ใช่คลัสเตอร์ก็มักไม่ค่อยได้รับผลกระทบ แต่มีการรวมระบบมากขึ้นเรื่อย ๆ (โดยเฉพาะต้องขอบคุณที่เก็บข้อมูล NoSQL) และขนาดฮีปก็เพิ่มมากขึ้น OldGen GCs มีความสัมพันธ์เชิงเส้นตรงกับขนาดฮีป (หมายความว่าการเพิ่มขนาดฮีปเป็นสองเท่ามากกว่าเวลา GC สองเท่าโดยสมมติว่าขนาดของชุดข้อมูลสดจะเพิ่มเป็นสองเท่าด้วย)
Gil Tene CTO ของ Azul มีภาพรวมที่ดีเกี่ยวกับปัญหาที่เกี่ยวข้องกับ Garbage Collection และการทบทวนวิธีแก้ปัญหาต่างๆในการนำเสนอการทำความเข้าใจ Java Garbage Collection และสิ่งที่คุณสามารถทำได้เกี่ยวกับการนำเสนอและมีรายละเอียดเพิ่มเติมในบทความนี้: http: // www.infoq.com/articles/azul_gc_in_detail
เครื่องเก็บขยะ C4 ของ Azul ใน Zing JVM ของเรามีทั้งแบบขนานและแบบพร้อมกันและใช้กลไก GC เดียวกันสำหรับทั้งรุ่นใหม่และรุ่นเก่าซึ่งทำงานพร้อมกันและกระชับในทั้งสองกรณี ที่สำคัญที่สุด C4 ไม่มีการถอยกลับแบบหยุดโลก การบดอัดทั้งหมดจะดำเนินการพร้อมกับแอปพลิเคชันที่ทำงานอยู่ เรามีลูกค้าที่ใช้งานขนาดใหญ่มาก (หลายร้อย GBytes) โดยมีกรณีที่แย่กว่านั้น GC เวลาหยุดชั่วคราวที่ <10 msec และขึ้นอยู่กับแอปพลิเคชันซึ่งมักจะน้อยกว่า 1-2 msec
ปัญหาเกี่ยวกับ CMS และ G1 คือเมื่อถึงจุดหนึ่งหน่วยความจำฮีพ Java จะต้องถูกบีบอัดและตัวรวบรวมขยะทั้งสองนั้นหยุดโลก / STW (เช่นหยุดแอปพลิเคชันชั่วคราว) เพื่อทำการบดอัด ดังนั้นในขณะที่ CMS และ G1 สามารถผลัก STW หยุดชั่วคราวได้ แต่จะไม่กำจัดออก อย่างไรก็ตาม C4 ของ Azul กำจัดการหยุดของ STW ได้อย่างสมบูรณ์และนั่นคือสาเหตุที่ Zing มี GC หยุดชั่วคราวแม้ในขนาดฮีปขนาดมหึมา
และเพื่อแก้ไขคำสั่งในคำตอบก่อนหน้านี้ Zing ไม่ต้องการการเปลี่ยนแปลงใด ๆ ในระบบปฏิบัติการ มันทำงานเหมือนกับ JVM อื่น ๆ บน Linux distros ที่ไม่ได้แก้ไข
เราใช้ G1GC อยู่แล้วตั้งแต่เกือบสองปี มันทำงานได้ยอดเยี่ยมในระบบประมวลผลธุรกรรมที่สำคัญของภารกิจของเราและได้รับการพิสูจน์แล้วว่าให้การสนับสนุนที่ยอดเยี่ยมในการรับส่งข้อมูลสูงการหยุดชั่วคราวต่ำการทำงานพร้อมกันและการจัดการหน่วยความจำหนัก
เรากำลังใช้การตั้งค่า JVM ต่อไปนี้:
-server -Xms512m -Xmx3076m -XX:NewRatio=50 -XX:+HeapDumpOnOutOfMemoryError -XX:+UseG1GC -XX:+AggressiveOpts -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000 -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime
อัปเดตแล้ว
-d64 -server -Xss4m -Xms1024m -Xmx4096m -XX:NewRatio=50 -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:-DisableExplicitGC -XX:+AggressiveOpts -Xnoclassgc -XX:+UseNUMA -XX:+UseFastAccessorMethods -XX:ReservedCodeCacheSize=48m -XX:+UseStringCache -XX:+UseStringDeduplication -XX:MaxGCPauseMillis=400 -XX:GCPauseIntervalMillis=8000
ตัวสะสม G1 ช่วยลดผลกระทบของคอลเล็กชันทั้งหมด หากคุณมีแอปพลิเคชั่นที่คุณลดความต้องการคอลเลกชันแบบเต็มแล้วตัวเก็บกวาดแผนที่พร้อมกันนั้นดีพอ ๆ กันและจากประสบการณ์ของฉันมีเวลาในการรวบรวมน้อยกว่า
ฉันเพิ่งถูกย้ายจาก
CMS เพื่อ G1GC กับ 4G กองและหน่วยประมวลผลหลัก 8 บนเซิร์ฟเวอร์ที่มี JDK 1.7.45
(JDK 1.8.x G1GC เป็นที่ต้องการมากกว่า 1.7 แต่เนื่องจากข้อ จำกัด บางประการฉันต้องยึดติดกับเวอร์ชัน 1.7.45)
ฉันได้กำหนดค่าพารามิเตอร์หลักด้านล่างและเก็บพารามิเตอร์อื่น ๆ ทั้งหมดเป็นค่าเริ่มต้น
-XX:G1HeapRegionSize=n, XX:MaxGCPauseMillis=m, -XX:ParallelGCThreads=n,
-XX:ConcGCThreads=n apart from -Xms and -Xmx
หากคุณต้องการปรับแต่งพารามิเตอร์เหล่านี้ให้ดูที่บทความoracleนี้
ข้อสังเกตที่สำคัญ:
แต่ฉันก็ยังมีความสุขที่เวลาหยุด Max GC น้อยกว่า CMS ฉันตั้งค่าเวลาหยุด GC สูงสุดเป็น1.5 วินาทีและยังไม่ข้ามค่านี้
คำถาม SE ที่เกี่ยวข้อง:
CMS สามารถทำให้ประสิทธิภาพลดลงอย่างช้าๆแม้ว่าคุณจะเรียกใช้โดยไม่สะสมวัตถุที่ยึดติด นี่เป็นเพราะการกระจายตัวของหน่วยความจำซึ่ง G1 ควรหลีกเลี่ยง
ตำนานเกี่ยวกับ G1 ที่มีให้เฉพาะกับการสนับสนุนแบบชำระเงินนั้นเป็นเพียงตำนาน Sun และตอนนี้ Oracle ได้ชี้แจงเรื่องนี้ในหน้า JDK
G1 GC ควรจะทำงานได้ดีขึ้น แต่หากตั้งค่า -XX: MaxGCPauseMillis มากเกินไปขยะจะถูกรวบรวมช้าเกินไป และนั่นคือสาเหตุที่ GC เต็มรูปแบบถูกเรียกใช้ในตัวอย่างของ David Leppik
ฉันเพิ่งติดตั้ง G1 Garbage Collector ในโครงการ Terracotta Big Memory ของเรา ในขณะที่ทำงานกับนักสะสมประเภทต่างๆ G1 ทำให้เราได้ผลลัพธ์ที่ดีที่สุดโดยมีเวลาตอบสนองน้อยกว่า 600ms
คุณสามารถดูผลการทดสอบ (ทั้งหมด 26 รายการ) ได้ที่นี่
หวังว่าจะช่วยได้
ฉันเพิ่งย้ายส่วนหนึ่งของ Twicsy ไปยังเซิร์ฟเวอร์ใหม่ที่มี RAM 128GB และตัดสินใจใช้ 1.7 ฉันเริ่มต้นโดยใช้การตั้งค่าหน่วยความจำแบบเดียวกับที่ฉันใช้กับ 1.6 (ฉันมีหลายอินสแตนซ์ที่ใช้งานได้หลายอย่างตั้งแต่ 500MB ของฮีปจนถึง 15GB และตอนนี้เป็นแบบใหม่ที่มี 40GB) และนั่นก็ไม่ได้ผลเลย . 1.7 ดูเหมือนว่าจะใช้ฮีปมากกว่า 1.6 และฉันพบปัญหามากมายในช่วงสองสามวันแรก ฉันโชคดีที่มี RAM เหลือเฟือที่จะทำงานร่วมกับ RAM สำหรับกระบวนการส่วนใหญ่ของฉัน แต่ก็ยังมีปัญหาอยู่ MO ปกติของฉันคือใช้ขนาดฮีปขั้นต่ำที่เล็กมากคือ 16m แม้จะมีฮีปสูงสุดหลายกิกะไบต์จากนั้นเปิด GC ที่เพิ่มขึ้น สิ่งนี้ทำให้หยุดชั่วคราวอย่างน้อยที่สุด ตอนนี้ใช้ไม่ได้แล้วและฉันต้องเพิ่มขนาดขั้นต่ำเป็นประมาณที่ฉันคาดว่าจะใช้โดยเฉลี่ยในฮีป และได้ผลดีมาก ฉันยังคงเปิด GC แบบเพิ่มหน่วยอยู่ แต่ฉันจะพยายามโดยไม่ใช้ ไม่มีการหยุด แต่อย่างใดในตอนนี้และดูเหมือนว่าสิ่งต่างๆจะดำเนินไปอย่างรวดเร็ว ดังนั้นฉันคิดว่าคุณธรรมของเรื่องนี้ไม่ได้คาดหวังว่าการตั้งค่าหน่วยความจำของคุณจะแปลได้อย่างสมบูรณ์แบบจาก 1.6 เป็น 1.7
G1 ทำให้แอปพลิเคชันคล่องตัวขึ้นมาก: เวลาแฝงของแอปพลิเคชันจะเพิ่มขึ้น - แอปสามารถตั้งชื่อเป็น "ซอฟต์ - เรียลไทม์" ได้ สิ่งนี้ทำได้โดยการเปลี่ยนการวิ่ง GC สองประเภท (ขนาดเล็กรองและหนึ่งตัวใหญ่ใน Tenured Gen) เป็นขนาดเล็กที่เท่ากัน
ดูรายละเอียดเพิ่มเติมได้ที่: http://geekroom.de/java/java-expertise-g1-fur-java-7/
ฉันกำลังทำงานกับ Java สำหรับ Heap ขนาดเล็กและขนาดใหญ่และคำถามเกี่ยวกับ GC และ Full GC ปรากฏขึ้นทุกวันเนื่องจากข้อ จำกัด อาจเข้มงวดกว่าข้ออื่น ๆ : ในบางสภาพแวดล้อม 0.1 วินาทีของ GC ในการเก็บกวาดหรือ GC เต็มฆ่า เพียงแค่fonctionnalitéและมีการกำหนดค่าและความสามารถอย่างละเอียดเป็นสิ่งสำคัญ (CMS, iCMS, อื่น ๆ ... เป้าหมายอยู่ที่นี่เพื่อให้มีเวลาตอบสนองที่ดีที่สุดเท่าที่จะเป็นไปได้ด้วยการรักษาแบบเกือบเรียลไทม์ (ในที่นี้การรักษาแบบเรียลไทม์มักจะอยู่ที่ 25 ms) ดังนั้นโดยพื้นฐานแล้วการปรับปรุงใด ๆ ในการยศาสตร์ GC ans heuristique ยินดีต้อนรับ!
ฉันใช้ G1GC บน Java 8 และกับ Groovy (เช่น Java 8) และฉันกำลังทำเวิร์กโหลดหลายประเภทและ G1GC โดยทั่วไปจะทำงานเช่นนี้:
การใช้หน่วยความจำต่ำมากเช่น 100MB แทนที่จะเป็น 500MB เมื่อเทียบกับการตั้งค่า Java เริ่มต้น
เวลาตอบสนองสม่ำเสมอและต่ำมาก
ประสิทธิภาพระหว่างการตั้งค่าเริ่มต้นและ G1GC จะช้าลง 20% เมื่อใช้ G1GC ในกรณีที่เลวร้ายที่สุด (โดยไม่ต้องปรับแต่งแอปพลิเคชันเธรดเดียว) ไม่มากนักเมื่อพิจารณาถึงเวลาตอบสนองที่ดีและการใช้หน่วยความจำต่ำ
เมื่อเรียกใช้จาก Tomcat ซึ่งเป็นแบบมัลติเธรดประสิทธิภาพโดยรวมจะดีขึ้น 30% และการใช้หน่วยความจำก็ลดลงมากเช่นกันเวลาในการตอบสนองจะต่ำกว่ามาก
ดังนั้นโดยรวมแล้วเมื่อใช้เวิร์กโหลดที่หลากหลาย G1GC จึงเป็นคอลเลกชันที่ดีมากสำหรับ Java 8 สำหรับแอพพลิเคชั่นแบบมัลติเธรดและแม้กระทั่งสำหรับเธรดเดียวก็ยังมีประโยชน์อยู่บ้าง
ไม่แนะนำให้ใช้ java8 w / G1GC สำหรับการคำนวณจุดลอยด้วย JVM ที่เหมือนฮอตสปอต เป็นอันตรายต่อความสมบูรณ์และความแม่นยำของแอปพลิเคชัน
https://bugs.openjdk.java.net/browse/JDK-8148175
JDK-8165766
JDK-8186112