लिनक्स tmpfs रैम स्पीड की तुलना में स्पीड स्लो लिखते हैं


1

मेरे पास HPE प्रोलिएंट DL360 Gen9 सर्वर है, चश्मा हैं:

  • CPU: Intel Xeon 2 CPUs E5-2687W v3 @ 3.10GHz, 25MB L3 कैश, 10 कोर
  • RAM: 8x 32GB PC4-17000 DDR4 2133 मेगाहर्ट्ज CAS-15 1.2V SDRAM DIMM (256 GB x)

(पूर्ण सर्वर चश्मा यहाँ )

सर्वर CentOS 7.2कर्नेल के साथ चल रहा है 3.10.0-327.36.3.el7.x86_64

मैंने निम्नलिखित प्रविष्टि का उपयोग करके सर्वर पर एक tmpfs रैमडिस्क लगाया /etc/fstab:

tmpfs  /ramdisk  tmpfs  noauto,user  0 0

इस रामदिस्क को लिखने का परीक्षण करने के लिए, मैं निम्नलिखित कमांड चलाता हूं:

time sh -c "dd if=/dev/zero of=/ramdisk/120GB_testfile bs=4k count=30000000 && sync"

यह रिपोर्ट करता है कि इसने 58.857s में 122,880,000,000 बाइट्स लिखे, जो 1991 MiB / सेकंड की राइट स्पीड है।

यह देखते हुए कि इस मेमोरी की लिखने की गति 17GB / sec ( मेमोरी डेटा दरों के इस विवरण के अनुसार ) है, मैं अपने tmpfs ramdisk को लिखते समय काफी कम दर से हैरान हूं। क्या कोई असमानता की व्याख्या कर सकता है, और स्मृति में एक फ़ाइल में लिखने का एक और तरीका सुझा सकता है जो तेज है?

धन्यवाद।

अद्यतन करें

मैं अक्षम हो गया vm.swappiness, लेकिन इससे कोई लाभ नहीं हुआ (1712 MiB / सेकंड)।

मैंने ब्लॉक आकार को बढ़ाने की कोशिश की ( bs=256k count=468750), लेकिन फिर से, बहुत अधिक प्रभाव (2087 मिब / सेकंड) नहीं।


1
यदि आप ब्लॉक का आकार बढ़ाते हैं (गिनती को कम करते समय) तो क्या होगा? Tmpfs को स्वैप मेमोरी द्वारा समर्थित किया जाता है, आप कितने निश्चित हैं कि आपके डेटा को पृष्ठांकित नहीं किया जा रहा है और इस प्रकार धीमा हो रहा है? क्या आपने vm.swappiness0 या 1 पर सेट किया है?
Mokubai

@ मोकूबाई, स्वैगनेस डिफ़ॉल्ट (60) पर सेट की गई थी। मुझे लगा कि मैं एक फ़ाइल को छोटा बनाकर स्वैप करने से बच रहा हूं ताकि वह पूरी तरह से रैम में फिट हो जाए। मैं स्वैग को अक्षम करने का प्रयास करूंगा और अपनी पोस्ट w / उन परिणामों को अपडेट करूंगा। धन्यवाद।
एट्रेयू

बार-बार tmpfs को लिखना (आपके परीक्षण की तरह) मेरे लिए अलग-अलग गति का परिणाम है, आमतौर पर बढ़ रहा है, लेकिन मैं छोटे आकार का उपयोग कर रहा हूं, यदि यह कारण नहीं है, तो मुझे अनुमान है कि यह tmpfs के लिए मुक्त होने वाली मेमोरी से हो सकता है। एक ही परीक्षण को लगातार कई बार चलाने पर कोई बदलाव? या ramfs का उपयोग कर रहे हैं? (FYI करें, रामफ्स को वास्तव में राम में रहना चाहिए और अधिक सटीक " रामडिस्क" होना चाहिए , लेकिन आकार सीमा iirc नहीं है इसलिए बाहर देखें)
Xen2050

जवाबों:


3

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

इसके अलावा, मेमोरी आवंटित करना बेहद धीमा है। वास्तव में, यह उन सबसे धीमी चीजों में से एक है जिनके बारे में आप ज्यादातर सिस्टम पर कर सकते हैं जिसमें I / O शामिल नहीं है, केवल एक धीमी चीज से एक नया धागा या प्रक्रिया बन रही है। ramspeedप्री-एलोकेशन जैसे उपकरण वे सभी मेमोरी का उपयोग करते हैं जो वे शुरू होने पर सही उपयोग करते हैं, इसलिए वे वास्तविक मेमोरी प्रदर्शन का परीक्षण कर सकते हैं। इसकी तुलना में, tmpfs को यह पता नहीं है कि आप जिस फ़ाइल को बनाने जा रहे हैं, वह कितनी बड़ी है, इसलिए उसे ऑन-डिमांड सब कुछ आवंटित करना पड़ता है, और ऐसा इसलिए होता है कि ddब्लॉक आकार से बड़ा नहीं हो (मुझे लगता है कि यह 64k पर कैप करता है, लेकिन मुझे यकीन नहीं है)। इस वजह से, आपके पास उस ब्लॉक को स्टोर करने के लिए मेमोरी आवंटित करने के लिए हर ब्लॉक में ओवरहेड है।


क्या आपको लगता है कि फ़ाइल की प्रतिलिपि बनाना तेज़ हो सकता है, क्योंकि यह जानता है कि फ़ाइल कितनी बड़ी होगी, जबकि dd नहीं? या कैसे cpगति को मापने के लिए , या यहां तक ​​कि कुछ से एक निश्चित आकार की फ़ाइल बनाएँ / जैसे देव / शून्य पहले से ही एक और फ़ाइल tmpfs / ramfs में कॉपी करने के लिए (पढ़ने को जोड़कर परीक्षण धीमा)?
Xen2050

अपने मूल में, cpऔर ddअनिवार्य रूप से एक ही काम कर रहे हैं, वे स्रोत से डेटा पढ़ते हैं और फिर इसे गंतव्य पर लिखते हैं। cpआमतौर पर थोड़ा तेज होता है, लेकिन ऐसा इसलिए है क्योंकि यह स्वचालित रूप से काम करने के लिए इष्टतम ब्लॉक आकारों के पास है। cpकुछ बहुत ही विशेष परिस्थितियों में भी काफी तेजी से हो सकता है क्योंकि यह विभिन्न कॉपी-ऑफ लोड तंत्र (जैसे कि फाइल सिस्टम पर इसका समर्थन करने वाले रिफ़लिंक, या इसका समर्थन करने वाले हार्डवेयर पर SCSI XCOPY कमांड) का उपयोग कर सकता है।
ऑस्टिन हेमेलर्गरन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.