👌🏽 👨🏼‍⚕️ 😾 कैसे और क्यों हमने लिनक्स कर्नेल में SLAB कैश की सफाई के लिए एल्गोरिथ्म को अनुकूलित किया 💤 😕 🤰

कंटेनरों की बढ़ती लोकप्रियता और नियंत्रण समूहों के साथ उनके उपयोग ने एक गंभीर स्केलेबिलिटी समस्या का पता लगाया, जिससे बड़ी मशीनों पर प्रदर्शन में महत्वपूर्ण गिरावट आई। समस्या यह है कि SLAB कैश का बाईपास समय कंटेनरों की संख्या पर निर्भर करता है, और छोटी अवधि में बड़ी मात्रा में मेमोरी की सक्रिय खपत सिस्टम को व्यस्त लूप में जाने का कारण बन सकती है, जो प्रोसेसर समय का 100% खपत करता है। आज मैं आपको यह बताना चाहूंगा कि कैसे हमने SLB कैश ऑब्जेक्ट्स का उपयोग करने के लिए memcg नियंत्रण समूह का उपयोग करने और संकोचन_स्लैब () फ़ंक्शन का उपयोग करने के लिए अकाउंटिंग एल्गोरिथ्म को बदलकर इस समस्या को हल किया।

स्मृति की सफाई

कर्नेल में प्रक्रियाओं के अनुकूलन का सवाल क्यों उठा? यह सब इस तथ्य से शुरू हुआ कि हमारे ग्राहकों में से एक, सक्रिय रूप से कंटेनर और मेमोरी कंट्रोल ग्रुप (मेमग) का उपयोग करते हुए, समय-समय पर होने वाले प्रोसेसर संसाधनों की खपत की अजीब चोटियों पर ध्यान आकर्षित करता है। सामान्य सिस्टम लोड लगभग 50% था, और चरम समय पर प्रोसेसर समय का 100% लिया गया था, और लगभग सभी इसे कर्नेल (एसआईएस समय) द्वारा भस्म किया गया था।
नोड स्वयं बहु-उपयोगकर्ता था, और उस पर लगभग 200 OpenVZ कंटेनर लॉन्च किए गए थे। विश्लेषण से पता चला कि बड़ी संख्या में उपयोगकर्ताओं ने नेस्टेड डॉकर कंटेनर और मेमोरी कंट्रोल समूहों के बहु-स्तरीय पदानुक्रम बनाए। प्रत्येक कस्टम शीर्ष-स्तरीय कंटेनर में सिस्टम द्वारा बनाए गए लगभग 20 माउंट पॉइंट और 20 कंट्रोल मेमोरी ग्रुप (मेमग) होते हैं। इसके अलावा, उक्त डॉकटर द्वारा बनाए गए आरोह बिंदु और नियंत्रण समूह थे। सीधे शब्दों में कहें, तो नोड भारी था, और उस पर लोड हमारे सभी अन्य ग्राहकों के लिए औसत से बहुत मजबूत था। हम इन चोटियों की उपस्थिति का कारण खोजने में रुचि रखते थे, क्योंकि कम व्यस्त मशीनों पर एक ही समस्या दिखाई दे सकती थी, जहां यह शायद ही ध्यान देने योग्य था (उदाहरण के लिए, + 5% sys समय पर चोटियां दें, जो प्रदर्शन को कम करती हैं)।

Perf में हेरफेर करके, मैं चोटी को पकड़ने और निशान को हटाने में कामयाब रहा। यह पता चला कि अधिकांश प्रोसेसर समय SLAB कैश को समाशोधन पर खर्च किया जाता है, अर्थात्, सुपर ब्लॉक कैश:

- 100,00% 0,00% kswapd0 [kernel.vmlinux] [k] kthread - 99,31% balance_pgdat - 82,11% shrink_zone - 61,69% shrink_slab - 58,29% super_cache_count + 54,56% list_lru_count_one

