क्या आपको SSD के साथ पेज फाइल को डिसेबल करना चाहिए?


26

मैं इस प्रश्न को पढ़ रहा हूं , और इसमें बहुत सारी जानकारी है।

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

मेरी समझ से, पृष्ठ फ़ाइल के बिना, जैसे ही आप अपनी रैम की सीमा तक पहुँचते हैं, डिस्क पर थ्रेशिंग ट्रिगर हो सकता है। लेकिन SSDs के लिए थ्रशिंग की कोई अवधारणा नहीं है, रीड्स तेज हैं।

आप लोग क्या सोचते हैं?


मैं इसे छोड़ दूँगा। आधुनिक SSD की दूरी तय करनी चाहिए। देखें: storagesearch.com/ssdmyths-endurance.html
मैट

1
इसके अलावा, आपके कार्यभार को प्रदान करना आपके सर्वर के लिए उपयुक्त है, आपको शायद ही वैसे भी डिस्क पर पेजिंग करना चाहिए (ठीक है, केवल पेजिंग जहां इसका लाभ है)। पिछले महीने अकेले औसतन मेरे सर्वर ने पूरे महीने के लिए केवल 100 पेज इन्स / आउट किए हैं।
मैथ्यू इफ

जवाबों:


22

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

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

गरीब इंटरनेट से पीड़ित SSDs के बारे में अधिक से अधिक इंटरनेट और सर्वर फाल्ट पर, दोनों में गलत सूचना की एक बड़ी मात्रा है। प्रारंभिक मॉडल SSDs में अच्छी तरह से समस्याएं हो सकती हैं, और USB फ्लैश ड्राइव निश्चित रूप से नीचा दिखाना शुरू कर देते हैं, लेकिन एंटरप्राइज़-क्लास SSDs में बेहतर पहनने वाले एल्गोरिदम होते हैं और कुछ प्रदर्शन और पहनने में सुधार के लिए स्पेयर फ्लैश का उपयोग करते हैं।

उदाहरण के लिए, इंटेल X25-E ड्राइव , 32 GB ड्राइव के लिए रैंडम राइट्स की 1 पेटाबाइट की एक लिखित अवधि का दावा करता है। यदि आप लेखन इंटरफ़ेस (200 एमबी / सेकंड) को नॉनस्टॉप कर रहे हैं, तो ओवरराइट के साथ, मेरा अनुमान है कि यह आपको 58 दिनों तक चलेगा। लेकिन उस ड्राइव पर प्रति दिन 17 टीबी डेटा की तरह कुछ लिख रहा है।

ओएस ड्राइव पर विशिष्ट सर्वर काम का बोझ कहीं कम होने जा रहा है, भले ही आपके पास एक पृष्ठ फ़ाइल हो। इसे प्रतिदिन 50 जीबी पर कॉल करें। यदि 1 पीबी आंकड़ा सटीक है (और मुझे पता है कि इसे एक औसत आंकड़ा माना जा सकता है, अधिक चर्चा बाद में), तो वह अभी भी 50 वर्षों के उत्तर में कहीं है।

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

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

यदि आप MLC SSD का उपयोग कर रहे हैं, तो आप शायद चिंतित होने के लिए सही हैं। लेकिन ध्यान रखें कि अगर इंटेल ड्राइव को पांच साल के लिए 100 जीबी / दिन पर रेट करने के लिए खुश है, तो यह अभी भी मौलिक रूप से 10 साल के लिए 50 जीबी / दिन के समान है। और, मेरे मूल बिंदु पर वापस, आपको अभी भी यह जानना होगा कि आप ड्राइव पर किस तरह का वास्तविक कार्यभार ले रहे हैं।

व्यक्तिगत रूप से, मैं दृढ़ता से कहूंगा कि उत्पादन सर्वर वातावरण में MLC SSD का उपयोग न करें। यदि एक सभ्य एसएलसी एसएसडी बहुत महंगा है, तो अब के लिए कताई डिस्क से चिपके रहें।

