प्रोक फाइल सिस्टम (इसके बाद सिर्फ़ प्रूफ़्स) एक वर्चुअल फाइल सिस्टम है जो प्रक्रियाओं के बारे में जानकारी प्रदान करता है। वह "सब कुछ एक फाइल है" प्रतिमान के बाद इंटरफेस का एक "ठीक" उदाहरण है। Procfs को बहुत पहले विकसित किया गया था: एक ऐसे समय में जब सर्वर ने औसतन दर्जनों प्रक्रियाओं को सेवित किया था, जब एक फ़ाइल खोलना और प्रक्रिया की जानकारी पढ़ना कोई समस्या नहीं थी। हालांकि, समय अभी भी खड़ा नहीं है, और अब सर्वर एक ही समय में सैकड़ों हजारों, या इससे भी अधिक प्रक्रियाओं की सेवा करते हैं। इस संदर्भ में, "रुचि के डेटा को घटाने के लिए प्रत्येक प्रक्रिया के लिए एक फ़ाइल खोलने" का विचार अब इतना आकर्षक नहीं लगता है, और पढ़ने में तेजी लाने के लिए पहली बात जो ध्यान में आती है, वह एक पुनरावृत्ति में प्रक्रियाओं के समूह के बारे में जानकारी प्राप्त करना है। इस लेख में, हम उन तत्वों को खोजने का प्रयास करेंगे जिन्हें अनुकूलित किया जा सकता है।

Procfs को बेहतर बनाने का विचार तब आया जब हमें पता चला कि CRIU काफी समय खर्च करता है बस procfs फाइलों को पढ़ता है। हमने देखा कि सॉकेट्स के लिए एक समान समस्या कैसे हल की गई थी, और उसने सॉक-डायग इंटरफेस के समान कुछ करने का फैसला किया, लेकिन केवल खरीद के लिए। बेशक, हमने यह मान लिया कि कर्नेल में लंबे समय से स्थायी और अच्छी तरह से स्थापित इंटरफ़ेस को बदलना कितना मुश्किल होगा, इस समुदाय को यह समझाने के लिए कि खेल मोमबत्ती के लायक था ... और हम नए इंटरफ़ेस के निर्माण का समर्थन करने वाले लोगों की संख्या से सुखद आश्चर्यचकित थे। कड़ाई से बोलते हुए, किसी को नहीं पता था कि नया इंटरफ़ेस कैसा दिखना चाहिए, लेकिन इसमें कोई संदेह नहीं है कि खरीद मौजूदा प्रदर्शन आवश्यकताओं को पूरा नहीं करता है। उदाहरण के लिए, यह परिदृश्य: सर्वर बहुत लंबे समय तक अनुरोधों का जवाब देता है, vmstat दिखाता है कि मेमोरी स्वैप में चली गई है, और "ps ax" को 10 सेकंड या उससे अधिक से शुरू किया जाता है, शीर्ष बिल्कुल कुछ भी नहीं दिखाता है। इस लेख में हम किसी विशिष्ट नए इंटरफ़ेस पर विचार नहीं करेंगे, बल्कि, हम समस्याओं और उनके समाधानों का वर्णन करने का प्रयास करेंगे।

प्रत्येक निष्पादन योग्य प्रॉक्सैस प्रक्रिया को / proc / <pid> डायरेक्टरी द्वारा दर्शाया जाता है।
ऐसी प्रत्येक निर्देशिका में कई फाइलें और उपनिर्देशिकाएं होती हैं जो प्रक्रिया के बारे में निश्चित जानकारी तक पहुंच प्रदान करती हैं। उपनिर्देशिका समूह डेटा सुविधा द्वारा। उदाहरण के लिए ( $$ एक विशेष शेल चर है जो कि पीआईडी में विस्तारित है - वर्तमान प्रक्रिया का पहचानकर्ता):

 $ ls -F /proc/$$ attr/ exe@ mounts projid_map status autogroup fd/ mountstats root@ syscall auxv fdinfo/ net/ sched task/ cgroup gid_map ns/ schedstat timers clear_refs io numa_maps sessionid timerslack_ns cmdline limits oom_adj setgroups uid_map comm loginuid oom_score smaps wchan coredump_filter map_files/ oom_score_adj smaps_rollup cpuset maps pagemap stack cwd@ mem patch_state stat environ mountinfo personality statm