यहां यह एक स्पष्टीकरण बनाने के लायक है और इस मुद्दे पर अधिक विस्तार से निवास करता है। हर कोई जानता है कि कर्नेल कैश को अप्रयुक्त डेटा को थोड़ी देर के लिए मेमोरी से मुक्त करने से पहले। कर्नेल इस सिद्धांत का व्यापक उपयोग करता है। उदाहरण के लिए, पृष्ठ कैश में फ़ाइल से संबंधित डेटा के पृष्ठ होते हैं, जो पढ़ते समय उनके लिए बार-बार पहुंच को गति देते हैं (क्योंकि आपको डिस्क को फिर से एक्सेस करने की आवश्यकता नहीं है)। हमारे मामले में, समस्या दो LRU सूचियों में निहित सुपरब्लॉक मेटाडेटा कैश के साथ उत्पन्न हुई: s_dentry_lru और s_inode_lru।

LRU (कम से कम हाल ही में प्रयुक्त)

लिंक किए गए सूचियों की एक सरणी के लिए संरचना lru_list इंगित करता है, और प्रत्येक सक्रिय मेम इस सरणी में एक तत्व (list_lru_one) से मेल खाती है। जब एक निश्चित SLAB ऑब्जेक्ट का उपयोग कर्नेल द्वारा नहीं किया जाता है, तो कर्नेल इसे सरणी की लिंक की गई सूचियों में से एक में जोड़ता है (इस पर निर्भर करता है कि ऑब्जेक्ट किस मेमेकग से संबंधित है, या मोटे तौर पर बोल रहा है, जो इस ऑब्जेक्ट के उपयोग होने पर उपयोग होने वाली प्रक्रिया को याद करता है)। सरणी को इस प्रकार वर्णित किया गया है (lru_list :: नोड :: memcg_lrus):

 struct list_lru_memcg { struct rcu_head rcu; /* array of per cgroup lists, indexed by memcg_cache_id */ struct list_lru_one *lru[0]; /*    */ }; struct list_lru_one { struct list_head list; /*    */ /* may become negative during memcg reparenting */ long nr_items; /*     */ };

lru [0] ID 0 के साथ मेमेक से संबंधित वस्तुओं की एक सूची को इंगित करता है;
lru [1] ID 1 के साथ memcg से संबंधित वस्तुओं की एक सूची को इंगित करता है;
...
lru [n] ID n के साथ मेमेक से संबंधित वस्तुओं की एक सूची को इंगित करता है;

LRU हमारी समस्या में s_dentry_lru और s_inode_lru को सूचीबद्ध करता है, और जैसा कि नाम से पता चलता है, उनके पास अप्रयुक्त डेंट्री और इनोड फाइल सिस्टम ऑब्जेक्ट हैं।
भविष्य में, यदि सिस्टम में पर्याप्त मेमोरी नहीं है या एक विशिष्ट मेमॉग है, तो सूची में से कुछ को अंतिम रूप से मुक्त कर दिया जाता है, और एक विशेष तंत्र जिसे संकोटर कहा जाता है वह ऐसा करता है।

Shrinker

जब कर्नेल को स्मृति के पृष्ठों को आवंटित करने की आवश्यकता होती है, लेकिन NUMA नोड या सिस्टम में कोई मुक्त मेमोरी नहीं है, तो इसकी सफाई के लिए तंत्र शुरू होता है। वह एक निश्चित मात्रा में डिस्क को फेंकने या डंप करने की कोशिश कर रहा है: पेज कैश से फ़ाइलों की सामग्री के 1) पृष्ठ; 2) एक स्वैप में अनाम मेमोरी से संबंधित पेज और 3) कैश्ड SLAB ऑब्जेक्ट्स (हमारे द्वारा सामना की गई समस्या उनसे संबंधित है)।

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

यह फ़ंक्शन ऑब्जेक्ट के उस हिस्से की वास्तविक सफाई करता है, जो विवरण के द्वारा निर्देशित होता है, जो कि कंप्रेक्टर कंप्रेशर में दिया जाता है:

 static unsigned long do_shrink_slab(struct shrink_control *shrinkctl, struct shrinker *shrinker, int priority) { … /*   */ freeable = shrinker->count_objects(shrinker, shrinkctl); if (freeable == 0) return 0; total_scan = _(freeable); while (total_scan >= batch_size) { /*   */ ret = shrinker->scan_objects(shrinker, shrinkctl); total_scan -= shrinkctl->nr_scanned; } ... }