(एक तरफ, यदि आप संख्याओं पर करते हैं, तो 50 वर्षों के लिए प्रति दिन 100 जीबी कहें, जो "एसएलसी एमएलसी की तुलना में 10x लंबे समय तक रहता है" रेटिंग है, ऐसा लगता है कि इंटेल कह रहा है कि उनकी 32 जीबी ड्राइव वास्तव में कुल लेखन जीवनकाल है डेटा के 2 पीबी के करीब, उत्पाद विनिर्देश पर 1 पीबी का हवाला नहीं दिया जाता है। भले ही मैं केवल उन दो मूल्यों के छोटे होने पर भरोसा करता हूं जो खुश हैं कि मेरी एक्स 25-ई ड्राइव 10 साल के उत्तर में अच्छी तरह से चलना चाहिए।)


मुझे लगता है कि मैं एमएलसी एसएसडी का उपयोग करने पर अपने बयान को संशोधित करूंगा: वे उद्यम उपयोग के लिए काफी अच्छे लगते हैं। मैंने सुना है कि SLC SSD के साथ एक प्रमुख विक्रेता MLC फ्लैश और स्मार्ट कंट्रोलर के साथ अपनी SLC रेंज की जगह ले रहे हैं।
डैनियल लॉसन

15

लंबी उम्र के अलावा शायद कोई मुद्दा नहीं है, जैसा कि डैनियल लॉसन ने उल्लेख किया है, और एमएस टीम से ही प्रतिक्रिया (नीचे), विचार करें

  1. पेजफाइल का उपयोग केवल तभी किया जाएगा जब आवश्यक हो
  2. यदि पेजफाइल का उपयोग किया जा रहा है, तो SSD बनाम कताई हार्ड ड्राइव पर होने से भारी अंतर पड़ेगा

क्या पेजफाइल को एसएसडी पर रखा जाना चाहिए?

हाँ। अधिकांश पेजफाइल संचालन छोटे यादृच्छिक रीड या बड़े अनुक्रमिक लिखते हैं, दोनों ही ऐसे प्रकार के ऑपरेशन हैं जिन्हें एसएसडी अच्छी तरह से संभालते हैं।

हजारों निशानों से टेलीमेट्री डेटा को देखने और पेजफाइल को पढ़ने और लिखने पर ध्यान केंद्रित करने पर, हम पाते हैं कि

  • Pagefile.sys outnumber पढ़ता है pagefile.sys लगभग 40 से 1 लिखता है
  • Pagefile.sys रीड साइज आम तौर पर काफी छोटा होता है, जिसमें 67% 4 KB से कम या बराबर होता है, और 16 KB से 88% कम होता है।
  • Pagefile.sys लिखते अपेक्षाकृत बड़े हैं, 62% से अधिक या 128 केबी के बराबर और 45% आकार में बिल्कुल 1 एमबी है। वास्तव में, दिए गए विशिष्ट पेजफाइल संदर्भ पैटर्न और अनुकूल प्रदर्शन विशेषताओं की एसएसडी उन पैटर्न पर है, एसएसडी पर जगह के लिए पेजफाइल से बेहतर कुछ फाइलें हैं।

सॉलिड-स्टेट ड्राइव (MSDN) के लिए समर्थन और प्रश्नोत्तर


9

पेजफाइल को पूरी तरह से निष्क्रिय करने के बजाय, ओएस को इसका उपयोग न करने के लिए कहना उपयोगी हो सकता है (उदाहरण के लिए sysctl vm.swappiness=0)।

जब तक आवश्यक न हो, SSD अनावश्यक लेखन को बचाने के लिए OS इसका उपयोग करने से बचेगा।


4
एक दम बढ़िया। वहाँ खिड़कियों के लिए इस तरह के एक मोड़ है?
पाइरोलॉनिक

