क्या मुझे चिंतित होना चाहिए कि लगभग 40GB मुफ्त मेमोरी वाले होस्ट पर स्वैप का उपयोग किया जा रहा है?

Question

मेरा उत्पादन होस्ट नीचे है:

लगभग 40GB मुफ्त, अप्रयुक्त मेमोरी स्पेस को बनाए रखते हुए, सिस्टम 1GB स्वैप का उपयोग कर रहा है। क्या मुझे इस बारे में चिंतित होना चाहिए, या यह ज्यादातर सामान्य है?

Comments

वास्तव में, आपको लगभग 40GB मेमोरी बर्बाद करने वाले वास्तविक लोड के साथ एक उत्पादन होस्ट के बारे में चिंतित होना चाहिए। निश्चित रूप से यह उस मेमोरी को लगाने के लिए कुछ उपयोग कर सकता है - एप्लिकेशन डिस्क्स तक पहुंच रहे हैं, क्या वह उस मेमोरी का उपयोग उस डेटा में से कुछ को कैश करने के लिए, I / Os को कम करने और इसके प्रदर्शन में सुधार करने के लिए नहीं कर सकता है? 40GB मेमोरी क्यों काम कर रही मशीन पर बर्बाद हो रही है? यही आपको चिंतित होना चाहिए। वह सामान्य नहीं है।

— डेविड श्वार्ट्ज

यदि आप हमें इसका उत्पादन दिखाते हैं तो यह वास्तव में अधिक उपयोगी होगा free -m। ग्राफिक्स को पढ़ना मुश्किल है।

— user9517

@DavidSchwartz - मेरे पास एक संबंधित प्रश्न है जो अभी भी उस पर सक्रिय है। serverfault.com/questions/825909/…

— MrDuk

Answer 1

यह कोई समस्या नहीं है और सामान्य होने की संभावना है। बहुत सारे कोड (और संभवतः डेटा) का उपयोग शायद ही कभी किया जाता है, इसलिए सिस्टम मेमोरी को मुक्त करने के लिए इसे स्वैप करेगा।

अगर मेमोरी को लगातार और अंदर स्वैप किया जा रहा है तो स्वैपिंग केवल एक समस्या है। यह उस तरह की गतिविधि है जो प्रदर्शन को मारता है और सिस्टम पर कहीं और एक समस्या का सुझाव देता है।

यदि आप अपनी स्वैप गतिविधि की निगरानी करना चाहते हैं तो आप कई उपयोगिताओं के साथ कर सकते हैं लेकिन vmstatआमतौर पर यह काफी उपयोगी है

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 348256  73540 274600    0    0     1     9    9    6  2  0 98  0  0
 0  0      0 348240  73544 274620    0    0     0    16   28   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   29   33  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   21   23  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   24   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   23   23  0  0 100  0  0

पहली पंक्ति को अनदेखा करें क्योंकि यह गतिविधि शुरू होने के बाद से गतिविधि है। के तहत siऔर soस्तंभों पर ध्यान दें ---swap--; वे आम तौर पर काफी छोटे आंकड़े होने चाहिए यदि समय के बहुमत के लिए 0 नहीं।

यह भी ध्यान देने योग्य है कि इस प्रीमेप्टिव स्वैपिंग को कर्नेल सेटिंग के साथ नियंत्रित किया जा सकता है। फ़ाइल में /proc/sys/vm/swappiness0 और 100 के बीच एक संख्या होती है जो कर्नेल को बताती है कि मेमोरी को स्वैप करने के लिए कितनी आक्रामक है। यह देखने के लिए फ़ाइल सेट करें कि यह किस पर सेट है। डिफ़ॉल्ट रूप से, अधिकांश लिनक्स डिस्ट्रोस इसे 60 तक डिफ़ॉल्ट करते हैं, लेकिन यदि आप मेमोरी समाप्त होने से पहले कोई स्वैपिंग नहीं देखना चाहते हैं, तो फ़ाइल में 0 को इस तरह से प्रतिध्वनित करें:

echo 0 >/proc/sys/vm/swappiness

इसे जोड़कर स्थायी बनाया जा सकता है

vm.swappiness = 0

को /etc/sysctl.conf।

Comments