संकोचन सुपरब्लॉक के संबंध में, इन कार्यों को निम्नानुसार लागू किया जाता है। प्रत्येक सुपरब्लॉक अपने स्वयं के s_dentry_lru और s_inode_lru से संबंधित अप्रयुक्त वस्तुओं की सूची रखता है:

 struct super_block { ... struct shrinker s_shrink; /* per-sb shrinker handle */ ... struct list_lru s_dentry_lru; struct list_lru s_inode_lru; … };

.Count_objects विधि ऑब्जेक्ट की संख्या लौटाती है:

 static unsigned long super_cache_count(struct shrinker *shrink, struct shrink_control *sc) { total_objects += list_lru_shrink_count(&sb->s_dentry_lru, sc); total_objects += list_lru_shrink_count(&sb->s_inode_lru, sc); /*     ) */ total_objects = vfs_pressure_ratio(total_objects); return total_objects; }

.Scan_objects विधि वास्तव में वस्तुओं को मुक्त करती है:

 static unsigned long super_cache_scan(struct shrinker *shrink, struct shrink_control *sc) { /*     s_dentry_lru */ prune_dcache_sb(sb, sc); /*     s_inode_lru */ prune_icache_sb(sb, sc); }

मुक्त की जाने वाली वस्तुओं की संख्या को sc पैरामीटर में पारित किया जाता है। इसके अलावा, मेमकग को वहां इंगित किया गया है, जिनमें से वस्तुओं को LRU से बाहर फेंक दिया जाना चाहिए:

 struct shrink_control { int nid; /* ID NUMA  */ unsigned long nr_to_scan; /*   */ struct mem_cgroup *memcg; /* memcg */ };

इस प्रकार, prune_dcache_sb () सरणी संरचना सूची_lru_memcg :: lru [] से एक लिंक की गई सूची का चयन करता है और इसके साथ काम करता है। Prune_icache_sb () वही करता है।

पुराना संकोची बाईपास एल्गोरिथम

मानक दृष्टिकोण के साथ, SLAB से ऑब्जेक्ट को "बेदखल करना" जिसमें मेमोरी से बाहर है
sc-> target_mem_cgroup निम्नानुसार होता है:

 shrink_node() { … struct mem_cgroup *root = sc->target_mem_cgroup; /*      sc->target_mem_cgroup  */ memcg = mem_cgroup_iter(root, NULL, &reclaim); do { … shrink_slab(memcg, ...); … } while ((memcg = mem_cgroup_iter(root, memcg, &reclaim))); ... }

हम सभी चाइल्ड मेमेक के माध्यम से जाते हैं और उनमें से प्रत्येक के लिए संकोचन_स्लाब () कहते हैं। इसके बाद, संकोचन_स्लैब () फ़ंक्शन में, हम सभी कम्प्रेसर के माध्यम से जाते हैं और उनमें से प्रत्येक के लिए do_shrink_slab () कहते हैं:

 static unsigned long shrink_slab(gfp_t gfp_mask, int nid, struct mem_cgroup *memcg, int priority) { list_for_each_entry(shrinker, &shrinker_list, list) { struct shrink_control sc = { .nid = nid, .memcg = memcg, }; ret = do_shrink_slab(&sc, shrinker, ...); } }

स्मरण करो कि प्रत्येक सुपरब्लॉक के लिए, इस सूची में अपना स्वयं का संकोचनकर्ता जोड़ा जाता है। आइए गिनती करें कि 20 मेमेक और 200 माउंट पॉइंट्स के 200 कंटेनरों के साथ केस के लिए do_shrink_slab () को कितनी बार बुलाया जाएगा। कुल में, हमारे पास 200 * 20 माउंट पॉइंट और 200 * 20 कंट्रोल ग्रुप हैं। यदि सबसे ऊपरी मेम में पर्याप्त मेमोरी नहीं है, तो हम उसके सभी चाइल्ड मेमेक (यानी, आमतौर पर सब कुछ) को बायपास करने के लिए मजबूर हो जाएंगे, और उनमें से प्रत्येक के लिए हर एक को संकोची_लिस्ट से हटकर कॉल करना होगा। इस प्रकार, कर्नेल do_shrink_slab () फ़ंक्शन में 200 * 20 * 200 * 20 = 16000000 कॉल करेगा।

