ขีด จำกัด หน่วยความจำของเคอร์เนล Linux


12

ฉันมีปัญหาที่น่างง ฉันมีห้องสมุดที่ใช้sgสำหรับการดำเนินการ CDB ที่กำหนดเอง มีคู่ของระบบที่เป็นประจำมีปัญหาเกี่ยวกับการจัดสรรหน่วยความจำมีSG โดยปกติแล้วSGคนขับมีขีด จำกัด หนักประมาณ 4MB แต่ที่เราเห็นบนระบบไม่กี่เหล่านี้ด้วย ~ คำขอ 2.3mb นั่นคือ CDBs กำลังเตรียมที่จะจัดสรรสำหรับการถ่ายโอน 2.3mb ไม่ควรมีปัญหาใด ๆ ที่นี่: 2.3 <4.0

ทีนี้รายละเอียดของตัวเครื่อง มันเป็นซีพียู 64 บิต แต่รัน CentOS 6.0 32- บิต (ฉันไม่ได้สร้างพวกเขาหรือฉันไม่มีส่วนเกี่ยวข้องกับการตัดสินใจนี้) เคอร์เนลเวอร์ชันสำหรับ CentOS distro นี้คือ 2.6.32 พวกเขามี RAM 16gb

นี่คือลักษณะการใช้หน่วยความจำในระบบ (แต่เนื่องจากข้อผิดพลาดนี้เกิดขึ้นในระหว่างการทดสอบอัตโนมัติฉันยังไม่ได้ตรวจสอบหากสิ่งนี้สะท้อนถึงสถานะเมื่อ errno นี้ส่งคืนจากsg )

top - 00:54:46 up 5 days, 22:05,  1 user,  load average: 0.00, 0.01, 0.21
Tasks: 297 total,   1 running, 296 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  15888480k total,  9460408k used,  6428072k free,   258280k buffers
Swap:  4194296k total,        0k used,  4194296k free,  8497424k cached

ฉันพบบทความนี้จากLinux Journalซึ่งเกี่ยวกับการจัดสรรหน่วยความจำในเคอร์เนล บทความนี้เป็นวันที่ แต่ดูเหมือนจะเกี่ยวข้องกับ 2.6 (ความคิดเห็นบางประการเกี่ยวกับผู้เขียนที่หัว) บทความกล่าวถึงเคอร์เนลที่ถูก จำกัด ไว้ที่หน่วยความจำประมาณ 1gb (แม้ว่าจะไม่ชัดเจนโดยสิ้นเชิงจากข้อความหากแต่ละหน่วยความจำ 1GB สำหรับฟิสิคัลและเสมือนหรือทั้งหมด) ฉันสงสัยว่านี่เป็นคำสั่งที่ถูกต้องสำหรับ 2.6.32 หรือไม่ ในที่สุดฉันสงสัยว่าระบบเหล่านี้มีผลกระทบต่อขีด จำกัด นี้หรือไม่

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

คำตอบ:


21

ขีด จำกัด 1 GiB สำหรับหน่วยความจำเคอร์เนล Linux ในระบบ 32 บิตเป็นผลมาจากการกำหนดแอดเดรส 32 บิตและเป็นข้อ จำกัด ที่ค่อนข้างเข้มงวด มันเป็นไปไม่ได้ที่จะเปลี่ยนแปลง แต่มีเหตุผลที่ดีมาก การเปลี่ยนแปลงมันมีผลกระทบ

ลองนำเครื่อง wayback ไปยังต้นปี 1990 เมื่อ Linux ถูกสร้างขึ้น ย้อนกลับไปในวันนั้นเราจะมีข้อโต้แย้งเกี่ยวกับว่าลินุกซ์อาจจะทำให้การทำงานใน 2 เอ็มไอของแรมหรือถ้ามันจริงๆจำเป็น4 ทั้งเอ็มไอ แน่นอนว่า snobs ระดับไฮเอนด์ต่างก็แอบมาที่เราพร้อมกับเซิร์ฟเวอร์มอนสเตอร์ 16 MiB ของพวกเขา

