ทำไมจำนวนไฟล์ที่เปิดอยู่ จำกัด ใน Linux?


136

ตอนนี้ฉันรู้วิธี:

  • ค้นหาการ จำกัด การเปิดไฟล์ต่อกระบวนการ: ulimit -n
  • นับจำนวนไฟล์ที่เปิดทั้งหมดโดยกระบวนการทั้งหมด: lsof | wc -l
  • รับจำนวนไฟล์ที่เปิดสูงสุดที่อนุญาต: cat /proc/sys/fs/file-max

คำถามของฉันคือเหตุใดจึงมีข้อ จำกัด ของไฟล์ที่เปิดอยู่ใน Linux?


2
@ Rob Googled นิดหน่อยและพบว่ามันเป็นfork Bombมันสามารถใช้อธิบายการเปิดไฟล์ได้หรือไม่?
xanpeng

6
การ จำกัด กระบวนการและการ จำกัด ไฟล์มีความสำคัญดังนั้นสิ่งต่าง ๆ เช่น fork bombs จะไม่ทำลายเซิร์ฟเวอร์ / คอมพิวเตอร์สำหรับผู้ใช้ทุกคนเฉพาะผู้ใช้ที่ทำมันและชั่วคราวเท่านั้น มิเช่นนั้นบางคนบนเซิร์ฟเวอร์ที่ใช้ร่วมกันสามารถตั้งค่า forkbomb และทำให้ล้มลงอย่างสมบูรณ์สำหรับผู้ใช้ทุกคนไม่ใช่แค่ตัวเอง
Rob

3
คำศัพท์ที่ดีมีประโยชน์ : +1:
Joshua Pinter

7
@Rob, fork bomb ไม่มีส่วนเกี่ยวข้องใด ๆ เนื่องจากขีด จำกัด ของไฟล์เป็นไปตามกระบวนการและทุกครั้งที่คุณแยกไฟล์จะไม่เปิดตัวจัดการไฟล์ใหม่
psusi

คำตอบ:


86

เหตุผลคือระบบปฏิบัติการต้องการหน่วยความจำในการจัดการแต่ละไฟล์ที่เปิดอยู่และหน่วยความจำเป็นทรัพยากรที่ จำกัด - โดยเฉพาะในระบบฝังตัว

ในฐานะผู้ใช้รูทคุณสามารถเปลี่ยนจำนวนไฟล์ที่เปิดสูงสุดต่อกระบวนการ (ผ่านulimit -n) และต่อระบบ (เช่นecho 800000 > /proc/sys/fs/file-max)


21
นอกจากนี้ยังมีเหตุผลด้านความปลอดภัย: หากไม่มีข้อ จำกัด ซอฟต์แวร์ userland จะสามารถสร้างไฟล์ได้ไม่สิ้นสุดจนกว่าเซิร์ฟเวอร์จะหยุดทำงาน
Coren

15
@Coren ข้อ จำกัด ที่กล่าวถึงที่นี่มีไว้สำหรับการนับตัวจัดการไฟล์ที่เปิดเท่านั้น เนื่องจากโปรแกรมสามารถปิดตัวจัดการไฟล์ได้มันสามารถสร้างไฟล์ได้มากและใหญ่เท่าที่ต้องการจนกว่าพื้นที่ว่างในดิสก์จะเต็ม เพื่อป้องกันสิ่งนี้คุณสามารถใช้โควต้าดิสก์หรือพาร์ติชันที่แยกจากกัน คุณเป็นความจริงในแง่หนึ่งว่าการรักษาความปลอดภัยด้านหนึ่งคือการป้องกันความอ่อนล้าของทรัพยากร - และสำหรับสิ่งนี้มีข้อ จำกัด
jofel

1
@jofel ขอบคุณ ฉันเดาว่าการจัดการไฟล์ที่เปิดอยู่จะแสดงด้วยอินสแตนซ์ของไฟล์ structและขนาดของ struct นี้มีขนาดค่อนข้างเล็ก (ระดับไบต์) ดังนั้นฉันจะตั้งค่า/.../file-maxที่ค่อนข้างใหญ่ได้นานเท่าใดหากหน่วยความจำไม่ได้ใช้งาน?
xanpeng