इसी समय, इस फ़ंक्शन पर कॉल की भारी संख्या बेकार हो जाएगी: कंटेनर आमतौर पर आपस में अलग-थलग होते हैं, और CT1 CT2 में बनाए गए सुपर_ब्लॉक 2 का उपयोग करने की संभावना आमतौर पर कम होती है। या, क्या समान है, अगर memcg1 CT1 से एक नियंत्रण समूह है, तो सुपर_ब्लॉक 2-> s_dentry_lru-> नोड-> memcg_lrus-> lru [memcg1_id] सरणी का संबंधित तत्व एक खाली सूची होगी, और do_shrink_sababl_sabab_sabink_sabab पर कोई नियंत्रण सूची नहीं होगी।

इस समस्या को एक सरल बैश लिपि (पैचसेट से डेटा, जिसे बाद में कर्नेल में पास किया गया था, यहां दिया गया है) का उपयोग करके मॉडलिंग की जा सकती है:

 $echo 1 > /sys/fs/cgroup/memory/memory.use_hierarchy $mkdir /sys/fs/cgroup/memory/ct $echo 4000M > /sys/fs/cgroup/memory/ct/memory.kmem.limit_in_bytes $for i in `seq 0 4000`; do mkdir /sys/fs/cgroup/memory/ct/$i; echo $$ > /sys/fs/cgroup/memory/ct/$i/cgroup.procs; mkdir -ps/$i; mount -t tmpfs $is/$i; touch s/$i/file; done

आइए देखते हैं कि अगर आप लगातार 5 बार कैश रीसेट प्रक्रिया को कॉल करते हैं तो क्या होता है:

 $time echo 3 > /proc/sys/vm/drop_caches

पहला पुनरावृति 14 सेकंड तक रहता है, क्योंकि कैश्ड ऑब्जेक्ट्स वास्तव में स्मृति में हैं: 0.00 उपयोगकर्ता 13.78 सिस्टम 0: 13.78 99% सीपीयू समाप्त हो गया ।
दूसरी पुनरावृत्ति में 5 सेकंड लगते हैं, हालांकि अधिक ऑब्जेक्ट नहीं हैं: 0.00user 5.59system 0: 05.60elapsed 99% CPU।
तीसरे पुनरावृत्ति में 5 सेकंड लगते हैं: 0.00user 5.48system 0: 05.48elapsed 99% CPU
चौथा पुनरावृत्ति 8 सेकंड लेता है: 0.00user 8.35system 0: 08.35elapsed 99% CPU
पांचवें पुनरावृत्ति में 8 सेकंड लगते हैं: 0.00user 8.34system 0: 08.35elapsed 99% CPU

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

नई संकोचन बाईपास एल्गोरिथ्म

नए एल्गोरिथ्म से मैं निम्नलिखित हासिल करना चाहता था:

उसे पुराने के दोषों से मुक्त करो और
नए ताले न जोड़ें। Do_shrink_slab () को केवल तब ही कॉल करें जब यह समझ में आता है (अर्थात, s_dentry_lru सरणी से या s_inode_lru सरणी से संबंधित लिंक सूची खाली नहीं है), लेकिन सीधे लिंक की गई मेमोरी का उपयोग न करें।