मुझे यकीन नहीं है, लेकिन आप उस फ़ाइल के आकार को न्यूनतम (2MB) पर सेट करके और इसे बढ़ने देने की अनुमति देने में सक्षम हो सकते हैं।
मिकीबी

5

मैं पेज फ़ाइल को हमेशा सक्षम छोड़ दूँगा; आपके OS या ऐप्स के कुछ हिस्से एक होने की उम्मीद करने के लिए लिखे जा सकते हैं, और अगर ऐसा नहीं है तो गलत व्यवहार कर सकते हैं।

यह कहते हुए कि, मैंने पिछले दिनों एक पृष्ठ फ़ाइल के बिना विंडोज (एक्सपी) चलाया है, और यह मेरे द्वारा फेंकी गई हर चीज से पूरी तरह खुश है। वहाँ हमेशा संदेह है कि हालांकि कुछ के साथ आ जाएगा कि यह पसंद नहीं था।

एक विकल्प यह वास्तव में छोटा सेट करने के लिए हो सकता है।


मुझे नहीं लगता कि ऐप पता लगा सकते हैं कि वे राम या स्वैप का उपयोग कर रहे हैं या नहीं। तो वह बात कैसे हो सकती है?
पाइरोलॉनिक

ओएस को आभासी मेमोरी सक्षम करने के लिए तैयार किया गया था, वास्तव में। आपके पास SSD's के साथ एक बिंदु है, या मुझे लगता है कि आप सही हैं - मैंने बहुत सारी कहावतें पढ़ी हैं कि उनके साथ दोहराव की समस्या है, और वर्चुअल मेमोरी निश्चित रूप से ऐसा करती है। क्या आप उचित डिस्क पर पेजफाइल / स्वैप नहीं कर सकते हैं? (निश्चित रूप से प्रति-सहज लगता है ...)
काइल हॉजसन

कोई OS पृष्ठ फ़ाइल क्यों मान सकता है? लिनक्स निश्चित रूप से नहीं करता है, और मुझे विश्वास करने का कोई कारण कभी नहीं देखा है कि विंडोज या तो करता है
माइकेज

2
यहाँ विंडोज पर विश्वास करने का एक कारण है: blogs.msdn.com/ericlippert/archive/2009/06/08/…
dmo

3

यह ओपी के लिए सीधे उत्तरदायी नहीं है, लेकिन मैं रोनाल्ड और डैनियल द्वारा दिए गए उत्तर / टिप्पणियों में गलत धारणा को सुधारना चाहता था। (मैं नया हूं, इसलिए टिप्पणी करने के लिए पर्याप्त बिंदु नहीं हैं।)

टीआरआईएम वास्तव में सबसे बड़ी चीज है जो आप एक एसएसडी के जीवन का विस्तार करने के लिए कर सकते हैं। यहाँ क्यों है: SSDs समय-समय पर "कचरा इकट्ठा" - आंशिक रूप से खाली मिटाए गए ब्लॉक से (खंडित) डेटा की प्रतिलिपि बनाएँ, और इसे नए सिरे से मिटाए गए ब्लॉक में लिखें।

पते को हटा दिया जाता है ताकि मेजबान को इसकी जानकारी न हो। यह अतिरिक्त लेखन गतिविधि, सीधे मेजबान लेखन से जुड़ी नहीं है, इसे "राइट एम्प्लीफिकेशन" कहा जाता है। एक पूरी तरह से पूर्ण एसएसडी के सबसे खराब मामले में थोड़ी मात्रा में ओवरप्रोवीड (छिपी हुई अतिरिक्त) जगह के साथ, लिखने का प्रवर्धन आसानी से 500% की सीमा में हो सकता है - 700% मेजबान लेखन दर!