7
@xanpeng ฉันไม่ใช่ผู้เชี่ยวชาญเกี่ยวกับเคอร์เนล แต่เท่าที่ฉันเห็นค่าเริ่มต้นสำหรับfile-maxขนาด RAM ดูเหมือนจะหารด้วย 10k เนื่องจากหน่วยความจำจริงที่ใช้ต่อตัวจัดการไฟล์ควรมีขนาดเล็กกว่ามาก (ขนาดของstruct fileบวกกับหน่วยความจำขึ้นอยู่กับไดรเวอร์บางตัว) นี่จึงเป็นข้อ จำกัด ที่ค่อนข้างอนุรักษ์นิยม
jofel

63

โปรดทราบว่าlsof | wc -lผลรวมของรายการที่ซ้ำกันจำนวนมาก (กระบวนการทางแยกสามารถใช้ร่วมกันจัดการไฟล์ ฯลฯ ) /proc/sys/fs/file-maxตัวเลขที่อาจจะสูงกว่าวงเงินที่ตั้งไว้ใน

ในการรับจำนวนไฟล์ที่เปิดในปัจจุบันจากมุมมองของเคอร์เนล Linux ให้ทำดังนี้:

cat /proc/sys/fs/file-nr

ตัวอย่าง: เซิร์ฟเวอร์นี้มี 40096 จากสูงสุด 65536 ไฟล์ที่เปิดแม้ว่า lsof รายงานจำนวนมากขึ้น:

# cat /proc/sys/fs/file-max
65536
# cat /proc/sys/fs/file-nr 
40096   0       65536
# lsof | wc -l
521504

1
ตามที่lsofจะรายงานไฟล์จำนวนมากสองครั้งหรือมากกว่าเช่น/dev/nullคุณสามารถลองเดาได้ดีที่สุดด้วย:lsof|awk '{print $9}'|sort|uniq|wc -l
Yvan

คุณอาจใช้lsof|awk '!a[$NF]++{c++}END{print c}'เพื่อรับจำนวนการเปิดที่ไม่ซ้ำกัน
....

18

ฉันคิดว่าส่วนใหญ่เป็นเพราะเหตุผลทางประวัติศาสตร์

บ่งแฟ้ม Unix มีขนาดเล็กintค่าส่งกลับโดยฟังก์ชั่นเหมือนopenและcreatและส่งผ่านไปยังread, write, closeและอื่น ๆ

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

ระบบที่ทันสมัยกว่านั้นมีขีด จำกัด ที่สูงกว่า แต่ก็ยังคงรักษารูปแบบทั่วไปไว้เหมือนเดิมโดยส่วนใหญ่มาจากความเฉื่อย


1
20 เป็นขีด จำกัด ของ Solaris สำหรับโครงสร้างข้อมูลไฟล์ภาษา C จำนวนการจัดการไฟล์นั้นใหญ่กว่าเสมอ
Lothar

@ Lothar: น่าสนใจ ฉันสงสัยว่าทำไมขีด จำกัด จึงแตกต่างกัน รับfilenoและfdopenฟังก์ชั่นที่ฉันคาดหวังว่าพวกเขาจะเปลี่ยนกันได้เกือบ
Keith Thompson

ไฟล์ unix เป็นมากกว่าการจัดการไฟล์ (int) ที่ส่งคืน มีบัฟเฟอร์ดิสก์และบล็อกควบคุมไฟล์ที่กำหนดออฟเซ็ตไฟล์ปัจจุบันเจ้าของไฟล์สิทธิ์ inode และอื่น ๆ
ChuckCottrill

@ChuckCottrill: ใช่แน่นอน แต่ส่วนมากของข้อมูลที่ได้จะถูกเก็บไว้ไม่ว่าจะเป็นไฟล์ที่มีการเข้าถึงผ่านการให้คำอธิบายหรือint FILE*หากคุณเปิดไฟล์มากกว่า 20 ไฟล์open()จะfdopen()ล้มเหลวหรือไม่
Keith Thompson
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.