ये सभी फाइलें विभिन्न स्वरूपों में डेटा का उत्पादन करती हैं। अधिकांश ASCII प्रारूप पाठ में हैं जो आसानी से मनुष्यों द्वारा माना जाता है। खैर, लगभग आसान:

 $ cat /proc/$$/stat 24293 (bash) S 21811 24293 24293 34854 24876 4210688 6325 19702 0 10 15 7 33 35 20 0 1 0 47892016 135487488 3388 18446744073709551615 94447405350912 94447406416132 140729719486816 0 0 0 65536 3670020 1266777851 1 0 0 17 2 0 0 0 0 0 94447408516528 94447408563556 94447429677056 140729719494655 140729719494660 140729719494660 140729719496686 0

यह समझने के लिए कि इस सेट के प्रत्येक तत्व का क्या मतलब है, पाठक को मैन प्रोक (5), या कर्नेल प्रलेखन खोलना होगा। उदाहरण के लिए, दूसरा तत्व ब्रैकेट में निष्पादन योग्य फ़ाइल का नाम है, और उन्नीसवां तत्व निष्पादन प्राथमिकता का वर्तमान मूल्य (अच्छा) है।

कुछ फाइलें अपने आप काफी पठनीय हैं:

 $ cat /proc/$$/status | head -n 5 Name: bash Umask: 0002 State: S (sleeping) Tgid: 24293 Ngid: 0

लेकिन उपयोगकर्ता कितनी बार procfs फाइलों से सीधे जानकारी पढ़ते हैं? बाइनरी डेटा को टेक्स्ट फॉर्मेट में बदलने के लिए कर्नेल को कितने समय की आवश्यकता होती है? अधिप्राप्ति का ओवरहेड क्या है? स्थिति मॉनिटर कार्यक्रमों के लिए यह इंटरफ़ेस कितना सुविधाजनक है, और इस पाठ डेटा को संसाधित करने में कितना समय वे खर्च करते हैं? आपातकालीन स्थितियों में इतना धीमा कार्यान्वयन कितना महत्वपूर्ण है?

सबसे अधिक संभावना है, यह कहना गलत नहीं होगा कि उपयोगकर्ता सीधे खरीद से डेटा पढ़ने के बजाय शीर्ष या पीएस जैसे कार्यक्रम पसंद करते हैं।

शेष प्रश्नों के उत्तर के लिए, हम कई प्रयोग करेंगे। सबसे पहले, यह पता लगाएं कि कर्नेल कहाँ तक समय-समय पर फ़ाइलों को बनाने के लिए खर्च करता है।

सिस्टम में सभी प्रक्रियाओं से निश्चित जानकारी प्राप्त करने के लिए, हमें / proc / निर्देशिका से गुजरना होगा और उन सभी उपनिर्देशिकाओं का चयन करना होगा जिनका नाम दशमलव अंकों द्वारा दर्शाया गया है। फिर, उनमें से प्रत्येक में, हमें फ़ाइल खोलने, इसे पढ़ने और इसे बंद करने की आवश्यकता है।

कुल मिलाकर, हम तीन सिस्टम कॉल करेंगे, जिनमें से एक फाइल डिस्क्रिप्टर बनाएगी (कर्नेल में, एक फाइल डिस्क्रिप्टर आंतरिक वस्तुओं के सेट के साथ जुड़ा हुआ है जिसके लिए अतिरिक्त मेमोरी आवंटित की गई है)। ओपन () और क्लोज़ () सिस्टम कॉल खुद हमें कोई जानकारी नहीं देते हैं, इसलिए उन्हें procfs इंटरफ़ेस ओवरहेड के लिए जिम्मेदार ठहराया जा सकता है।

