समर्पित चूल्हा स्मृति और OOM किलर हस्तक्षेप

फिर से नमस्कार! अगले लेख का अनुवाद विशेष रूप से कुबेरनेट्स-आधारित इन्फ्रास्ट्रक्चर प्लेटफॉर्म पाठ्यक्रम के छात्रों के लिए तैयार किया गया था, जो इस महीने से शुरू हो रहा है। आइए शुरू करते हैं।



हाल के दिनों में, मेरे कुछ पॉड्स लगातार दुर्घटनाग्रस्त हो गए हैं, ओएस सिस्टम लॉग में एक नोट छोड़कर कि OOM किलर ने कंटेनर प्रक्रिया को नष्ट कर दिया है। मैंने यह पता लगाने का फैसला किया कि ऐसा क्यों हो रहा है।

चूल्हा स्मृति सीमा और cgroup स्मृति सेटिंग्स

के 3 एस वितरण पर परीक्षण करते हैं। हम 123 MiB (123 Mi) की एक विशिष्ट मेमोरी सीमा के साथ निर्माण करते हैं।

kubectl run --restart=Never --rm -it --image=ubuntu --limits='memory=123Mi' -- sh If you don't see a command prompt, try pressing enter. root@sh:/# 

किसी अन्य कंसोल में, चूल्हा के uid पता लगाएं।

 kubectl get pods sh -o yaml | grep uid uid: bc001ffa-68fc-11e9-92d7-5ef9efd9374c 

सर्वर के नीचे जहां यह चल रहा है, हम वांछित पॉड के uid निर्दिष्ट करके cgroup मापदंडों का पता cgroup ।

 cd /sys/fs/cgroup/memory/kubepods/burstable/podbc001ffa-68fc-11e9-92d7-5ef9efd9374c cat memory.limit_in_bytes 128974848 

128974848 बिल्कुल 123 MiB (123 * 1024 * 1024) है। स्थिति साफ हो रही है। यह पता चला है कि कुबेरनेट्स में, मेमोरी सीमा को cgroup के माध्यम से सेट किया गया है। जैसे ही आवंटित मेमोरी सीमा बढ़ती है, cgroup कंटेनर प्रक्रिया के विनाश की शुरुआत करता है।

तनाव परीक्षण

चलो खुले कमांड कंसोल सत्र के माध्यम से चूल्हा का परीक्षण करने के लिए उपयोगिताओं को स्थापित करें।

 root@sh:/# apt update; apt install -y stress 

उसी समय, हम dmesg -Tw साथ syslog प्रविष्टियों को ट्रैक करेंगे।

सबसे पहले, तनाव परीक्षण उपयोगिता को चलाएं, स्मृति में 100 एमबी आवंटित करें। प्रक्रिया सफलतापूर्वक शुरू हुई।

 root@sh:/# stress --vm 1 --vm-bytes 100M & [1] 271 root@sh:/# stress: info: [271] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd 

अब हम दूसरा तनाव परीक्षण करेंगे।

 root@sh:/# stress --vm 1 --vm-bytes 50M stress: info: [273] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd stress: FAIL: [271] (415) <-- worker 272 got signal 9 stress: WARN: [271] (417) now reaping child worker processes stress: FAIL: [271] (451) failed run completed in 7s 

लॉन्च ने सिग्नल 9 पर पहले तनाव परीक्षण (पीआईडी ​​271) की प्रक्रिया के तात्कालिक विनाश का नेतृत्व किया।

इस बीच, सिस्टम लॉग में निम्नलिखित प्रविष्टियाँ दिखाई दीं:

[Sat Apr 27 22:56:09 2019] stress invoked oom-killer: gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=939
[Sat Apr 27 22:56:09 2019] stress cpuset=a2ed67c63e828da3849bf9f506ae2b36b4dac5b402a57f2981c9bdc07b23e672 mems_allowed=0
[Sat Apr 27 22:56:09 2019] CPU: 0 PID: 32332 Comm: stress Not tainted 4.15.0-46-generic #49-Ubuntu
[Sat Apr 27 22:56:09 2019] Hardware name: BHYVE, BIOS 1.00 03/14/2014
[Sat Apr 27 22:56:09 2019] Call Trace:
[Sat Apr 27 22:56:09 2019] dump_stack+0x63/0x8b
[Sat Apr 27 22:56:09 2019] dump_header+0x71/0x285
[Sat Apr 27 22:56:09 2019] oom_kill_process+0x220/0x440
[Sat Apr 27 22:56:09 2019] out_of_memory+0x2d1/0x4f0
[Sat Apr 27 22:56:09 2019] mem_cgroup_out_of_memory+0x4b/0x80
[Sat Apr 27 22:56:09 2019] mem_cgroup_oom_synchronize+0x2e8/0x320
[Sat Apr 27 22:56:09 2019] ? mem_cgroup_css_online+0x40/0x40
[Sat Apr 27 22:56:09 2019] pagefault_out_of_memory+0x36/0x7b
[Sat Apr 27 22:56:09 2019] mm_fault_error+0x90/0x180
[Sat Apr 27 22:56:09 2019] __do_page_fault+0x4a5/0x4d0
[Sat Apr 27 22:56:09 2019] do_page_fault+0x2e/0xe0
[Sat Apr 27 22:56:09 2019] ? page_fault+0x2f/0x50
[Sat Apr 27 22:56:09 2019] page_fault+0x45/0x50
[Sat Apr 27 22:56:09 2019] RIP: 0033:0x558182259cf0
[Sat Apr 27 22:56:09 2019] RSP: 002b:00007fff01a47940 EFLAGS: 00010206
[Sat Apr 27 22:56:09 2019] RAX: 00007fdc18cdf010 RBX: 00007fdc1763a010 RCX: 00007fdc1763a010
[Sat Apr 27 22:56:09 2019] RDX: 00000000016a5000 RSI: 0000000003201000 RDI: 0000000000000000
[Sat Apr 27 22:56:09 2019] RBP: 0000000003200000 R08: 00000000ffffffff R09: 0000000000000000
[Sat Apr 27 22:56:09 2019] R10: 0000000000000022 R11: 0000000000000246 R12: ffffffffffffffff
[Sat Apr 27 22:56:09 2019] R13: 0000000000000002 R14: fffffffffffff000 R15: 0000000000001000
[Sat Apr 27 22:56:09 2019] Task in /kubepods/burstable/podbc001ffa-68fc-11e9-92d7-5ef9efd9374c/a2ed67c63e828da3849bf9f506ae2b36b4dac5b402a57f2981c9bdc07b23e672 killed as a result of limit of /kubepods/burstable/podbc001ffa-68fc-11e9-92d7-5ef9efd9374c
[Sat Apr 27 22:56:09 2019] memory: usage 125952kB, limit 125952kB, failcnt 3632
[Sat Apr 27 22:56:09 2019] memory+swap: usage 0kB, limit 9007199254740988kB, failcnt 0
[Sat Apr 27 22:56:09 2019] kmem: usage 2352kB, limit 9007199254740988kB, failcnt 0
[Sat Apr 27 22:56:09 2019] Memory cgroup stats for /kubepods/burstable/podbc001ffa-68fc-11e9-92d7-5ef9efd9374c: cache:0KB rss:0KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_anon:0KB active_anon:0KB inactive_file:0KB active_file:0KB unevictable:0KB
[Sat Apr 27 22:56:09 2019] Memory cgroup stats for /kubepods/burstable/podbc001ffa-68fc-11e9-92d7-5ef9efd9374c/79fae7c2724ea1b19caa343fed8da3ea84bbe5eb370e5af8a6a94a090d9e4ac2: cache:0KB rss:48KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_anon:0KB active_anon:48KB inactive_file:0KB active_file:0KB unevictable:0KB
[Sat Apr 27 22:56:09 2019] Memory cgroup stats for /kubepods/burstable/podbc001ffa-68fc-11e9-92d7-5ef9efd9374c/a2ed67c63e828da3849bf9f506ae2b36b4dac5b402a57f2981c9bdc07b23e672: cache:0KB rss:123552KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:0KB writeback:0KB inactive_anon:0KB active_anon:123548KB inactive_file:0KB active_file:0KB unevictable:0KB
[Sat Apr 27 22:56:09 2019] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
[Sat Apr 27 22:56:09 2019] [25160] 0 25160 256 1 28672 0 -998 pause
[Sat Apr 27 22:56:09 2019] [25218] 0 25218 4627 872 77824 0 939 bash
[Sat Apr 27 22:56:09 2019] [32307] 0 32307 2060 275 57344 0 939 stress
[Sat Apr 27 22:56:09 2019] [32308] 0 32308 27661 24953 253952 0 939 stress
[Sat Apr 27 22:56:09 2019] [32331] 0 32331 2060 304 53248 0 939 stress
[Sat Apr 27 22:56:09 2019] [32332] 0 32332 14861 5829 102400 0 939 stress
[Sat Apr 27 22:56:09 2019] Memory cgroup out of memory: Kill process 32308 (stress) score 1718 or sacrifice child
[Sat Apr 27 22:56:09 2019] Killed process 32308 (stress) total-vm:110644kB, anon-rss:99620kB, file-rss:192kB, shmem-rss:0kB
[Sat Apr 27 22:56:09 2019] oom_reaper: reaped process 32308 (stress), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