บทความเล็ก ๆ น้อย ๆ ที่น่าสนใจเกี่ยวกับอะไร ในโลกนั้นมันเป็นเรื่องง่ายในการตัดสินใจเกี่ยวกับวิธีแบ่งพื้นที่ที่อยู่ 4 GiB ที่คุณได้รับจากการกำหนดที่อยู่ 32 บิตที่เรียบง่าย OSE บางตัวเพิ่งแยกครึ่งและรักษาบิตส่วนบนของที่อยู่เป็น "เคอร์เนลแฟล็ก": ที่อยู่ 0 ถึง 2 31 -1 ได้ล้างบิตสูงสุดและเป็นรหัสพื้นที่ผู้ใช้และที่อยู่ 2 31ถึง 2 32 - 1 มีชุดบิตสูงสุดและใช้สำหรับเคอร์เนล คุณสามารถดูที่อยู่แล้วบอกว่า: 0x80000000 ขึ้นไปเป็นเคอร์เนลสเปซมิฉะนั้นจะเป็นพื้นที่ผู้ใช้

เมื่อขนาดหน่วยความจำพีซีพุ่งขึ้นสู่ขีด จำกัด หน่วยความจำ 4 GiB การแบ่ง 2/2 แบบง่ายนี้เริ่มเป็นปัญหา พื้นที่ผู้ใช้และพื้นที่เคอร์เนลทั้งสองมีการเรียกร้องที่ดีใน RAM จำนวนมาก แต่เนื่องจากจุดประสงค์ของเราในการมีคอมพิวเตอร์โดยทั่วไปคือการรันโปรแกรมผู้ใช้แทนที่จะเรียกใช้เคอร์เนลระบบปฏิบัติการเริ่มเล่นกับผู้ใช้ / เคอร์เนลแบ่ง การแบ่ง 3/1 นั้นเป็นการประนีประนอมร่วมกัน

สำหรับคำถามของคุณเกี่ยวกับทางกายภาพ vs เสมือนจริง ๆ แล้วมันไม่สำคัญ ในทางเทคนิคแล้วมันเป็นการ จำกัด หน่วยความจำเสมือน แต่นั่นเป็นเพราะ Linux เป็นระบบปฏิบัติการบน VM การติดตั้งฟิสิคัลแรม 32 GiB จะไม่เปลี่ยนแปลงอะไรเลยและจะไม่ช่วยในswaponการสลับพาร์ติชั่น 32 GiB ไม่ว่าคุณจะทำอะไรเคอร์เนล Linux แบบ 32 บิตจะไม่สามารถจัดการกับมากกว่า 4 GiB พร้อมกันได้

(ใช่ฉันรู้เกี่ยวกับPAEแล้วตอนนี้ OS 64- บิตกำลังเข้ามาในที่สุดฉันหวังว่าเราจะเริ่มลืมแฮ็คที่น่ารังเกียจฉันไม่เชื่อว่ามันจะช่วยคุณได้ในกรณีนี้)

บรรทัดล่างคือถ้าคุณกำลังทำงานในขีด จำกัด VM เคอร์เนล 1 GiB คุณสามารถสร้างเคอร์เนลใหม่ด้วยการแบ่ง 2/2 แต่จะส่งผลโดยตรงต่อโปรแกรมพื้นที่ผู้ใช้

64 บิตเป็นคำตอบที่ถูกต้องจริงๆ


1
ขอบคุณ การเขียนนี้ดีมาก ฉันพบปัญหาการแยก 2/2 ที่ใช้กันทั่วไปใน Windows ในเวลานั้นฉันเรียนรู้ว่า Linux ใช้การแบ่ง 3/1 ฉันคิดว่าฉันจะคิดถึงสิ่งนั้นเมื่ออ่านบทความฉันคิดว่าฉันจะเชื่อมโยงจุดต่าง ๆ ดังนั้น ... ดูเหมือนว่าฉันจะต้องจำไว้ อาจไม่ไกลเกินเอื้อมที่จะคิดว่าระบบเหล่านี้มีข้อ จำกัด ในการพิจารณาลักษณะของการทดสอบ คำถามใหญ่ก็คือว่าทำไมระบบอื่นจึงไม่ประสบปัญหาเช่นนี้ ขอบคุณอีกครั้ง.
Andrew Falanga