यह भी ध्यान देने योग्य है कि इस प्रीमेप्टिव स्वैपिंग को कर्नेल सेटिंग के साथ नियंत्रित किया जा सकता है। / Proc / sys / vm / swappiness की फ़ाइल में 0 और 100 के बीच एक संख्या होती है, जो कर्नेल को बताती है कि मेमोरी को स्वैप करने के लिए कितनी आक्रामक है। यह सेट करने के लिए फ़ाइल को कैट करें। डिफ़ॉल्ट रूप से, अधिकांश लिनक्स डिस्ट्रोस इसे 60 में डिफ़ॉल्ट करते हैं, लेकिन यदि आप मेमोरी समाप्त होने से पहले कोई स्वैपिंग नहीं देखना चाहते हैं, तो फ़ाइल में 0 को इस तरह से प्रतिध्वनित करें echo 0 >/proc/sys/vm/swappiness:। इसे vm.swappiness = 0/etc/sysctl.conf में जोड़कर स्थायी बनाया जा सकता है ।

— कुंवार

@virtex: मैं अपने डेस्कटॉप पर १ = १ या १० से कम किसी चीज़ का उपयोग करना पसंद करता हूं। यह ज्यादातर समय सर्वरों पर भी अच्छा कर सकता है। पूरी तरह से निषिद्ध किए बिना, अधिक पेजकेक के लिए रैम को मुक्त करने के लिए ज़ोरदार हतोत्साहित करना।

— पीटर कॉर्डेस

@PeterCordes सर्वरों, विशेष रूप से उन डेटाबेस तक पहुँचने या फ़ाइलों की सेवा करने के लिए ध्यान रखें। उन फ़ाइल कैश के लिए उपलब्ध स्मृति बनने से बहुत लाभ हो सकता है।

— जोनास श्फर

@JonasWielicki: यहां तक ​​कि swappiness=7कुछ या कुछ के साथ , लंबे समय तक अप्रयुक्त पृष्ठों की अदला-बदली होती है। कोई बड़ा swappiness=0मान और कोई मान भी कम अंतर है । कर्नेल-डिफॉल्ट swappiness=60आमतौर पर सर्वरों के लिए अच्छा होता है, और यह केवल डेस्कटॉप इंटरेक्टिव उपयोग के लिए होता है, जहाँ कम स्वैग अच्छा होता है। लेकिन इसे 7 या कुछ करने के लिए सेट करने से बहुत नुकसान नहीं होना चाहिए। (लेकिन मैंने जाँच नहीं की है, मैं एक सर्वर sysadmin नहीं हूँ)।

— पीटर कॉर्डेस

@PeterCordes जब तक आप मेमोरी प्रेशर नहीं डालते, तब तक कोई भी swappinessकाम बढ़िया नहीं होता। दबाव के साथ, आप देखेंगे कि swappiness=7फ़ाइल कैश को लगभग पूरी तरह से विस्तारित अवधि के लिए भुनाता है , जबकि swappiness=60बहुत सारे कैश को परिसमाप्त करता है, लेकिन सेकंड के भीतर बाहर स्वैप करना शुरू कर देता है। यह अभी भी कैश है जो धड़कन लेता है, लेकिन बहुत अधिक संतुलित तरीके से।

— कुबंझक

Answer 2

अगर यह करने के लिए बेहतर कुछ नहीं है, तो लिनक्स डिस्क से पहले के पन्नों को लिख देगा। इसका मतलब यह नहीं है कि यह उन पृष्ठों को स्मृति से बेदखल कर देगा, हालांकि। यह सिर्फ उस मामले में यह चाहिए भविष्य में कुछ समय उन पृष्ठों को बेदखल, यह है, क्योंकि वे पहले से ही देखते हैं प्रतीक्षा करने के लिए उन्हें डिस्क पर लिखे जाने की जरूरत नहीं है।

आखिरकार, आप जिस कारण से याददाश्त से बाहर चल रहे हैं, वह शायद इसलिए है क्योंकि आपकी मशीन पहले से ही कड़ी मेहनत कर रही है, आप स्वैपिंग के अलावा इसके अतिरिक्त बोझ नहीं चाहते हैं। जब मशीन कुछ नहीं कर रही हो तो स्वैपिंग करना बेहतर होगा।

