लिनक्स में खुली फाइलों की संख्या सीमित क्यों है?

Question

अभी, मुझे पता है:

• प्रक्रिया के अनुसार खुली फ़ाइलों की सीमा खोजें: ulimit -n
• सभी प्रक्रियाओं द्वारा सभी खोली गई फ़ाइलों की गणना करें: lsof | wc -l
• खुली फ़ाइलों की अधिकतम अनुमत संख्या प्राप्त करें: cat /proc/sys/fs/file-max

मेरा सवाल है: लिनक्स में खुली फाइलों की सीमा क्यों है?

Comments

@ रब ने थोड़ा गुगला किया और पाया कि यह एक फोर्क बम है , क्या इसका उपयोग खुली फाइल की सीमा को समझाने के लिए किया जा सकता है?

— xanpeng

ठीक है, प्रक्रिया सीमा और फ़ाइल सीमाएँ महत्वपूर्ण हैं, इसलिए फोर्क बम जैसी चीजें सभी उपयोगकर्ताओं के लिए एक सर्वर / कंप्यूटर को नहीं तोड़ती हैं, केवल उपयोगकर्ता जो इसे करता है और केवल अस्थायी रूप से करता है। अन्यथा, एक साझा सर्वर पर कोई व्यक्ति एक forkbomb सेट कर सकता है और पूरी तरह से सभी उपयोगकर्ताओं के लिए इसे नॉक डाउन कर सकता है, न कि केवल स्वयं।

— रॉब

अच्छा एक कुछ बहुत ही उपयोगी आदेशों को संक्षेप में लिखें! : +1:

— जोशुआ पिंटर

@ रोब, एक फोर्क बम का इससे कोई लेना-देना नहीं है क्योंकि फ़ाइल सीमा प्रति प्रक्रिया है और हर बार जब आप कांटा लगाते हैं तो यह एक नया फ़ाइल हैंडल नहीं खोलता है।

— Psusi

Answer 1

कारण यह है कि ऑपरेटिंग सिस्टम को प्रत्येक खुली फ़ाइल का प्रबंधन करने के लिए मेमोरी की आवश्यकता होती है, और मेमोरी एक सीमित संसाधन है - विशेष रूप से एम्बेडेड सिस्टम पर।

रूट उपयोगकर्ता के रूप में आप प्रति प्रक्रिया (के माध्यम से ulimit -n) और प्रति सिस्टम (जैसे echo 800000 > /proc/sys/fs/file-max) की गणना की गई खुली फ़ाइलों की अधिकतम बदल सकते हैं ।

Comments

एक सुरक्षा कारण भी है: अगर कोई सीमा नहीं थी, तो एक उपयोगकर्ता सॉफ़्टवेयर तब तक फ़ाइलों को अंतहीन रूप से बनाने में सक्षम होगा जब तक कि सर्वर नीचे नहीं जाता है।

— कोरन

@Coren यहाँ चर्चा की गई सीमाएँ केवल खुले फ़ाइल संचालकों की गिनती के लिए हैं। एक प्रोग्राम के रूप में फाइल हैंडलर को भी बंद किया जा सकता है, यह तब तक कई फाइलें बना सकता है और जब तक सभी उपलब्ध डिस्क स्थान भरा हुआ है, तब तक यह जितना चाहें उतना बड़ा हो सकता है। इसे रोकने के लिए, आप डिस्क कोटा या अलग किए गए विभाजन का उपयोग कर सकते हैं। आप इस अर्थ में सही हैं, कि सुरक्षा का एक पहलू संसाधन थकावट को रोक रहा है - और इसके लिए सीमाएँ हैं।

— जॉफेल

@ जोफेल थैंक्स मुझे लगता है कि खोले गए फ़ाइल हैंडल को संरचना फ़ाइल के उदाहरणों द्वारा दर्शाया गया है , और इस संरचना का आकार काफी छोटा है (बाइट्स स्तर), इसलिए क्या मैं /.../file-maxकाफी बड़े मूल्य के साथ सेट कर सकता हूं जब तक कि मेमोरी का उपयोग नहीं किया जाता है?

— xanpeng

