Ehcache พูดถึงหน่วยความจำแบบ on-heap และ off-heap อะไรคือความแตกต่าง? JVM args ใดที่ใช้เพื่อกำหนดค่า
คำตอบ:
ที่เก็บบน heap หมายถึงวัตถุที่จะมีอยู่ใน Java heap (และยังขึ้นอยู่กับ GC) ในทางกลับกันที่เก็บ off-heap อ้างถึงวัตถุ (ต่อเนื่อง) ที่จัดการโดย EHCache แต่เก็บไว้นอก heap (และไม่รวมอยู่ใน GC) เนื่องจากที่เก็บ off-heap ยังคงได้รับการจัดการในหน่วยความจำมันจะช้ากว่าร้านค้าแบบ on-heap เล็กน้อย แต่ก็ยังเร็วกว่าที่เก็บดิสก์
รายละเอียดภายในที่เกี่ยวข้องกับการจัดการและการใช้งานของ off-heap store นั้นไม่ปรากฏในลิงก์ที่โพสต์ในคำถามดังนั้นจึงควรตรวจสอบรายละเอียดของTerracotta BigMemoryซึ่งใช้สำหรับจัดการ off-disk เก็บ. BigMemory (off-heap store) จะถูกใช้เพื่อหลีกเลี่ยงโอเวอร์เฮดของ GC ในฮีปที่มีหลายเมกะไบต์หรือกิกะไบต์ใหญ่ BigMemory ใช้พื้นที่ที่อยู่หน่วยความจำของกระบวนการ JVM ผ่านByteBuffers โดยตรงที่ไม่อยู่ภายใต้ GC ซึ่งแตกต่างจากวัตถุ Java ดั้งเดิมอื่น ๆ
จากhttp://code.google.com/p/fast-serialization/wiki/QuickStartHeapOff
Heap-Offloading คืออะไร
โดยปกติวัตถุที่ไม่ใช่ชั่วคราวทั้งหมดที่คุณจัดสรรจะได้รับการจัดการโดยตัวรวบรวมขยะของ java แม้ว่า VM จะทำงานได้ดีในการเก็บรวบรวมขยะ แต่ ณ จุดหนึ่ง VM ก็ต้องทำสิ่งที่เรียกว่า 'Full GC' GC เต็มรูปแบบเกี่ยวข้องกับการสแกน Heap ที่จัดสรรสมบูรณ์ซึ่งหมายความว่า GC การหยุดชั่วคราว / การชะลอตัวเป็นสัดส่วนกับขนาดฮีปของแอปพลิเคชัน ดังนั้นอย่าเชื่อถือใครก็ตามที่บอกคุณว่า 'ความจำราคาถูก' ในการใช้หน่วยความจำจาวาเจ็บประสิทธิภาพ นอกจากนี้คุณอาจได้หยุดชั่วคราวด้วยขนาดฮีป> 1 Gb สิ่งนี้อาจน่ารังเกียจหากคุณมีสิ่งที่เกิดขึ้นแบบเรียลไทม์ในคลัสเตอร์หรือกริดกระบวนการ java อาจไม่ตอบสนองและหลุดออกจากคลัสเตอร์
อย่างไรก็ตามแอปพลิเคชันเซิร์ฟเวอร์ในปัจจุบัน (สร้างขึ้นบ่อย ๆ บนเฟรมเวิร์ก bloaty ;-)) ต้องการฮีปที่เกิน 4Gb ได้อย่างง่ายดาย
ทางออกหนึ่งสำหรับความต้องการหน่วยความจำเหล่านี้คือการ 'ถ่ายข้อมูล' ส่วนของวัตถุไปยังฮีปที่ไม่ใช่จาวา (จัดสรรโดยตรงจากระบบปฏิบัติการ) โชคดีที่ java.nio จัดเตรียมคลาสเพื่อจัดสรร / อ่านและเขียนหน่วยความจำ 'ที่ไม่มีการจัดการ' โดยตรง (แม้แต่ไฟล์ที่แม็พหน่วยความจำ)
ดังนั้นหนึ่งสามารถจัดสรรหน่วยความจำ 'ไม่ได้จัดการ' จำนวนมากและใช้สิ่งนี้เพื่อบันทึกวัตถุที่นั่น เพื่อบันทึกวัตถุโดยพลการลงในหน่วยความจำที่ไม่มีการจัดการทางออกที่ทำงานได้มากที่สุดคือการใช้อนุกรม ซึ่งหมายความว่าแอปพลิเคชันจะทำให้วัตถุเป็นอนุกรมในหน่วยความจำ offheap ในภายหลังบนวัตถุสามารถอ่านได้โดยใช้
ขนาดฮีพที่จัดการโดย java VM สามารถเก็บไว้เล็กดังนั้น GC หยุดชั่วคราวอยู่ในมิลลิวินาทีทุกคนมีความสุขทำงานเสร็จแล้ว
เป็นที่ชัดเจนว่าประสิทธิภาพของบัฟเฟอร์ฮีปปิดนั้นขึ้นอยู่กับประสิทธิภาพของการใช้การทำให้เป็นอนุกรม ข่าวดี: ด้วยเหตุผลบางอย่าง FST-serialization ค่อนข้างเร็ว :-)
สถานการณ์การใช้งานตัวอย่าง:
แก้ไข: สำหรับบางสถานการณ์หนึ่งอาจเลือกอัลกอริทึม Garbage Collection ที่ซับซ้อนยิ่งขึ้นเช่น ConcurrentMarkAndSweep หรือ G1 เพื่อสนับสนุนฮีปที่ใหญ่ขึ้น (แต่นี่ยังมีข้อ จำกัด เกินกว่าฮีป 16GB) นอกจากนี้ยังมี JVM เชิงพาณิชย์พร้อม GC แบบ 'หยุดชั่วคราว' ที่ได้รับการปรับปรุงให้ดีขึ้น
ฮีปคือสถานที่ในหน่วยความจำที่มีการจัดสรรออบเจ็กต์แบบไดนามิกของคุณ ถ้าคุณใช้newแล้วมันอยู่ในกอง ซึ่งตรงกันข้ามกับพื้นที่สแต็คซึ่งเป็นที่ที่สแต็กของฟังก์ชันมีชีวิต หากคุณมีตัวแปรโลคัลการอ้างอิงนั้นอยู่บนสแต็ก กองของ Java นั้นขึ้นอยู่กับการรวบรวมขยะและวัตถุนั้นสามารถใช้งานได้โดยตรง
ที่เก็บข้อมูลนอกฮีปของ EHCache จะลบวัตถุปกติของคุณออกจากฮีปทำให้เป็นอนุกรมและจัดเก็บเป็นไบต์ในหน่วยความจำจำนวนหนึ่งที่ EHCache จัดการ มันเหมือนเก็บไว้ในดิสก์ แต่ยังอยู่ใน RAM วัตถุไม่สามารถใช้งานได้โดยตรงในสถานะนี้พวกเขาจะต้องทำการดีซีเรียลไลซ์ก่อน ยังไม่ได้รับการเก็บขยะ
JVM ไม่รู้อะไรเลยเกี่ยวกับหน่วยความจำแบบ off-heap Ehcache ใช้แคชบนดิสก์เช่นเดียวกับแคชในหน่วยความจำ
ไม่ใช่ 100%; อย่างไรก็ตามดูเหมือนว่า heap เป็นวัตถุหรือชุดของพื้นที่ที่จัดสรร (บน RAM) ที่สร้างไว้ในฟังก์ชันการทำงานของโค้ดไม่ว่าจะเป็น Java เองหรือการทำงานที่เป็นไปได้มากขึ้นจาก ehcache และ off-heap Ram มีระบบของตัวเองเป็น ดี; แม้กระนั้นดูเหมือนว่านี่จะมีขนาดที่ช้ากว่าเพราะมันไม่ได้มีการจัดระเบียบหมายความว่ามันอาจไม่ใช้ฮีป (หมายถึงพื้นที่หน่วยความจำยาวหนึ่งชุด) และใช้พื้นที่แอดเดรสที่ต่างกันแทนซึ่งทำให้มีประสิทธิภาพน้อยลงเล็กน้อย
แน่นอนว่าระดับที่ต่ำกว่าถัดไปคือพื้นที่ฮาร์ดไดรฟ์
ฉันไม่ได้ใช้ ehcache ดังนั้นคุณอาจไม่อยากเชื่อใจฉัน แต่นั่นคือสิ่งที่ฉันรวบรวมจากเอกสารของพวกเขา