एक समान कारण के लिए, आपकी स्मृति हमेशा भरी होनी चाहिए। मेमोरी पेज, फाइलसिस्टम कैशे, में tmpfsइतना सारा सामान होता है जिसे मेमोरी में रखा जा सकता है। वास्तव में, आपको चिंतित होना चाहिए कि क्या आपकी मेमोरी खाली है; आखिरकार, आपने इसके लिए बहुत सारे पैसे का भुगतान किया (कम से कम डिस्क स्थान की समान मात्रा की तुलना में), इसलिए इसका बेहतर उपयोग किया जाए!

Comments

जोर्ग, जिन पेजों को कर्नेल पूर्व में डिस्क में लिखते हैं, वे स्वैप पेज नहीं हैं, गंदे डिस्क कैश पेज हैं। Vm.dirty_background _... tunnables नियंत्रण करता है। स्वैप आउट गतिविधि स्वैनेन ट्यूनएबल के अनुसार शुरू होती है और निष्क्रिय समय की प्रतीक्षा नहीं करती है।

— लुकास

Answer 3

उपयोग किया गया स्वैप खराब नहीं है, लेकिन बहुत सारी स्वैप गतिविधि है

  vmstat 1
  procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
  6  0 521040 114564   6688 377308    8   13   639   173    0 1100  5  4 90  0
  1  0 521040 114964   6688 377448    0    0   256     0    0 1826  3  4 94  0
  0  0 521040 115956   6688 377448    0    0     0     0    0 1182  7  3 90  0
  0  0 521036 115992   6688 377448    4    0    16     0    0 1154 10  2 88  0
  3  0 521036 114628   6696 377640    0    0   928   224    0 1503 15 17 67  1

स्तंभ स्वैप कोई समस्या नहीं है। कॉलम सी पर गैर शून्य मान और इसलिए सर्वर प्रदर्शन के लिए घातक हैं। विशेष रूप से बहुत से RAM वाले।

कई जीबी रैम वाली मशीनों पर स्वैपन को अक्षम करना सबसे अच्छा है:

sysctl -w vm.swappiness=0

यह स्वैप को अक्षम नहीं करेगा। यह केवल लिनक्स को अंतिम उपाय के रूप में स्वैप का उपयोग करने का निर्देश देगा। यह कुछ MB प्रोग्रामों को बर्बाद कर देगा जिन्हें RAM में होने की आवश्यकता नहीं है ... लेकिन आपकी डिस्क एक्सेस कॉपियों को फूला हुआ स्वैप करने के लिए बेहतर है।

1 संपादित करें: स्वैच्छिकता का डिफ़ॉल्ट मान इष्टतम क्यों नहीं है

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

संपादित करें 2: क्यों सी इतनी गतिविधि सर्वरों के लिए घातक है?

Si और इसलिए टन के साथ मशीनों पर गतिविधि घातक है क्योंकि इसका मतलब है कि सिस्टम रैम के लिए खुद से लड़ रहा है। ऐसा क्या होता है कि रैम की तुलना में डिस्क, यहां तक ​​कि बड़े स्टोरेज भी धीमा होते हैं। आक्रामक स्वैप एप्लिकेशन डेटा पर कर्नेल डिस्क कैश का पक्षधर है और रैम के लिए लड़ने का सबसे आम स्रोत है। चूँकि OS को प्रत्येक si पर डिस्क कैश मुक्त करना होगा , अतिरिक्त कैश जो स्वैप प्रदान करता है उसके जीने का समय उपयोगी रास्ते के लिए बहुत कम है। नतीजा यह है कि आप कैश को स्टोर करने के लिए डिस्क बैंडविड्थ ले रहे हैं जो शायद उपयोग नहीं किया जाएगा और आपके प्रोग्राम को सी पेज के इंतजार में रोक देगा । अर्थ है कि अनुप्रयोगों के लिए बहुत कम या कोई लाभ नहीं के साथ बहुत सारे महत्वपूर्ण संसाधनों की खपत होती है।

प्रतिक्रिया के शीर्षक पर ध्यान दें "बहुत सारे रैम के साथ सर्वर पर स्वैप गतिविधि"। यह कभी-कभी सी और इतनी गतिविधि वाली मशीनों पर लागू नहीं होता है। यह भविष्य में लागू नहीं हो सकता है यदि ओएस में होशियार स्वैप एल्गोरिदम विकसित किए जाते हैं।

