จำนวนไฟล์ที่เปิดสูงสุดที่อนุญาตสูงสุดใน Linux

มีข้อ จำกัด ทางเทคนิคหรือทางปฏิบัติหรือไม่ในการที่คุณสามารถกำหนดค่าจำนวนไฟล์สูงสุดที่เปิดใน Linux ได้หรือไม่? มีผลข้างเคียงบ้างไหมถ้าคุณตั้งค่าเป็นจำนวนมาก (พูด 1-100M)?

ฉันคิดว่าการใช้เซิร์ฟเวอร์ที่นี่ไม่ใช่ระบบฝังตัว แน่นอนว่าโปรแกรมที่ใช้ไฟล์เปิดจำนวนมากสามารถกินหน่วยความจำและช้า แต่ฉันสนใจผลข้างเคียงหากมีการกำหนดขีด จำกัด ที่ใหญ่กว่าที่จำเป็น (เช่นหน่วยความจำที่ใช้โดยการกำหนดค่า)

ฉันสงสัยว่าเหตุผลหลักสำหรับข้อ จำกัด คือการหลีกเลี่ยงการใช้หน่วยความจำส่วนเกิน (ตัวอธิบายไฟล์ที่เปิดแต่ละไฟล์ใช้หน่วยความจำเคอร์เนล) นอกจากนี้ยังทำหน้าที่ป้องกันแอพพลิเคชั่น buggy ที่รั่วไหลออกมาอธิบายไฟล์และใช้ทรัพยากรของระบบ

แต่เมื่อเทียบกับระบบที่ทันสมัยของ RAM เมื่อเปรียบเทียบกับระบบเมื่อ 10 ปีที่แล้วผมคิดว่าค่าเริ่มต้นในปัจจุบันค่อนข้างต่ำ

ในปี 2011 วงเงินยากเริ่มต้นสำหรับการอธิบายไฟล์บน Linux ได้รับการเพิ่มขึ้น 1,024-4,096

ซอฟต์แวร์บางตัว (เช่น MongoDB) ใช้ตัวอธิบายไฟล์มากกว่าข้อ จำกัด เริ่มต้น ชาว MongoDB ขอแนะนำให้เพิ่มวงเงินนี้ 64,000 ฉันใช้ไปแล้วrlimit_nofile300,000 รายการสำหรับบางแอปพลิเคชัน

ตราบใดที่คุณยังคงขีด จำกัด ซอฟต์ไว้ที่ค่าเริ่มต้น (1024) มันอาจจะค่อนข้างปลอดภัยที่จะเพิ่มขีด จำกัด ฮาร์ด โปรแกรมจะต้องโทรsetrlimit()เพื่อที่จะเพิ่มขีด จำกัด ของพวกเขาสูงกว่าขีด จำกัด อ่อนและยังคงถูก จำกัด โดยขีด จำกัด ฮาร์ด

ดูคำถามที่เกี่ยวข้อง:

• /server/356962/where-are-the-default-ulimit-values-set-linux-centos
• /server/773609/how-do-ulimit-settings-impact-linux

ผลกระทบจะไม่สามารถสังเกตเห็นได้ตามปกติ แต่โมดูล IO ของเคอร์เนลจะต้องดูแลตัวอธิบายไฟล์แบบเปิดทั้งหมดและอาจส่งผลต่อประสิทธิภาพของแคช

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

หากคุณไม่มีเหตุผลที่ชัดเจนในการเพิ่มขีด จำกัด เหล่านั้นคุณควรหลีกเลี่ยงและนอนหลับให้ดีขึ้น

มันถูก จำกัด ทางเทคนิคกับค่าสูงสุดของ long long ที่ไม่ได้ลงชื่อ (C Lang) คือ 4,294,967,295

การอ้างอิง: fs.hไฟล์

/* And dynamically-tunable limits and defaults: */
struct files_stat_struct {
  unsigned long nr_files;   /* read only */
  unsigned long nr_free_files;  /* read only */
  unsigned long max_files;    /* tunable THIS IS OUR VALUE */
};

ฉันคิดว่าข้อกังวลของคุณนั้นเข้าใจได้ แต่ส่วนใหญ่ลีนุกซ์จะไม่ใช้หน่วยความจำมากนักในการกำหนดค่า (แต่ไม่ได้ใช้ file descriptors) :)

ฉันจำปัญหานี้ไม่ได้ในอาชีพการงานของฉันในช่วง 10 ปีที่ผ่านมา

ความนับถือ.

เงียบช้า แต่สิ่งนี้จะช่วยให้ทุกคนได้รับคำตอบสำหรับคำถามนี้ ข้อ จำกัด การใช้งานจริงสำหรับจำนวนไฟล์ที่เปิดใน linux สามารถนับได้โดยใช้จำนวนตัวอธิบายไฟล์สูงสุดที่กระบวนการสามารถเปิดได้

ฉันเห็นข้อ จำกัด ที่เปลี่ยนจากระบบเป็นระบบ จากหน้าคนgetlimitคุณจะเห็นว่าRLIMIT_NOFILE-1ระบุข้อ จำกัด ภายใน

ในการตรวจสอบค่า RLIMIT_NOFILE คุณสามารถใช้คำสั่งด้านล่างเพื่อรับ tuple

python -c "import resource; print(resource.getrlimit(resource.RLIMIT_NOFILE))"

tuple ส่งคืนผลลัพธ์เป็น (Soflimit, hardlimit) สำหรับฉันที่ใช้ระบบหลาย ๆ ผลจะเป็นดังนี้

(1024, 1048576) # on UBUNTU linux 
(65536, 65536)  # on amazon linux 
(1024, 9223372036854775807) # on macos 

หมายเหตุ: 9223372036854775807 ตัวเลขนี้หมายถึงอนันต์ คุณจะถึงขีด จำกัด ทรัพยากรอื่น ๆ เสมอก่อนที่คุณจะทำสิ่งนี้ หากคุณแก้ไข hardlimit บนระบบเกินกว่าที่เป็นอยู่คุณจะต้องแก้ไขเคอร์เนลพารามิเตอร์