सवाल क्या मुझे चिंतित होना चाहिए कि मेजबान पर 40 जीबी की मुफ्त मेमोरी के साथ स्वैप का इस्तेमाल किया जा रहा है?


मेरे पास एक उत्पादन मेजबान है, नीचे:

htop

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


39
2018-01-12 17:04


मूल


असल में, आपको एक उत्पादन मेजबान के बारे में चिंतित होना चाहिए जिसमें असली भार लगभग 40 जीबी की बर्बादी बर्बाद हो। निश्चित रूप से यह उस स्मृति को रखने के लिए कुछ उपयोग ढूंढ सकता है - एप्लिकेशन डिस्क तक पहुंच रहे हैं, क्या वह उस मेमोरी का उपयोग उस डेटा को कैश करने, आई / ओएस को कम करने और इसके प्रदर्शन में सुधार करने के लिए नहीं कर सकता? मशीन पर 40 जीबी मेमोरी बर्बाद हो रही है जो काम कर रही है? यही आपको चिंतित होना चाहिए। यह सामान्य नहीं है। - David Schwartz
यदि आप हमें आउटपुट दिखाते हैं तो यह वास्तव में अधिक उपयोगी होगा free -m। ग्राफिक्स पढ़ने के लिए मुश्किल हैं। - Iain
@ डेविडस्वार्टज़ - मेरे पास एक संबंधित प्रश्न है जो अभी भी उस पर सक्रिय है। serverfault.com/questions/825909/... - MrDuk


जवाब:


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

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

यदि आप अपनी स्वैप गतिविधि की निगरानी करना चाहते हैं तो आप कई उपयोगिताओं के साथ कर सकते हैं 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 नहीं होने पर उन्हें आम तौर पर काफी छोटे आंकड़े होना चाहिए।

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

echo 0 >/proc/sys/vm/swappiness

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

vm.swappiness = 0

सेवा मेरे /etc/sysctl.conf


68
2018-01-12 17:10



उल्लेखनीय है कि यह प्रीemptive स्वैपिंग कर्नेल सेटिंग के साथ नियंत्रित किया जा सकता है। / Proc / sys / vm / swappiness पर फ़ाइल में 0 और 100 के बीच एक संख्या होती है जो कर्नेल को स्मृति को स्वैप करने के लिए आक्रामक रूप से बताती है। फ़ाइल को यह देखने के लिए बिल्ली को सेट करें कि यह क्या सेट है। डिफ़ॉल्ट रूप से, अधिकांश लिनक्स डिस्ट्रोज़ इसे 60 तक डिफ़ॉल्ट करते हैं, लेकिन यदि आप स्मृति समाप्त होने से पहले कोई स्वैपिंग नहीं देखना चाहते हैं, तो इस तरह फ़ाइल में 0 को प्रतिबिंबित करें: echo 0 >/proc/sys/vm/swappiness। इसे जोड़कर स्थायी बनाया जा सकता है vm.swappiness = 0 /etc/sysctl.conf करने के लिए। - virtex
@virtex: मुझे अपने डेस्कटॉप पर swappiness = 1, या 10 से कम कुछ का उपयोग करना पसंद है। यह सर्वर पर ज्यादातर समय भी अच्छा प्रदर्शन कर सकता है। इसे पूरी तरह से निषिद्ध किए बिना, अधिक पेजकेच के लिए रैम को मुक्त करने के लिए स्वैपिंग को हतोत्साहित करें। - Peter Cordes
@ पीटरकॉर्डर्स सर्वरों की देखभाल करें, विशेष रूप से उन डेटाबेस तक पहुंचने या फ़ाइलों की सेवा करने वाले। फाइल कैश के लिए स्मृति उपलब्ध होने से बहुत लाभ हो सकता है। - Jonas Schäfer
@ जोनासविएलिकी: यहां तक ​​कि साथ swappiness=7 या कुछ, दीर्घकालिक अप्रयुक्त पृष्ठ स्वैप हो जाते हैं। बीच में एक बड़ा अंतर है swappiness=0 और कोई अन्य मूल्य, यहां तक ​​कि कम मूल्य भी। कर्नेल-डिफ़ॉल्ट swappiness=60 आम तौर पर सर्वर के लिए अच्छा है, और यह केवल डेस्कटॉप इंटरैक्टिव उपयोग के लिए है जहां कम स्वैपनेस अच्छा है। लेकिन इसे 7 या किसी चीज़ पर सेट करना ज्यादा चोट नहीं पहुंचाएगा। (लेकिन मैंने जांच नहीं की है, मैं सर्वर sysadmin नहीं हूँ)। - Peter Cordes
@ पीटरकॉर्डिस जब तक आप मेमोरी दबाव नहीं डालते, कोई भी swappiness बहुत अच्छा काम करता है। दबाव के साथ, आप इसे देखेंगे swappiness=7 फ़ाइल कैश भूखा है लगभग पूरी तरह से समय की एक विस्तृत अवधि के लिए, जबकि swappiness=60 बहुत सारे कैश को तरल करता है लेकिन सेकंड के भीतर भी स्वैप करना शुरू कर देता है। यह अभी भी कैश है जो धड़कता है, लेकिन एक अधिक संतुलित तरीके से। - kubanczyk


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

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

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