3 संपादित करें: "ठंडा" पृष्ठ

लोग स्वैपिंग एल्गोरिथम को रोमांटिक करते हैं। कुछ लोग कहते हैं "यह रैम के कम उपयोग किए जाने वाले पृष्ठों को लेता है", लेकिन यह वह नहीं है जो कर्नेल बिल्कुल नहीं करता है। स्वैप के बारे में समझना मुश्किल है कि कर्नेल को पता नहीं है कि "कोल्ड पेज" क्या है। कर्नेल के पास यह निर्धारित करने के लिए एक अच्छा मीट्रिक नहीं है कि क्या पृष्ठ का उपयोग किया जाता है या निकट भविष्य में उपयोग किए जाने की संभावना है। इस बात को दरकिनार करने के लिए कि कर्नेल बेतरतीब ढंग से स्वैप में पृष्ठों को रखता है और जिन पृष्ठों की आवश्यकता नहीं होती है, वे वहाँ रहते हैं। उस एल्गोरिथ्म की समस्या यह है कि पृष्ठों को स्वैप में जाने की आवश्यकता है ताकि पता चल सके कि क्या उन्हें अनुप्रयोगों द्वारा आवश्यक है। और इसका मतलब बहुत सारे "गर्म" पृष्ठ स्वैप पर जाएंगे। रैम की तुलना में डिस्क के साथ समस्या बहुत धीमी है।

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

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

Comments

"स्वैपीनेस को निष्क्रिय करने के लिए सर्वश्रेष्ठ" सर्वश्रेष्ठ, क्यों? (सर्वश्रेष्ठ, किस उद्देश्य के लिए?) डिफ़ॉल्ट सभी उपयोगों के लिए सही नहीं हो सकता है, लेकिन मुझे इसे बदलने के लिए एक कारण की आवश्यकता होगी।

— jpaugh

siआपके सर्वर से अधिक घातक कैसे है bi? दोनों का अर्थ है कि कुछ कार्यक्रम डिस्क से मेमोरी तक 4096 बाइट्स के पढ़ने की प्रतीक्षा कर रहे हैं। biकिसी भी फाइल से है, और siफ़ाइलों की एक विशिष्ट संकीर्ण श्रेणी से (लेकिन उनके बाइट्स के लिए कदम बस के रूप में तेजी से ठीक उसी पथ के माध्यम से)।

— कुबंझक

128MB RAM वाला 486 बहुत दुर्लभ था और इसे मेनफ़्रेम या सुपर कंप्यूटर माना जाता था - इस प्रकार CPU की संभावना 486 नहीं होती। मेरे पुराने 486 में 4MB RAM था और मुझे 16MB RAM (बड़े सर्वर) वाले मेरे मित्र की मशीन से ईर्ष्या थी 16 से 32 एमबी रैम) था। पेंटियम के आगे तेजी से और हम सामान्य के रूप में 8 से 16 एमबी देखना शुरू करते हैं। जब पेंटियम 3 पहली बार दिखाई दिया (जब सीपीयू सामान्य रूप से 1GHz से अधिक होने लगा) 32MB सामान्य था और वेब सर्वर में आमतौर पर 64 से 128MB था।

— स्लीवेटमैन

swappiness=0सर्वर के लिए पूरी तरह से अनुचित लगता है। आप इसे एक इंटरेक्टिव डेस्कटॉप सिस्टम के लिए विचार कर सकते हैं (लेकिन फिर भी, swappiness=1वास्तव में ठंडे पृष्ठों को स्वैप करने के लिए एक बेहतर विकल्प है)। एक और जवाब पर टिप्पणियाँ देखें । swappiness=7या कुछ OOM तक RAM में ठंडे पन्नों को पिन किए बिना स्वैप गतिविधि को नाटकीय रूप से कम कर देगा, और यह विचार करने के लायक है कि क्या आपको लगता 60है कि एक विशिष्ट सर्वर के लिए बहुत स्वैपी है।

— पीटर कॉर्डेस

@kubanczyk: मुझे लगता siहै कि इससे भी बदतर है bi। अधिकांश सर्वर सॉफ़्टवेयर को इस धारणा के आसपास डिज़ाइन किया गया है कि डिस्क से I / O धीमा हो सकता है, और I / O का इंतजार करते समय सामान्य रूप से उत्तरदायी बने रहने के लिए थ्रेड्स, Async I / O, या कुछ अन्य तकनीक का उपयोग करता है। पेज की गलती कहीं भी हो सकती है। सबसे खराब स्थिति में, एक धीमा पृष्ठ दोष लॉक लेने के बाद हो सकता है, अन्य महत्वपूर्ण सूत्र ~ 10ms (धीमे घूर्णी भंडारण पर स्वैप के साथ) के लिए उस महत्वपूर्ण खंड में प्रवेश करने से रोकते हैं। यदि एक महत्वपूर्ण खंड एक साझा डेटा संरचना से संभावित-ठंडे पेज पर डेटा की प्रतिलिपि बनाता है, तो यह प्रशंसनीय हो सकता है।

— पीटर कॉर्डेस

Answer 4

यह आपके प्रश्न का उत्तर नहीं है; बल्कि, एक अतिरिक्त निर्णय लेने में आपकी मदद करने के लिए सिर्फ अतिरिक्त जानकारी।

यदि आप जानना चाहते हैं कि कौन सी प्रक्रियाएँ विशेष रूप से कितनी अदला-बदली का उपयोग कर रही हैं, तो यहाँ थोड़ा शेल स्क्रिप्ट है:

#!/bin/bash

set -o posix
set -u

OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"` ; do
  PID=`echo $DIR | cut -d / -f 3`
  PROGNAME=`ps -p $PID -o comm --no-headers`

  SUM=0
  for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'` ; do
    let SUM=$SUM+$SWAP
  done
  echo "PID=$PID - Swap used: $SUM - ($PROGNAME )"

  let OVERALL=$OVERALL+$SUM
done
echo "Overall swap used: $OVERALL"

मुझे यह भी जोड़ना चाहिए कि tmpfs भी स्वैप करेंगे। यह प्रणाली का उपयोग करके आधुनिक लिनक्स सिस्टम पर अधिक सामान्य है जो tmpfs का उपयोग करके उपयोगकर्ता-स्पेस / tmp ओवरले बनाते हैं।

Comments

अच्छी पटकथा। स्मेम पर भी नजर डालें।

— user9517

मुझे लगता है कि आप लिख सकते हैं कि बहुत अधिक कुशलता से ( अभी तक कम कांटे की प्रक्रियाओं के साथ) awk '/Swap/ {sw += $2} FNR==1 { /*first line of a new file */ find the command somehow, maybe still fork/exec ps;} END { print totals }' /proc/[0-9]*/smaps। यह हर प्रक्रिया के लिए कट और पीएस चलाता है, और सिस्टम में हर प्रक्रिया के लिए grep + awk कई बार।

— पीटर कॉर्डेस

Answer 5

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

DBA की दुनिया में सर्वसम्मति से प्रतीत होता है कि "यह सामान्य ज्ञान है कि जब आप MySQL (या वास्तव में कोई अन्य DBMS) चला रहे हैं, तो आप अपने स्वैप स्थान में किसी भी I / O को नहीं देखना चाहते हैं। कैश आकार का स्केलिंग (उपयोग करके) innodb_buffer_pool_size in MySQL के मामले में) यह सुनिश्चित करने के लिए मानक अभ्यास है कि पर्याप्त स्वतंत्र मेमोरी है, इसलिए स्वैपिंग की आवश्यकता नहीं है।

लेकिन क्या होगा अगर आप कुछ गलती करते हैं या मिसकॉल करते हैं, और स्वैपिंग होती है? यह वास्तव में प्रदर्शन को कितना प्रभावित करता है? यह वही है जो मैंने जांच के लिए निर्धारित किया है। "

मुझे आशा है कि पाठकों को निम्नलिखित लिंक एप्रोपोस मिलेंगे।

https://www.percona.com/blog/2017/01/13/impact-of-swapping-on-mysql-performance/

https://www.percona.com/blog/2010/01/18/why-swapping-is-bad-for-mysql-performance/

Comments

सर्वर दोष में आपका स्वागत है! जब भी यह सैद्धांतिक रूप से प्रश्न का उत्तर दे सकता है, तो उत्तर के आवश्यक भागों को शामिल करना और संदर्भ के लिए लिंक प्रदान करना बेहतर होगा ।

— फ्रेडरिक नीलसन