1
@AndrewFalanga: จริง ๆ แล้ว Windows สมัยใหม่นั้นใช้การแบ่งแบบฝอย 3/1เช่นกัน
Warren Young

1
พวกเราบางคนสามารถรวมหน่วยความจำจากเครื่องที่แตกต่างกันสามเครื่องที่สืบทอดมาจาก SSC เพื่อรับเซิร์ฟเวอร์ 12 MB ดังนั้นมากหน่วยความจำที่เราสามารถทำสิ่งที่เราต้องการ ...
dmckee --- อดีตผู้ดูแลลูกแมว

3
"ใช่ฉันรู้เกี่ยวกับรูปแบบหน่วยความจำแบบแบ่งส่วน x86ตอนนี้ในที่สุดระบบปฏิบัติการแบบ 32 บิตก็เข้ามาแทนที่ฉันหวังว่าเราจะเริ่มลืมแฮ็คที่น่ารังเกียจ"
CVn

มีสองเท่าเป็นสองเท่าระหว่าง 32- และ 64- บิตระหว่าง 16-32 และ 32 เท่าซึ่งเท่ากับระยะเวลาที่เราต้องถอดแฮ็กดังกล่าวออกไป แต่สิ่งอื่นไม่เท่ากันสิ่งที่เกิดจากพระอาทิตย์ตกของกฎของมัวร์ เราได้สองทศวรรษจากการคำนวณ x86 แบบ 32 บิต เราอาจได้รับศตวรรษจาก 64 บิต A-ผ่านเดียวอ่าน2⁶⁴ไบต์ของแรมที่วันนี้แบนด์วิดท์ DRAM จะใช้เวลาประมาณ 30 ปีที่ผ่านมา การเพิ่มแบนด์วิดท์จะมาจากที่ใดเพื่อให้เราสามารถเข้าถึงขีด จำกัด 64 บิตได้
Warren Young

2

ฉันต้องการเพิ่มคำตอบที่ยอดเยี่ยมของ Warren Youngเพียงเล็กน้อยเพราะสิ่งต่าง ๆ เลวร้ายยิ่งกว่าที่เขาเขียน

พื้นที่แอดเดรสเคอร์เนล 1GB จะถูกแบ่งออกเป็นสองส่วนเพิ่มเติม 128MB มีการvmallocและ 896MB lowmemสำหรับ ไม่เป็นไรหรอกว่ามันหมายถึงอะไรจริง ๆ เมื่อทำการจัดสรรหน่วยความจำรหัสเคอร์เนลจะต้องเลือกว่าต้องการสิ่งใด คุณไม่สามารถรับหน่วยความจำจากพูลใดก็ตามที่มีพื้นที่ว่าง

หากคุณเลือกvmallocคุณถูก จำกัด ไว้ที่ 128MB ตอนนี้ 1GB ดูไม่เลวเลย ...

หากคุณเลือกlowmemคุณจะ จำกัด 896MB ไม่ไกลจาก 1GB แต่ในกรณีนี้การจัดสรรทั้งหมดจะถูกปัดเศษเป็นกำลังงานถัดไปของ 2 ดังนั้นการจัดสรร 2.3MB จะใช้จริง 4MB นอกจากนี้คุณไม่สามารถจัดสรรมากกว่า 4MB lowmemในหนึ่งสายเมื่อใช้

64 บิตเป็นคำตอบที่ถูกต้องจริงๆ


ฉันมีคำถามที่เกี่ยวข้องกับคำตอบของคุณ สำหรับพื้นที่หน่วยความจำชื่อlowmemนี้เป็นที่ที่หน่วยความจำจากการโทรเช่น kmalloc และ kzmalloc มาจากไหน?
Andrew Falanga

@AndrewFalanga ใช่ฟังก์ชั่นเหล่านี้ใช้ lowmem
ugoren
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.