यह स्पष्ट था कि यह केवल विषम सिकुड़न के शीर्ष पर एक नई डेटा संरचना द्वारा प्रदान किया जा सकता है (इस आलेख में न केवल सुपरब्लॉक के सिक्योरर्स हैं, बल्कि अन्य डेटा ऑब्जेक्ट भी नहीं हैं। पाठक कीवर्ड प्रीलोक_श्रींकर () के लिए खोज करने के साथ खुद को परिचित कर सकता है। कर्नेल कोड में)। नई डेटा संरचना को दो राज्यों की कोडिंग की अनुमति देनी चाहिए: "यह do_shrink_slab () को कॉल करने के लिए समझ में आता है और" do_shrink_slab () को कॉल करने का कोई मतलब नहीं है।

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

प्रत्येक कंप्रेशर की अपनी विशिष्ट आईडी (संकोचक :: आईडी) प्राप्त होती है, और प्रत्येक मेकग में एक बिटमैप प्राप्त होता है, जो वर्तमान में पंजीकृत लोगों की सबसे बड़ी आईडी से युक्त होता है। जब पहला तत्व s_dentry_lru-> नोड-> memcg_lrus-> lru [memcg_id] सूची में जोड़ा जाता है, तो संबंधित मेम्क बिटमैप नंबर संकोचनकर्ता> आईडी के साथ 1 बिट पर सेट होता है। S_inode_id के साथ भी यही बात है।

अब संकोचन_slab () में लूप केवल आवश्यक कंप्रेशर्स को बायपास करने के लिए अनुकूलित किया जा सकता है:

 unsigned long shrink_slab() { … for_each_set_bit(i, map, shrinker_nr_max) { … shrinker = idr_find(&shrinker_idr, i); … do_shrink_slab(&sc, shrinker, priority); … } }

(बिट सफाई तब भी लागू की जाती है जब संकोचनकर्ता राज्य में प्रवेश करता है ”यह do_shrink_sab () को कॉल करने का कोई मतलब नहीं है। अधिक जानकारी के लिए गीथब को प्रतिबद्ध देखें।

यदि आप कैश रीसेट परीक्षण दोहराते हैं, तो नए एल्गोरिथ्म का उपयोग करके यह काफी बेहतर परिणाम दिखाता है:

 $time echo 3 > /proc/sys/vm/drop_caches

पहला चलना: 0.00user 1.10system 0: 01.10elapsed 99% CPU
दूसरा पुनरावृत्ति: 0.00user 0.00system 0: 00.01elapsed 64% CPU
तीसरा पुनरावृत्ति: 0.00user 0.01system 0: 00.01elapsed 82% CPU
चौथा पुनरावृत्ति: 0.00user 0.00system 0: 00.01elapsed 64% CPU
पांचवीं पुनरावृत्ति: 0.00user 0.01system 0: 00.01elapsed 82% CPU
पांचवें पुनरावृत्तियों के माध्यम से दूसरे की अवधि 0.01 सेकंड, पहले की तुलना में 548 गुना तेज है।

चूंकि मशीन पर मेमोरी की कमी के साथ कैश को रीसेट करने के लिए इसी तरह की क्रियाएं होती हैं, इसलिए यह अनुकूलन बड़ी संख्या में कंटेनरों और मेमोरी कंट्रोल समूहों के साथ मशीनों के संचालन में काफी सुधार करता है। पैच का एक सेट (17 टुकड़े) को वेनिला कोर में स्वीकार किया गया है, और आप इसे 4.19 संस्करण से शुरू कर सकते हैं।

पैच की समीक्षा करने की प्रक्रिया में, एक Google कर्मचारी दिखाई दिया, और यह पता चला कि उनके पास भी यही समस्या थी। इसलिए, पैच को एक अलग प्रकार के लोड पर आगे परीक्षण किया गया था।
नतीजतन, पैचसेट को 9 वें पुनरावृत्ति से अपनाया गया था; और वैनिला कोर में इसके प्रवेश में लगभग 4 महीने लगे। इसके अलावा, आज, पैचसेट को हमारे अपने वर्चुअज़ो 7 कर्नेल में शामिल किया गया है, जो संस्करण vz7.71.9 से शुरू होता है

कैसे और क्यों हमने लिनक्स कर्नेल में SLAB कैश की सफाई के लिए एल्गोरिथ्म को अनुकूलित किया

More articles: