/ Var / log / संदेशों के साथ आउट-ऑफ-मेमोरी को डीबग करें

Question

निम्नलिखित रिपोर्ट मेरे संदेश लॉग में डाली गई है:

kernel: Out of memory: Kill process 9163 (mysqld) score 511 or sacrifice child
kernel: Killed process 9163, UID 27, (mysqld) total-vm:2457368kB, anon-rss:816780kB, file-rss:4kB

इससे कोई फर्क नहीं पड़ता कि यह समस्या है या नहीं httpd, लेकिन मैं उत्सुक हूं कि मैं इस समस्या को कैसे डीबग करना जारी रख सकता हूं।mysqldpostfix

मुझे इस बारे में अधिक जानकारी कैसे मिल सकती है कि पीआईडी ​​9163 क्यों मारा गया है और मुझे यकीन नहीं है कि अगर लिनक्स कहीं न कहीं समाप्त पीआईडी ​​के लिए इतिहास रखता है।

यदि यह आपके संदेश लॉग फ़ाइल में होता है तो आप इस समस्या को चरण दर चरण समस्या निवारण कैसे करेंगे?

# free -m

             total       used       free     shared    buffers     cached
Mem:          1655        934        721          0         10         52
-/+ buffers/cache:        871        784
Swap:          109          6        103`

Comments

समस्या के बारे में सभी संदेश क्या दिखाते हैं dmesg?

— स्टार्क

OOM के बारे में उपयोगी विवरण - linux-mm.org/OOM_Killer ।

— स्लम

Answer 1

कर्नेल ने ऐसा होने से पहले सामान का एक गुच्छा लॉग किया होगा, लेकिन इसमें से अधिकांश /var/log/messagesआपके (r)syslogdद्वारा कॉन्फ़िगर किए जाने के आधार पर नहीं होगा । प्रयत्न, कोशिश:

grep oom /var/log/*
grep total_vm /var/log/*

पूर्व को केवल एक या दो स्थानों पर बार का एक गुच्छा दिखाना चाहिए। यह वह फ़ाइल है जिसे आप देखना चाहते हैं।

फ़ाइलों में से एक में मूल "मेमोरी से बाहर" लाइन ढूंढें total_vm। एक मिनट के लिए तीस सेकंड (अधिक हो सकता है, कम हो सकता है) उस रेखा से पहले आपको कुछ ऐसा मिलेगा:

kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

आपको उस लाइन और "आउट ऑफ़ मेमोरी" लाइन के बीच में एक टेबल भी मिलनी चाहिए, जैसे हेडर:

[ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name

हो सकता है कि यह आपको पहले से पता होने की तुलना में बहुत अधिक न बताए, लेकिन क्षेत्र हैं:

• pid प्रक्रिया आईडी।
• यूआईडी यूजर आईडी।
• tgid थ्रेड समूह ID।
• Total_vm वर्चुअल मेमोरी उपयोग (4 kB पृष्ठों में)
• rss निवासी स्मृति उपयोग (4 kB पृष्ठों में)
• nr_ptes पृष्ठ तालिका प्रविष्टियाँ
• swapents प्रविष्टियों स्वैप
• oom_score_adj आमतौर पर 0; एक कम संख्या इंगित करती है कि ओओएम हत्यारे के आह्वान पर प्रक्रिया की मृत्यु होने की संभावना कम होगी।

आप ज्यादातर अनदेखी कर सकते हैं nr_ptesऔर swapentsहालांकि मेरा मानना ​​है कि ये निर्धारित करने में कारक हैं कि कौन मारा जाता है। यह जरूरी नहीं कि सबसे अधिक स्मृति का उपयोग करने वाली प्रक्रिया है, लेकिन यह बहुत संभावना है। चयन प्रक्रिया के बारे में अधिक जानकारी के लिए, यहाँ देखें । मूल रूप से, उच्चतम ओओम स्कोर के साथ समाप्त होने वाली प्रक्रिया को मार दिया जाता है - यह "स्कोर" "आउट ऑफ मेमोरी" लाइन पर रिपोर्ट किया गया है; दुर्भाग्य से अन्य स्कोर की सूचना नहीं है, लेकिन यह तालिका कारकों के संदर्भ में कुछ सुराग प्रदान करती है।

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

Comments

dmesgजहां यह होने की गारंटी है। यह केवल तभी होगा /var/logजब syslog डेमन से पढ़ता है /dev/kmsg(जो यह आमतौर पर हालांकि करता है)।

— पैट्रिक

@Patrick जब आप देखने जाते हैं तो निर्भर करता है । यदि यह सामान्य फ़ाइल लॉग में से एक में दर्ज किया गया है (यह होना चाहिए, या आपने अपने लकड़हारे के साथ कुछ बेवकूफी की है), तो यह लंबे समय तक रहेगा, जबकि इस बिंदु से, यदि ओपी एक समस्या का निदान करना चाहता है, जो हुआ कल, या एक दिन पहले, आदि, रिकॉर्ड dmesgअब और नहीं भी हो सकता है, भले ही सिस्टम को छोड़ दिया गया हो।

— गोल्डीलॉक्स

Answer 2

इस संदेश की कुंजी संदेश में ही है - मेमोरी से बाहर । जब लिनक्स कर्नेल को वर्चुअल मेमोरी (भौतिक रैम प्लस स्वैप) से भूखा किया जाता है, तो यह मारना शुरू कर देगा और ठीक वैसा ही यहां हुआ। ऐसा लगता है कि mysqld2GB से अधिक वर्चुअल मेमोरी का उपयोग कर रहा था।

सिस्टम में कितना RAM और स्वैप है? मैं अतिरिक्त रैम जोड़ने पर विचार करूंगा या, यदि यह संभव नहीं है, तो अतिरिक्त स्वैप जोड़ना। कम से कम प्रक्रियाओं को त्वरित रूप से ठीक करने से रोकने के लिए आप स्वैप फ़ाइल जोड़ सकते हैं।

अपडेट: आपके पास रैम की मात्रा को देखते हुए, आप तुरंत समस्या देख सकते हैं। आपके पास ~ 1.6GB RAM और 100MB स्वैप है फिर भी MySQL इससे कहीं अधिक RAM का उपयोग कर रहा है। यह बताता है कि आप प्रक्रियाओं को समाप्त क्यों देख रहे हैं।

Comments

total used free shared buffers cached Mem: 1655 934 721 0 10 52 -/+ buffers/cache: 871 784 Swap: 109 6 103 यह उसी समय मेमोरी आउटपुट है जब प्रक्रिया को मार दिया गया था

— ibedelovski

क्या आप संभवत: मूल संदेश में, स्वरूपण को बनाए रखने के साथ पेस्ट कर सकते हैं? पढ़ने में आसानी होगी।

— mjturner

मैं वास्तव में प्रारूपण में अच्छा नहीं हूं ... लेकिन मूल संदेश में पहले से ही इसे चिपका देता

— हूं