कचरा संग्रहण के दौरान, SSD उन पन्नों को कॉपी और फिर से लिखने की जहमत नहीं उठाता, जो अमान्य (ओवरराइट या TRIMmed) किए गए हैं, जो संभावित रूप से बहुत अच्छा काम बचाते हैं और गतिविधि लिखते हैं। यदि फ़ाइल सिस्टम एक बड़ी फ़ाइल मिटा देता है, लेकिन यह TRIM के माध्यम से ड्राइव को सूचित नहीं करता है, तो ड्राइव उस प्रतिलिपि को जारी रखेगा जो डेटा को चारों ओर मिटा देता है, लिखता है, अनिश्चित काल तक (या जब तक कि ब्लॉक पते किसी अन्य फ़ाइल को सौंपा जाना नहीं होता है, जो एक लंबा समय हो सकता है)।

सारांश में, TRIM वास्तव में दीर्घायु और प्रदर्शन दोनों के लिए महत्वपूर्ण है।


2

मैंने इसे आपके द्वारा लिंक किए गए अन्य पोस्ट पर कहा है, लेकिन हम बिना पेजफाइल के एक बहुत ही मुख्य-पंक्ति सर्वर चलाते हैं और यहां सब कुछ ठीक लगता है। वास्तव में यह इसके बिना तेज लगता है। हमारे पास 8GB RAM है और मैं कहूंगा कि आपको अपना निर्णय इस आधार पर करना चाहिए कि क्या आपके पास बहुत अधिक RAM है, न कि आपकी हार्ड ड्राइव SSD है या नहीं। हालांकि मैं अनावश्यक लेखन न करके इसके जीवन को बचाने की इच्छा को समझ सकता हूं।


2

बस वर्चुअल मेमोरी के लिए दूसरी हार्ड ड्राइव का उपयोग करें।


1
मुझे लगता है कि एसएसडी का उपयोग करके स्वैप प्रदर्शन में सुधार करने के लिए बिंदु था, अगर एसएसडी के लिए पेजफाइल लिखना ड्राइव को लिखने के माध्यम से नहीं जलाएगा। एक सामान्य हार्ड ड्राइव का उपयोग प्रदर्शन लाभ प्रदान नहीं करेगा जो कि SSD होगा।
jrista

अधिकांश लैपटॉप पर संभव नहीं है।
ब्रायन नोब्लुक

0

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

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


-1

मैं कहूंगा कि यदि आप इसके साथ भाग सकते हैं, तो स्वैप का उपयोग न करें। या शायद swappiness रास्ता नीचे बारी। हालांकि, जब आपको इसकी आवश्यकता न हो, तो एक बार पहनना मुश्किल होता है (100,000 बार पूरे ड्राइव पर लिखने में कितना समय लगेगा?)।

फिर से, हाइबरनेट (डिस्क के लिए निलंबित) कुछ प्रकार के स्वैप के बिना काम नहीं करता है।

कोई अदला-बदली वाला कोई व्यवहार नहीं करता था (जैसा कि 50 एमबी रैम डिस्क में स्वैप के लिए एक जीत होगी), लेकिन वह पिछली गर्मियों में पैच किया गया था (या यह 2007 था?), इसलिए एक चालू ओएस ठीक होना चाहिए।

अब हमें केवल हार्डवेयर की जरूरत है जो इरेज़ कमांड का समर्थन करता है (लिनक्स ने महीनों तक इसका समर्थन किया है), और एसएसडी पर जीवन बस बांका होगा।


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

बहुत सच है, यह सिर्फ उन्हें बेहतर प्रदर्शन करने के लिए कर देगा।
रोनाल्ड पोटोल

डैनियल (और रोनाल्ड): यदि एसएसडी को पता है कि "डिस्क" का एक खंड मुक्त या शून्य कर दिया गया है, तो टीआरआईएम के लिए धन्यवाद, यह संभवत: इसे कॉपी नहीं करेगा जब लेखन लिखने या छोटे लेखन का प्रबंधन करते हैं। जिसका अर्थ है कम लिखना और अधिक जीवनकाल, नहीं? कुछ स्रोत जो मुझसे सहमत हैं, जो ठोस प्रतीत होते हैं: atpinc.com/Memory-insider/… superuser.com/questions/1063744/… wiki.archlinux.org/index.php/Solid_state_date#TRIM - एज केसेस के लिए बढ़िया संसाधन आदि
मैथ्यू एल्वे