@xanpeng मैं एक कर्नेल विशेषज्ञ नहीं हूं, लेकिन जहां तक ​​मैं देख सकता हूं, डिफ़ॉल्ट रूप file-maxसे RAM आकार 10k से विभाजित होने लगता है। जैसा कि फ़ाइल हैंडलर के लिए उपयोग की जाने वाली वास्तविक मेमोरी बहुत छोटी होनी चाहिए ( struct fileप्लस कुछ ड्राइवर निर्भर मेमोरी का आकार ), यह काफी रूढ़िवादी सीमा लगती है।

— जोफेल

Answer 2

कृपया ध्यान दें कि lsof | wc -lबहुत सी डुप्लिकेट की गई प्रविष्टियाँ (फोर्क्ड प्रक्रियाएँ फ़ाइल हैंडल आदि को साझा कर सकती हैं) को प्रस्तुत करती हैं। यह संख्या निर्धारित सीमा से बहुत अधिक हो सकती है /proc/sys/fs/file-max।

लिनक्स कर्नेल के दृष्टिकोण से खुली फ़ाइलों की वर्तमान संख्या प्राप्त करने के लिए, यह करें:

cat /proc/sys/fs/file-nr

उदाहरण: इस सर्वर में अधिकतम 65536 खुली फाइलों में से 40096 हैं, हालाँकि lsof बहुत अधिक संख्या में रिपोर्ट करता है:

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

Comments

जैसा कि lsofदो या दो से अधिक फ़ाइलों की रिपोर्ट करेगा, जैसे कि /dev/null, आप इसके साथ सबसे अच्छा अनुमान लगा सकते हैं:lsof|awk '{print $9}'|sort|uniq|wc -l

— यवन

आप lsof|awk '!a[$NF]++{c++}END{print c}'खुली फ़ाइलों की गैर-डुप्लिकेट गणना प्राप्त करने के लिए उपयोग कर सकते हैं ।

— पी ....

Answer 3

मुझे लगता है कि यह काफी हद तक ऐतिहासिक कारणों से है।

एक यूनिक्स फ़ाइल वर्णनकर्ता एक छोटा सा है intमूल्य, जैसे कार्यों के द्वारा दिया openऔर creat, और करने के लिए पारित कर दिया read, write, close, और इसके आगे।

कम से कम यूनिक्स के शुरुआती संस्करणों में, एक फाइल डिस्क्रिप्टर संरचनाओं के एक निश्चित-आकार प्रति प्रक्रिया सरणी में एक सूचकांक था, जहां प्रत्येक संरचना में एक खुली फ़ाइल के बारे में जानकारी होती है। यदि मुझे सही तरीके से याद है, तो कुछ शुरुआती प्रणालियों ने इस तालिका का आकार 20 या तो सीमित कर दिया है।

अधिक आधुनिक प्रणालियों की उच्च सीमाएं हैं, लेकिन एक ही सामान्य योजना को बनाए रखा है, बड़े पैमाने पर जड़ता से बाहर।

Comments

20 सी भाषा फ़ाइल डेटा संरचनाओं के लिए सोलारिस सीमा थी। फ़ाइल हैंडल काउंट हमेशा बड़ा होता था।

— लोथर

@ लोथर: दिलचस्प है। मुझे आश्चर्य है कि सीमाएं अलग क्यों होंगी। इन कार्यों filenoऔर fdopenकार्यों को देखते हुए मैं उनसे लगभग विनिमेय होने की उम्मीद करूंगा।

— कीथ थॉम्पसन

एक यूनिक्स फ़ाइल केवल फ़ाइल हैंडल (इंट) से अधिक है। डिस्क बफ़र, और एक फ़ाइल नियंत्रण ब्लॉक है जो वर्तमान फ़ाइल ऑफसेट, फ़ाइल स्वामी, अनुमतियाँ,

— इनोड

@ChuckCottrill: हां, बिल्कुल। लेकिन उस जानकारी को संग्रहित करना पड़ता है चाहे कोई फ़ाइल intडिस्क्रिप्टर या ए के माध्यम से एक्सेस हो FILE*। यदि आपके पास 20 से अधिक फाइलें हैं open(), तो क्या आप fdopen()असफल होंगे?

— कीथ थॉम्पसन