हार्ड ड्राइव के प्रदर्शन की जांच कैसे करें (या तो टर्मिनल या जीयूआई के माध्यम से) । लिखने की गति। पढ़ने की गति। कैश आकार और गति । यादृच्छिक गति।
टर्मिनल विधि
hdparm शुरू करने के लिए एक अच्छी जगह है ।
sudo hdparm -Tt /dev/sda/dev/sda:Timing cached reads: 12540 MB in 2.00 seconds = 6277.67 MB/secTiming buffered disk reads: 234 MB in 3.00 seconds = 77.98 MB/secsudo hdparm -v /dev/sda जानकारी भी देंगे ।
dd आपको लिखने की गति के बारे में जानकारी देगा ।
यदि ड्राइव में फ़ाइल सिस्टम नहीं है (और तभी), उपयोग करें of=/dev/sda.
अन्यथा, इसे /टीएमपी पर माउंट करें और लिखें फिर परीक्षण आउटपुट फ़ाइल को हटा दें ।
dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output10240+0 records in10240+0 records out83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/sचित्रमय विधि
- >>सिस्टम-प्रशासन-डिस्क उपयोगिता पर जाएं ।
- वैकल्पिक रूप से, कमांड लाइन से गनोम डिस्क उपयोगिता को चलाकर लॉन्च करें
gnome-disks
- वैकल्पिक रूप से, कमांड लाइन से गनोम डिस्क उपयोगिता को चलाकर लॉन्च करें
- बाएँ फलक पर अपनी हार्ड डिस्क का चयन करें ।
- अब दाएँ फलक में "बेंचमार्क – माप ड्राइव प्रदर्शन" बटन पर क्लिक करें ।
- चार्ट के साथ एक नई विंडो खुलती है । आप पाएंगे और दो बटन । एक " स्टार्ट रीड ओनली बेंचमार्क "के लिए है और दूसरा"स्टार्ट रीड/राइट बेंचमार्क" है । जब आप किसी भी बटन पर क्लिक करते हैं तो यह हार्ड डिस्क की बेंचमार्किंग शुरू करता है ।
बेंचमार्क डिस्क आई/ओ कैसे करें
क्या आप कुछ और चाहते हैं?
सुओमिन सही है, हमें किसी प्रकार के सिंक का उपयोग करना चाहिए; लेकिन एक सरल तरीका है, कॉन्व=एफडीएटासिंक काम करेगा:
dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output1024+0records in1024+0 records out402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/sयदि आप सटीकता चाहते हैं, तो आपको उपयोग करना चाहिए fio. इसे मैनुअल पढ़ने की आवश्यकता है (man fio) लेकिन यह आपको सटीक परिणाम देगा । ध्यान दें कि किसी भी सटीकता के लिए, आपको ठीक वही निर्दिष्ट करना होगा जो आप मापना चाहते हैं । कुछ उदाहरण:
बड़े ब्लॉकों के साथ अनुक्रमिक पढ़ने की गति (यह आपके ड्राइव के विनिर्देशों में दिखाई देने वाली संख्या के पास होना चाहिए):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=read --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reportingबड़े ब्लॉकों के साथ अनुक्रमिक लिखने की गति (यह आपके ड्राइव के विनिर्देशों में दिखाई देने वाली संख्या के पास होना चाहिए):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=write --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting4K यादृच्छिक पढ़ने QD1 (यह वह संख्या है जो वास्तव में वास्तविक विश्व प्रदर्शन के लिए मायने रखती है जब तक कि आप निश्चित रूप से बेहतर नहीं जानते):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reportingमिश्रित यादृच्छिक 4 के सिंक के साथ क्यूडी 1 पढ़ें और लिखें (यह सबसे खराब स्थिति संख्या है जिसे आपको कभी भी अपने ड्राइव से उम्मीद करनी चाहिए, आमतौर पर स्पेक शीट में सूचीबद्ध संख्याओं का 1% से कम):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reportingबढ़ाएँ --size फ़ाइल का आकार बढ़ाने के लिए तर्क । बड़ी फ़ाइलों का उपयोग करने से ड्राइव तकनीक और फर्मवेयर के आधार पर आपको मिलने वाली संख्या कम हो सकती है । छोटी फाइलें घूर्णी मीडिया के लिए बहुत अच्छे परिणाम देंगी क्योंकि रीड हेड को इतना स्थानांतरित करने की आवश्यकता नहीं है । यदि आपका डिवाइस खाली है, तो ड्राइव को लगभग भरने के लिए पर्याप्त फ़ाइल का उपयोग करने से आपको प्रत्येक परीक्षण के लिए सबसे खराब स्थिति का व्यवहार मिलेगा । एसएसडी के मामले में, फ़ाइल का आकार इतना मायने नहीं रखता ।
हालांकि, ध्यान दें कि कुछ भंडारण मीडिया के आकार के लिए फ़ाइल उतना महत्वपूर्ण नहीं है जितना कम समय अवधि के दौरान लिखे गए कुल बाइट्स. उदाहरण के लिए, कुछ एसएसडी में पूर्व-मिटाए गए ब्लॉकों के साथ काफी तेज प्रदर्शन होता है या इसमें छोटा एसएलसी फ्लैश क्षेत्र हो सकता है जिसका उपयोग राइट कैश के रूप में किया जाता है और एसएलसी कैश पूर्ण होने के बाद प्रदर्शन में परिवर्तन होता है (उदाहरण के लिए सैमसंग ईवीओ श्रृंखला जिसमें 20-50 जीबी एसएलसी कैश है) । एक अन्य उदाहरण के रूप में, सीगेट एसएमआर एचडीडी में लगभग 20 जीबी पीएमआर कैश क्षेत्र होता है जिसमें बहुत अधिक प्रदर्शन होता है लेकिन एक बार जब यह पूरा हो जाता है, तो सीधे एसएमआर क्षेत्र में लिखने से प्रदर्शन मूल से 10% तक कट सकता है । और इस प्रदर्शन में गिरावट को देखने का एकमात्र तरीका यह है कि पहले 20+ जीबी को जितनी जल्दी हो सके लिखें और तुरंत बाद वास्तविक परीक्षण जारी रखें । बेशक, यह सब आपके कार्यभार पर निर्भर करता है: यदि आपकी लेखन पहुंच लंबे समय तक देरी से भरी हुई है जो डिवाइस को आंतरिक कैश को साफ करने की अनुमति देती है, तो छोटे परीक्षण अनुक्रम आपके वास्तविक विश्व प्रदर्शन को बेहतर ढंग से प्रतिबिंबित करेंगे । यदि आपको बहुत सारे आईओ करने की ज़रूरत है, तो आपको दोनों को बढ़ाना होगा --io_size और --runtime पैरामीटर। ध्यान दें कि कुछ मीडिया (जैसे अधिकांश सस्ता फ्लैश डिवाइस) इस तरह के परीक्षण से पीड़ित होंगे क्योंकि फ्लैश चिप्स बहुत जल्दी खराब हो जाते हैं । मेरी राय में, यदि कोई उपकरण इस तरह के परीक्षण को संभालने के लिए पर्याप्त खराब है, तो इसका उपयोग किसी भी मामले में किसी भी मूल्यवान डेटा को रखने के लिए नहीं किया जाना चाहिए । उस ने कहा, 1000 के दशक के लिए बड़े लेखन परीक्षणों को न दोहराएं क्योंकि सभी फ्लैश कोशिकाओं में लेखन के साथ कुछ स्तर के पहनने होंगे ।
इसके अलावा, कुछ उच्च गुणवत्ता वाले एसएसडी उपकरणों में और भी अधिक बुद्धिमान पहनने वाले लेवलिंग एल्गोरिदम हो सकते हैं जहां आंतरिक एसएलसी कैश में डेटा को बदलने के लिए पर्याप्त स्मार्ट होते हैं यदि डेटा अभी भी एसएलसी कैश में है, तो इसे फिर से लिखा जा रहा है । ऐसे उपकरणों के लिए, यदि परीक्षण फ़ाइल डिवाइस के कुल एसएलसी कैश से छोटी है, तो पूर्ण परीक्षण हमेशा एसएलसी कैश को ही लिखता है और आपको डिवाइस की तुलना में उच्च प्रदर्शन संख्या मिलती है जो बड़े लेखन के लिए समर्थन कर सकती है । तो ऐसे उपकरणों के लिए, फ़ाइल का आकार फिर से मायने रखने लगता है । यदि आप अपने वास्तविक कार्यभार को जानते हैं तो फ़ाइल आकारों के साथ परीक्षण करना सबसे अच्छा है जो आप वास्तव में वास्तविक जीवन में देखेंगे । यदि आप अपेक्षित कार्यभार नहीं जानते हैं, तो परीक्षण फ़ाइल आकार का उपयोग करके जो लगभग 50% स्टोरेज डिवाइस को भरता है, उसके परिणामस्वरूप सभी स्टोरेज कार्यान्वयन के लिए एक अच्छा औसत परिणाम होना चाहिए । बेशक, 50 टीबी छापे सेटअप के लिए, 25 टीबी परीक्षण फ़ाइल के साथ एक लेखन परीक्षण करने में काफी समय लगेगा!
ध्यान दें कि fio पहले रन पर आवश्यक अस्थायी फ़ाइल बनाएगा । यह उन उपकरणों से बहुत अच्छी संख्या प्राप्त करने से बचने के लिए छद्म आयामी डेटा से भरा होगा जो स्थायी भंडारण में लिखने से पहले डेटा को संपीड़ित करके बेंचमार्क में धोखा देने की कोशिश करते हैं । अस्थायी फ़ाइल को बुलाया जाएगा fio-tempfile.dat उपरोक्त उदाहरणों में और वर्तमान कार्यशील निर्देशिका में संग्रहीत । तो आपको पहले उस निर्देशिका में बदलना चाहिए जो उस डिवाइस पर माउंट की गई है जिसे आप परीक्षण करना चाहते हैं । द fio परीक्षण लक्ष्य के रूप में प्रत्यक्ष मीडिया का उपयोग करने का भी समर्थन करता है, लेकिन मैं निश्चित रूप से कोशिश करने से पहले मैनुअल पेज को पढ़ने का सुझाव देता हूं क्योंकि एक टाइपो आपके पूरे ऑपरेटिंग सिस्टम को अधिलेखित कर सकता है जब कोई प्रत्यक्ष भंडारण मीडिया एक्सेस का उपयोग करता है (उदाहरण के लिए गलती से परीक्षण डिवाइस के बजाय ओएस
यदि आपके पास एक अच्छा एसएसडी है और आप और भी अधिक संख्या देखना चाहते हैं, तो बढ़ाएँ --numjobs ऊपर। यह पढ़ने और लिखने के लिए संगामिति को परिभाषित करता है । उपरोक्त सभी उदाहरणों में है numjobs पर सेट करें 1 तो परीक्षण एकल थ्रेडेड प्रक्रिया पढ़ने और लिखने के बारे में है (संभवतः कतार की गहराई या क्यूडी के साथ सेट के साथ iodepth). उच्च अंत एसएसडी (जैसे इंटेल ऑप्टेन 905 पी) को बिना बढ़ाए भी उच्च संख्या मिलनी चाहिए numjobs बहुत कुछ (जैसे 4 उच्चतम कल्पना संख्या प्राप्त करने के लिए पर्याप्त होना चाहिए) लेकिन कुछ उद्यम और उद्धरण;एसएसडी को रेंज में जाने की आवश्यकता होती है 32-128 कल्पना संख्या प्राप्त करने के लिए क्योंकि उन उपकरणों की आंतरिक विलंबता अधिक है लेकिन समग्र थ्रूपुट पागल है । ध्यान दें कि बढ़ रहा है numbjobs उच्च मूल्यों के लिए आमतौर पर परिणामस्वरूप बढ़ जाता है बेंचमार्क प्रदर्शन संख्या लेकिन शायद ही कभी किसी भी तरह से वास्तविक दुनिया के प्रदर्शन को दर्शाता है ।
मैं उपयोग करने की सलाह नहीं दूंगा /dev/urandom क्योंकि यह सॉफ्टवेयर आधारित है और सुअर की तरह धीमा है । रैमडिस्क पर यादृच्छिक डेटा का हिस्सा लेना बेहतर है । हार्ड डिस्क परीक्षण पर यादृच्छिक कोई फर्क नहीं पड़ता, क्योंकि प्रत्येक बाइट के रूप में लिखा जाता है (डीडी के साथ एसएसडी पर भी) । लेकिन अगर हम शुद्ध शून्य या यादृच्छिक डेटा के साथ जेडएफएस पूल का परीक्षण करते हैं, तो बहुत बड़ा प्रदर्शन अंतर है ।
एक अन्य दृष्टिकोण सिंक समय समावेश होना चाहिए; सभी आधुनिक फाइल सिस्टम फ़ाइल संचालन पर कैशिंग का उपयोग करते हैं ।
वास्तव में डिस्क की गति को मापने के लिए और मेमोरी को नहीं, हमें कैशिंग प्रभाव से छुटकारा पाने के लिए फाइल सिस्टम को सिंक करना होगा । यह आसानी से किया जा सकता है:
time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"उस विधि से आपको आउटपुट मिलता है:
sync ; time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync" ; rm testfile 1024+0 records in1024+0 records out104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/sreal 0m0.441suser 0m0.004ssys 0m0.124s>तो डिस्क डेटारेट सिर्फ 104857600 / 0.441 = 237772335 बी/एस-237 एमबी/एस है
यह कैशिंग की तुलना में 100 एमबी/एस से कम है ।
हैप्पी बेंचमार्किंग,
यदि आप वास्तविक समय में डिस्क पढ़ने और लिखने की गति की निगरानी करना चाहते हैं तो आप इसका उपयोग कर सकते हैं iotop उपकरण।
यह जानकारी प्राप्त करने के लिए उपयोगी है कि डिस्क किसी विशेष एप्लिकेशन या कार्यभार के लिए कैसा प्रदर्शन करती है । आउटपुट आपको प्रति प्रक्रिया पढ़ने/लिखने की गति दिखाएगा, और सर्वर के लिए कुल पढ़ने/लिखने की गति, इसी तरह top.
स्थापित करें iotop:
sudo apt-get install iotop इसे चलाएं:
sudo iotopयह उपकरण यह समझने में सहायक है कि डिस्क एक विशिष्ट कार्यभार बनाम अधिक सामान्य और सैद्धांतिक परीक्षणों के लिए कैसा प्रदर्शन करती है ।
गति लिखें
$ dd if=/dev/zero of=./largefile bs=1M count=10241024+0 records in1024+0 records out1073741824 bytes (1.1 GB) copied, 4.82364 s, 223 MB/sब्लॉक का आकार वास्तव में काफी बड़ा है । आप 64 के या 4 के जैसे छोटे आकार के साथ भी कोशिश कर सकते हैं ।
गति पढ़ें
मेमोरी कैश को साफ़ करने के लिए निम्न कमांड चलाएँ
$ sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"अब उस फाइल को पढ़ें जो राइट टेस्ट में बनाई गई थी:
$ dd if=./largefile of=/dev/null bs=4k165118+0 records in165118+0 records out676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/sबोनी++ अंतिम बेंचमार्क उपयोगिता है जिसे मैं लिनक्स के लिए जानता हूं ।
(मैं वर्तमान में बोनी++ के साथ काम पर एक लिनक्स लाइवसीडी तैयार कर रहा हूं ताकि इसके साथ हमारी विंडोज-आधारित मशीन का परीक्षण किया जा सके!)
यह कैशिंग, सिंकिंग, रैंडम डेटा, डिस्क पर रैंडम लोकेशन, छोटे आकार के अपडेट, बड़े अपडेट, रीड, राइट आदि का ध्यान रखता है । यूएसबीकेई, हार्डडिस्क (रोटरी), सॉलिड-स्टेट ड्राइव और रैम-आधारित फाइल सिस्टम की तुलना नौसिखिया के लिए बहुत जानकारीपूर्ण हो सकती है ।
मुझे नहीं पता कि यह उबंटू में शामिल है, लेकिन आप इसे स्रोत से आसानी से संकलित कर सकते हैं ।
बोनी++का उपयोग करने के तरीके पर कुछ संकेत
bonnie++ -d [TEST_LOCATION] -s [TEST_SIZE] -n 0 -m [TEST_NAME] -f -b -u [TEST_USER] bonnie++ -d /tmp -s 4G -n 0 -m TEST -f -b -u jamesथोड़ा और अधिक पर: सरल बोनी++ उदाहरण.
Similar question has been asked over on linux - How can I benchmark my HDD? - Unix & Linux Stack Exchange , file io - Testing IO performance in Linux - Stack Overflow and io - I/O Performance Benchmarking Linux - Server Fault .