-2

मैं दो एंटरप्राइज़-श्रेणी SSDs मुझ पर बाहर जला लिया है बहुत (यह है कि अच्छी तरह से वारंटी अवधि के अंदर), समय से पहले ही। मुझे लगता है कि थ्रैशिंग की वजह से भारी बदबू आ रही थी। मुझे अक्सर एहसास हुआ कि मैंने मेमोरी लीक के साथ / छोटी गाड़ी डेमों को चलाने की अनावश्यक प्रक्रियाएं की थीं, जैसे कि लगभग निरंतर रूप से भारी स्वैप गतिविधि थी। मैं iostat -n9 -w 10समय-समय पर पृष्ठभूमि में दौड़ता हूं और ध्यान देता हूं कि अक्सर लगातार भारी डिस्क गतिविधि होती है। इसके अलावा कर्नेल प्रक्रिया '(स्वैप) गतिविधि को अधिकांश I / O के स्रोत के रूप में लॉग किया गया था। मुझे एक डेमॉन याद आता है जिसमें महीनों तक मेमोरी लीक होती थी और समय-समय पर हत्या की जरूरत होती थी। मैं अक्सर समस्या का निवारण तब तक नहीं करता, जब तक कि सिस्टम नाराज़ न हो जाए, इसलिए अक्सर जोर लगाने से पहले मैं डेमॉन को फिर से शुरू करने का समय ले लेता था। और अब रिसाव को ठीक करने के लिए।

स्वैपिंग को अक्षम करने से मेरा ध्यान आकर्षित होता है, इसलिए एसएसडी पर प्रमुख पहनने से पहले समस्या का समाधान किया जाएगा, यह इस तरह के नुकसान को रोकने के लिए सबसे अच्छा तरीका है; किसी भी सभ्य निगरानी / सतर्कता उपकरण बेहतर होगा।

एक चेतावनी जो कई जवाबों को स्वीकार करने में विफल रहती है, वह यह है कि अगर कोई सर्वर लगातार एसएसडी को थ्रेश कर रहा है, तो वह इस स्थिति में एक साल के भीतर बहुत जल्दी-जल्दी बर्नआउट कर देगा। क्लासिक थ्रैशिंग आम तौर पर तब होता है जब वर्चुअल मेमोरी स्वैपिंग (स्वैप) ड्राइव को ज्यादातर व्यस्त रखने के लिए पर्याप्त होती है - अच्छी तरह से इसकी अधिकतम I / O बैंडविड्थ के परिमाण के भीतर, और स्वैप-संबंधी I / के लिए कम से कम एक प्रक्रिया की प्रतीक्षा होती है O अधिकांश समय उस सिस्टम को पूरा करने के लिए है जो उस अवस्था में है। अन्य उत्तर मानते हैं कि सिस्टम नहीं हैकम से कम, क्लासिक तरीके से नहीं; या इस बात की गलतफहमी पर भरोसा करें कि क्या जोर है। और यह गलत धारणा, अन्य सटीक आंकड़ों के बावजूद, गलत जवाब देने के लिए नेतृत्व क्यों पेजिंग के रूप में, यहां तक ​​कि जब एक एसएसडी केवल स्वैप के लिए संभव स्थान है, सबसे अच्छा सक्षम है।


-3

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


2
मैं आपसे अधिक असहमत नहीं हो सकता। इस पोस्टर के लिंक से संबंधित प्रश्न पर स्वीकृत उत्तर पर एक नज़र क्यों नहीं डालें।
चॉपर

2
विंडोज मेमोरी में पेजफाइल बनाएगा? सो कैसे?
मार्क सोउल
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.