25
2018-01-13 00:02



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


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

  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

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

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

sysctl -w vm.swappiness=0

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

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

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

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

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

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

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

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

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

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


10
2018-01-12 19:27



"स्वैपनेस अक्षम करने के लिए सर्वश्रेष्ठ" सर्वश्रेष्ठ, क्यों? (सर्वश्रेष्ठ, किस उद्देश्य के लिए?) डिफ़ॉल्ट सभी उपयोगों के लिए सही नहीं हो सकता है, लेकिन मुझे अभी भी इसे बदलने का एक कारण चाहिए। - jpaugh
कैसे si आपके सर्वर से अधिक घातक bi? दोनों का मतलब है कि कुछ प्रोग्राम 4096 बाइट्स को डिस्क से स्मृति में पढ़ने के लिए इंतजार कर रहा है। bi किसी भी फाइल से है, और si फ़ाइलों की एक विशिष्ट संकीर्ण श्रेणी से (लेकिन उनके बाइट्स स्थानांतरित होते हैं बस तेज़ बिल्कुल उसी मार्ग के माध्यम से)। - kubanczyk
128 एमबी रैम वाला 486 बहुत दुर्लभ था और इसे मेनफ्रेम या सुपरकंप्यूटर माना जाएगा - इस प्रकार सीपीयू की संभावना 486 थी। मेरी पुरानी 486 में 4 एमबी रैम थी और मैं 16 एमबी रैम (बड़े सर्वर) के साथ अपने दोस्त की मशीन से ईर्ष्यावान था 16 से 32 एमबी रैम था)। पेंटियम के लिए तेज़ आगे और हम 8 से 16 एमबी सामान्य के रूप में देखना शुरू करते हैं। जब पेंटियम 3 पहली बार दिखाई देता था (जब सीपीयू सामान्य रूप से 1GHz से अधिक शुरू होता है) 32 एमबी सामान्य था और वेब सर्वरों में आमतौर पर 64 से 128 एमबी था। - slebetman
swappiness=0 सर्वर के लिए पूरी तरह से अनुचित लगता है। आप इसे एक इंटरैक्टिव डेस्कटॉप सिस्टम के लिए मान सकते हैं (लेकिन फिर भी, swappiness=1 वास्तव में वास्तव में ठंडा पृष्ठों को स्वैप करने के लिए एक बेहतर विकल्प है)। देख एक और जवाब पर टिप्पणी। swappiness=7 या कुछ ओओएम तक रैम में ठंडे पृष्ठों को पिन किए बिना नाटकीय रूप से स्वैप गतिविधि को कम कर देगा, और यदि आप सोचते हैं तो विचार करने योग्य है 60 एक विशिष्ट सर्वर के लिए बहुत swappy है। - Peter Cordes
@kubanczyk: मुझे लगता है si से भी बदतर है bi। अधिकांश सर्वर सॉफ़्टवेयर को इस धारणा के चारों ओर डिज़ाइन किया गया है कि डिस्क से I / O धीमा हो सकता है, और I / O पर प्रतीक्षा करते समय सामान्य रूप से उत्तरदायी बने रहने के लिए थ्रेड, async I / O, या कुछ अन्य तकनीक का उपयोग करता है। एक पेज गलती कहीं भी हो सकती है। सबसे बुरे मामले में, लॉक लेने के बाद धीमी पृष्ठ की गलती हो सकती है, अन्य सभी धागे को ~ 10ms के लिए उस महत्वपूर्ण खंड में प्रवेश करने से रोकना (धीमी घूर्णन भंडारण पर स्वैप के साथ)। यह संभव हो सकता है यदि कोई महत्वपूर्ण अनुभाग किसी साझा डेटा संरचना से संभावित रूप से-ठंडे पृष्ठ पर डेटा कॉपी करता है। - Peter Cordes


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

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

#!/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 भी स्वैप कर देगा। यह systemd का उपयोग कर आधुनिक लिनक्स सिस्टम पर अधिक आम है जो tmpfs का उपयोग कर उपयोगकर्ता-स्थान / tmp ओवरले बनाते हैं।


8
2018-01-12 18:09



अच्छी लिपि स्मेम पर भी एक नज़र डालें। - Iain
मुझे लगता है कि आप इसे और अधिक कुशलता से लिख सकते हैं (दूर कम फोर्क प्रक्रियाओं के साथ) 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 कई बार। - Peter Cordes


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

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

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

मुझे आशा है कि पाठकों को निम्न लिंक apropos मिल जाएगा।

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/


-1
2018-03-24 15:13



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