मेमोरी से बाहर होने के कारण PID 32308 के साथ प्रक्रिया को नष्ट कर दिया गया था। लेकिन सबसे दिलचस्प बात जर्नल प्रविष्टियों के अंत में छिपी है:



यहां इस चूल्हा की प्रक्रियाएं हैं जो ओओएम किलर घटक द्वारा विनाश के लिए उम्मीदवारों के रूप में चिह्नित हैं। बेस pause प्रक्रिया, जो नेटवर्क नेमस्पेस को स्टोर करती है, को oom_score_adj एक oom_score_adj स्कोर प्राप्त -998 , जिसका अर्थ है कि प्रक्रिया नष्ट नहीं होगी। कंटेनर में शेष प्रक्रियाओं को 939 का एक oom_score_adj स्कोर प्राप्त हुआ। आप इस मूल्य को नीचे कुबेरनेट प्रलेखन से सूत्र का उपयोग करके सत्यापित कर सकते हैं:

 min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) 

हम नोड के लिए उपलब्ध स्मृति की मात्रा का पता लगाते हैं:

 kubectl describe nodes k3s | grep Allocatable -A 5 Allocatable: cpu: 1 ephemeral-storage: 49255941901 hugepages-1Gi: 0 hugepages-2Mi: 0 memory: 2041888Ki 

यदि अनुरोधित मेमोरी का आकार निर्दिष्ट नहीं है, तो डिफ़ॉल्ट रूप से यह सीमा के बराबर होगा। मानों को प्रतिस्थापित करते हुए, हमें निम्नलिखित oom_score_adj मान मिलता है: 1000–123*1024/2041888=938.32 , जो सिस्टम लॉग में निर्दिष्ट मूल्य 939 बहुत करीब है। (मुझे नहीं पता कि ओओएम किलर को 939 का सटीक मूल्य कैसे मिलता है।)

तो, कंटेनर में सभी प्रक्रियाओं का समान oom_score_adj मान है। OOM किलर घटक मेमोरी उपयोग के आधार पर OOM मान की गणना करता है और परिणाम को oom_score_adive स्कोर के आधार पर समायोजित करता है। और, अंततः, यह पहले तनाव परीक्षण की प्रक्रिया को नष्ट कर देता है, जो कि अधिकांश मेमोरी, 100 एमबी को खा जाता है, जो अनुमान oom_score = 1718 से मेल खाती है।

निष्कर्ष

कुबेरनेट्स cgroup और OOM Killer घटकों के माध्यम से चूल्हा स्मृति सीमा को नियंत्रित करता है। ओओएम ऑपरेटिंग सिस्टम और ओओएम चूल्हा की शर्तों पर सावधानीपूर्वक सहमत होना आवश्यक है।

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