आइए सिस्टम में प्रत्येक प्रक्रिया के लिए बस खोलने () और बंद करने () की कोशिश करें, लेकिन हम फ़ाइलों की सामग्री को नहीं पढ़ेंगे:

 $ time ./task_proc_all --noread stat tasks: 50290 real 0m0.177s user 0m0.012s sys 0m0.162s

 $ time ./task_proc_all --noread loginuid tasks: 50289 real 0m0.176s user 0m0.026s sys 0m0.145

कार्य-खरीद-सभी - एक छोटी सी उपयोगिता, जिसका कोड नीचे दिए गए लिंक पर पाया जा सकता है

इससे कोई फर्क नहीं पड़ता कि कौन सी फाइल को खोलना है, क्योंकि वास्तविक डेटा केवल पढ़ने के समय () में उत्पन्न होता है।

अब परफेक्ट कोर प्रोफाइलर के आउटपुट को देखें:

 - 92.18% 0.00% task_proc_all [unknown] - 0x8000 - 64.01% __GI___libc_open - 50.71% entry_SYSCALL_64_fastpath - do_sys_open - 48.63% do_filp_open - path_openat - 19.60% link_path_walk - 14.23% walk_component - 13.87% lookup_fast - 7.55% pid_revalidate 4.13% get_pid_task + 1.58% security_task_to_inode 1.10% task_dump_owner 3.63% __d_lookup_rcu + 3.42% security_inode_permission + 14.76% proc_pident_lookup + 4.39% d_alloc_parallel + 2.93% get_empty_filp + 2.43% lookup_fast + 0.98% do_dentry_open 2.07% syscall_return_via_sysret 1.60% 0xfffffe000008a01b 0.97% kmem_cache_alloc 0.61% 0xfffffe000008a01e - 16.45% __getdents64 - 15.11% entry_SYSCALL_64_fastpath sys_getdents iterate_dir - proc_pid_readdir - 7.18% proc_fill_cache + 3.53% d_lookup 1.59% filldir + 6.82% next_tgid + 0.61% snprintf - 9.89% __close + 4.03% entry_SYSCALL_64_fastpath 0.98% syscall_return_via_sysret 0.85% 0xfffffe000008a01b 0.61% 0xfffffe000008a01e 1.10% syscall_return_via_sysret

कर्नेल फ़ाइल डिस्क्रिप्टर को बनाने और हटाने के लिए लगभग 75% समय खर्च करता है, और प्रक्रियाओं को सूचीबद्ध करने के लिए लगभग 16%।

यद्यपि हम जानते हैं कि प्रत्येक प्रक्रिया के लिए खुले () और पास () कॉल में कितना समय लगता है, फिर भी हम अनुमान नहीं लगा सकते कि यह कितना महत्वपूर्ण है। हमें कुछ के साथ प्राप्त मूल्यों की तुलना करने की आवश्यकता है। आइए सबसे प्रसिद्ध फाइलों के साथ ऐसा ही करने का प्रयास करें। आमतौर पर, जब आपको प्रक्रियाओं को सूचीबद्ध करने की आवश्यकता होती है, तो ps या शीर्ष उपयोगिता का उपयोग किया जाता है। वे दोनों सिस्टम पर प्रत्येक प्रक्रिया के लिए / proc / <pid> / stat और / proc / <pid> / status पढ़ते हैं।

चलिए शुरू करते हैं / proc / <pid> / status से - यह एक विशाल फ़ाइल है जिसमें निश्चित संख्या में फ़ील्ड हैं:

 $ time ./task_proc_all status tasks: 50283 real 0m0.455s user 0m0.033s sys 0m0.417s

 - 93.84% 0.00% task_proc_all [unknown] [k] 0x0000000000008000 - 0x8000 - 61.20% read - 53.06% entry_SYSCALL_64_fastpath - sys_read - 52.80% vfs_read - 52.22% __vfs_read - seq_read - 50.43% proc_single_show - 50.38% proc_pid_status - 11.34% task_mem + seq_printf + 6.99% seq_printf - 5.77% seq_put_decimal_ull 1.94% strlen + 1.42% num_to_str - 5.73% cpuset_task_status_allowed + seq_printf - 5.37% render_cap_t + 5.31% seq_printf - 5.25% render_sigset_t 0.84% seq_putc 0.73% __task_pid_nr_ns + 0.63% __lock_task_sighand 0.53% hugetlb_report_usage + 0.68% _copy_to_user 1.10% number 1.05% seq_put_decimal_ull 0.84% vsnprintf 0.79% format_decode 0.73% syscall_return_via_sysret 0.52% 0xfffffe000003201b + 20.95% __GI___libc_open + 6.44% __getdents64 + 4.10% __close

यह देखा जा सकता है कि रीड () सिस्टम कॉल के अंदर खर्च किए गए समय का केवल 60% है। यदि आप प्रोफ़ाइल को अधिक बारीकी से देखते हैं, तो यह पता चलता है कि 45% समय कर्नेल फ़ंक्शन seq_printf, seq_put_decimal_ull के अंदर उपयोग किया जाता है। तो, द्विआधारी से पाठ प्रारूप में परिवर्तित करना काफी महंगा ऑपरेशन है। जो अच्छी तरह से स्थापित प्रश्न को भीख देता है: क्या हमें वास्तव में कर्नेल से डेटा खींचने के लिए एक पाठ इंटरफ़ेस की आवश्यकता है? उपयोगकर्ता कच्चे डेटा के साथ कितनी बार काम करना चाहते हैं? और शीर्ष और पीएस उपयोगिताओं को इस पाठ डेटा को बाइनरी में क्यों बदलना है?

शायद यह जानना दिलचस्प होगा कि बाइनरी डेटा सीधे उपयोग किए जाने पर आउटपुट कितना तेज़ होगा, और यदि तीन सिस्टम कॉल की आवश्यकता नहीं थी।

इस तरह के एक इंटरफ़ेस बनाने के लिए पहले से ही प्रयास किए गए हैं। 2004 में हमने नेटलिंक इंजन का उपयोग करने की कोशिश की।

 [0/2][ANNOUNCE] nproc: netlink access to /proc information (https://lwn.net/Articles/99600/) nproc is an attempt to address the current problems with /proc. In short, it exposes the same information via netlink (implemented for a small subset).

दुर्भाग्य से, समुदाय ने इस काम में ज्यादा दिलचस्पी नहीं दिखाई है। स्थिति को सुधारने के अंतिम प्रयासों में से एक दो साल पहले हुआ था।

 [PATCH 0/15] task_diag: add a new interface to get information about processes (https://lwn.net/Articles/683371/)

कार्य-डायग इंटरफ़ेस निम्नलिखित सिद्धांतों पर आधारित है:

लेन-देन: एक अनुरोध भेजा, एक प्रतिक्रिया मिली;
संदेशों का प्रारूप नेटलिंक (इंटरफ़ेस sock_diag: बाइनरी और एक्स्टेंसिबल के समान) के रूप में है;
एक कॉल में कई प्रक्रियाओं के बारे में जानकारी का अनुरोध करने की क्षमता;
विशेषताओं का अनुकूलित समूहन (समूह में कोई विशेषता प्रतिक्रिया समय नहीं बढ़ाना चाहिए)।

यह इंटरफ़ेस कई सम्मेलनों में प्रस्तुत किया गया है। यह एक प्रयोग के रूप में pstools, CRIU उपयोगिताओं, और डेविड अहर्न एकीकृत task_diag में एकीकृत किया गया था।

कर्नेल विकास समुदाय को task_diag इंटरफ़ेस में रुचि हो गई है। चर्चा का मुख्य विषय कर्नेल और उपयोगकर्ता स्थान के बीच परिवहन का विकल्प था। नेटलिंक सॉकेट्स का उपयोग करने का प्रारंभिक विचार खारिज कर दिया गया था। आंशिक रूप से नेटलिंक इंजन के कोड में अनसुलझे समस्याओं के कारण, और आंशिक रूप से क्योंकि कई लोग सोचते हैं कि नेटलिंक इंटरफ़ेस विशेष रूप से नेटवर्क सबसिस्टम के लिए डिज़ाइन किया गया था। तब प्रैक्टिस के अंदर ट्रांसेक्शनल फ़ाइलों का उपयोग करने का प्रस्ताव किया गया था, अर्थात्, उपयोगकर्ता फ़ाइल खोलता है, इसमें अनुरोध लिखता है, और फिर बस उत्तर पढ़ता है। हमेशा की तरह, इस दृष्टिकोण के विरोधी थे। एक समाधान जो हर किसी को तब तक पसंद आएगा जब तक कि वह मिल न जाए।

टास्क के साथ टास्क_डैग के प्रदर्शन की तुलना करते हैं।

टास्क_डैग इंजन में एक परीक्षण उपयोगिता है जो हमारे प्रयोगों के लिए उपयुक्त है। मान लीजिए हम प्रक्रिया पहचानकर्ताओं और उनके अधिकारों का अनुरोध करना चाहते हैं। नीचे एक प्रक्रिया के लिए आउटपुट है:

 $ ./task_diag_all one -c -p $$ pid 2305 tgid 2305 ppid 2299 sid 2305 pgid 2305 comm bash uid: 1000 1000 1000 1000 gid: 1000 1000 1000 1000 CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000 CapBnd: 0000003fffffffff

और अब सिस्टम में सभी प्रक्रियाओं के लिए, अर्थात, हमने जब हमने / proc / pid / स्टेटस फ़ाइल पढ़ी है, तो हमने वही प्रयोग किया है, जो हमने procfs प्रयोग के लिए किया था:

 $ time ./task_diag_all all -c real 0m0.048s user 0m0.001s sys 0m0.046s

प्रक्रिया पेड़ बनाने के लिए डेटा प्राप्त करने में केवल 0.05 सेकंड का समय लगा। और procfs के साथ, प्रत्येक प्रक्रिया के लिए एक फ़ाइल खोलने के लिए, और डेटा को पढ़े बिना केवल 0.177 सेकंड का समय लगा।

Task_diag इंटरफ़ेस के लिए संपूर्ण आउटपुट:

 - 82.24% 0.00% task_diag_all [kernel.vmlinux] [k] entry_SYSCALL_64_fastpath - entry_SYSCALL_64_fastpath - 81.84% sys_read vfs_read __vfs_read proc_reg_read task_diag_read - taskdiag_dumpit + 33.84% next_tgid 13.06% __task_pid_nr_ns + 6.63% ptrace_may_access + 5.68% from_kuid_munged - 4.19% __get_task_comm 2.90% strncpy 1.29% _raw_spin_lock 3.03% __nla_reserve 1.73% nla_reserve + 1.30% skb_copy_datagram_iter + 1.21% from_kgid_munged 1.12% strncpy

लिस्टिंग में कुछ भी दिलचस्प नहीं है सिवाय इसके कि अनुकूलन के लिए उपयुक्त कोई स्पष्ट कार्य नहीं हैं।

आइए सिस्टम में सभी प्रक्रियाओं के बारे में जानकारी पढ़ते समय परफैक्ट आउटपुट देखें:

  $ perf trace -s ./task_diag_all all -c -q Summary of events: task_diag_all (54326), 185 events, 95.4% syscall calls total min avg max stddev (msec) (msec) (msec) (msec) (%) --------------- -------- --------- --------- --------- --------- ------ read 49 40.209 0.002 0.821 4.126 9.50% mmap 11 0.051 0.003 0.005 0.007 9.94% mprotect 8 0.047 0.003 0.006 0.009 10.42% openat 5 0.042 0.005 0.008 0.020 34.86% munmap 1 0.014 0.014 0.014 0.014 0.00% fstat 4 0.006 0.001 0.002 0.002 10.47% access 1 0.006 0.006 0.006 0.006 0.00% close 4 0.004 0.001 0.001 0.001 2.11% write 1 0.003 0.003 0.003 0.003 0.00% rt_sigaction 2 0.003 0.001 0.001 0.002 15.43% brk 1 0.002 0.002 0.002 0.002 0.00% prlimit64 1 0.001 0.001 0.001 0.001 0.00% arch_prctl 1 0.001 0.001 0.001 0.001 0.00% rt_sigprocmask 1 0.001 0.001 0.001 0.001 0.00% set_robust_list 1 0.001 0.001 0.001 0.001 0.00% set_tid_address 1 0.001 0.001 0.001 0.001 0.00%

Procfs के लिए, हमें सभी प्रक्रियाओं के बारे में जानकारी प्राप्त करने के लिए 150,000 से अधिक सिस्टम कॉल करने की आवश्यकता है, और task_diag के लिए - 50 से थोड़ा अधिक।

आइए वास्तविक जीवन स्थितियों को देखें। उदाहरण के लिए, हम प्रत्येक के लिए कमांड लाइन के तर्कों के साथ एक प्रोसेस ट्री प्रदर्शित करना चाहते हैं। ऐसा करने के लिए, हमें प्रक्रिया की पाइड, उसके अभिभावक की पीडा, और कमांड लाइन अपने आप को तर्क देने की जरूरत है।

टास्क_डैग इंटरफेस के लिए, प्रोग्राम एक बार में सभी मापदंडों को प्राप्त करने के लिए एक अनुरोध भेजता है:

 $ time ./task_diag_all all --cmdline -q real 0m0.096s user 0m0.006s sys 0m0.090s

मूल घोषणाओं के लिए, हमें प्रत्येक प्रक्रिया के लिए / proc // स्थिति और / proc // cmdline पढ़ना होगा:

 $ time ./task_proc_all status tasks: 50278 real 0m0.463s user 0m0.030s sys 0m0.427s

 $ time ./task_proc_all cmdline tasks: 50281 real 0m0.270s user 0m0.028s sys 0m0.237s

यह नोट करना आसान है कि टास्क_डैग, सैकेंड्स की तुलना में 7 गुना तेज है (0.27 + 0.46 के मुकाबले 0.096)। आमतौर पर, कई प्रतिशत का प्रदर्शन सुधार पहले से ही एक अच्छा परिणाम है, लेकिन यहाँ गति लगभग एक परिमाण के क्रम से बढ़ी है।

यह भी उल्लेखनीय है कि आंतरिक कर्नेल ऑब्जेक्ट का निर्माण भी प्रदर्शन को बहुत प्रभावित करता है। विशेष रूप से जब मेमोरी सबसिस्टम भारी लोड के तहत होता है। Procfs और task_diag के लिए बनाई गई वस्तुओं की संख्या की तुलना करें:

 $ perf trace --event 'kmem:*alloc*' ./task_proc_all status 2>&1 | grep kmem | wc -l 58184 $ perf trace --event 'kmem:*alloc*' ./task_diag_all all -q 2>&1 | grep kmem | wc -l 188

और आपको यह भी पता लगाने की आवश्यकता है कि एक सरल प्रक्रिया शुरू करते समय कितनी वस्तुओं का निर्माण होता है, उदाहरण के लिए, वास्तविक उपयोगिता:

 $ perf trace --event 'kmem:*alloc*' true 2>&1 | wc -l 94

Procfs, task_diag से 600 गुना अधिक ऑब्जेक्ट बनाता है। यह एक कारण है कि जब मेमोरी लोड भारी होता है, तो proc इतनी बुरी तरह से काम करता है। कम से कम इसलिए यह अनुकूलन के लायक है।

हमें उम्मीद है कि लेख कर्नेल सबसिस्टम के procfs राज्य को अनुकूलित करने के लिए अधिक डेवलपर्स को आकर्षित करेगा।

डेविड अहर्न, एंडी लुतोमिरस्की, स्टीफन हेमिंग, ओलेग नेस्टरोव, डब्ल्यू। ट्रेवर किंग, अरंड बर्गमैन, एरिक डब्ल्यू बाइडरमैन और कई अन्य लोगों को धन्यवाद जिन्होंने टास्क_डैग इंटरफेस को विकसित करने और सुधारने में मदद की।

इस लेख को लिखने में मदद के लिए cromer , k001 और स्टैनिस्लाव किंसबर्सकी का धन्यवाद।

वर्चुअल फाइल सिस्टम कितना प्रभावी है और क्या इसका अनुकूलन संभव है

संदर्भ

More articles: