हार्ड ड्राइव के प्रदर्शन की जांच कैसे करें (या तो टर्मिनल या जीयूआई के माध्यम से)। लिखने की गति। पढ़ने की गति। कैश का आकार और गति। यादृच्छिक गति।
जवाबों:
hdparm शुरू करने के लिए एक अच्छी जगह है।
sudo hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 12540 MB in 2.00 seconds = 6277.67 MB/sec
Timing buffered disk reads: 234 MB in 3.00 seconds = 77.98 MB/sec
sudo hdparm -v /dev/sda साथ ही जानकारी देंगे।
dd आपको गति लिखने की जानकारी देगा।
यदि ड्राइव में फ़ाइल सिस्टम नहीं है (और केवल तब ), का उपयोग करें of=/dev/sda।
अन्यथा, इसे / tmp पर माउंट करें और लिखें और फिर परीक्षण आउटपुट फ़ाइल को हटा दें।
dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/s
gnome-disks
क्या कुछ और है जो आप चाहते हैं?
/dev/urandomसाथ- /dev/zeroसाथ इनपुट की भी सिफारिश करूंगा क्योंकि ddडेटा की कम्प्रेसिबिलिटी लिखने की गति पर भारी प्रभाव डाल सकती है।
/tmpफाइल सिस्टम अक्सर इन दिनों रैमडिस्क उपयोग कर रहा है। इसलिए लिखने के लिए /tmpअपनी स्मृति का परीक्षण करने के लिए प्रतीत होता है, न कि आपकी डिस्क सबसिस्टम।
Suominen सही है, हमें किसी प्रकार के सिंक का उपयोग करना चाहिए; लेकिन एक सरल तरीका है, conv = fdatasync काम करेगा:
dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output
1024+0records in
1024+0 records out
402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/s
मैं उपयोग करने की सलाह नहीं दूंगा /dev/urandomक्योंकि यह सॉफ्टवेयर आधारित है और सुअर के रूप में धीमा है। रैमडिस्क पर यादृच्छिक डेटा का हिस्सा लेने के लिए बेहतर है। हार्ड डिस्क परीक्षण पर यादृच्छिक कोई फर्क नहीं पड़ता, क्योंकि प्रत्येक बाइट को लिखा जाता है (dd के साथ ssd पर भी)। लेकिन अगर हम शुद्ध शून्य या यादृच्छिक डेटा के साथ कटे हुए ज़फ़्स पूल का परीक्षण करते हैं, तो बड़ा प्रदर्शन अंतर होता है।
देखने का एक और बिंदु सिंक टाइम इंक्लूजन होना चाहिए; सभी आधुनिक फाइलसिस्टम फ़ाइल संचालन पर कैशिंग का उपयोग करते हैं।
वास्तव में डिस्क की गति और स्मृति को मापने के लिए, हमें कैशिंग प्रभाव से छुटकारा पाने के लिए फाइल सिस्टम को सिंक करना होगा। यह आसानी से किया जा सकता है:
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 in
1024+0 records out
104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/s
real 0m0.441s
user 0m0.004s
sys 0m0.124s
इसलिए डिस्क डेटराट सिर्फ 104857600 / 0.441 = 237772335 B / s -> 237MB / s
यह 100 एमबी / से अधिक कैशिंग के साथ कम है।
हैप्पी बेंचमार्किंग,
यदि आप डिस्क को पढ़ने और लिखने की गति को वास्तविक समय में मॉनिटर करना चाहते हैं, तो आप iotop टूल का उपयोग कर सकते हैं ।
किसी विशेष एप्लिकेशन या कार्य के लिए डिस्क कैसे कार्य करती है, इसकी सटीक जानकारी प्राप्त करने के लिए यह उपयोगी है। आउटपुट आपको प्रति प्रक्रिया पढ़ने / लिखने की गति दिखाएगा, और सर्वर के लिए कुल पढ़ने / लिखने की गति के समान है top।
Iotop स्थापित करने के लिए:
sudo apt-get install iotop
इसे चलाने के लिए:
sudo iotop
यदि आप सटीकता चाहते हैं, तो आपको उपयोग करना चाहिए fio। इसके लिए मैनुअल ( man fio) पढ़ना आवश्यक है लेकिन यह आपको सटीक परिणाम देगा। ध्यान दें कि किसी भी सटीकता के लिए, आपको वही निर्दिष्ट करना होगा जो आप मापना चाहते हैं। कुछ उदाहरण:
बड़े ब्लॉक के साथ क्रमिक READ गति (यह आपके ड्राइव के विनिर्देशों में आपके द्वारा देखी गई संख्या के पास होना चाहिए):
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
बड़े ब्लॉकों के साथ अनुक्रमिक WRITE गति (यह आपके ड्राइव के लिए विनिर्देशों में देखी गई संख्या के पास होना चाहिए):
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_reporting
रैंडम 4K ने 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
मिश्रित रैंडम 4K QD1 को सिंक के साथ पढ़ें और लिखें (यह सबसे खराब स्थिति है जिसे आपको कभी भी अपनी ड्राइव से उम्मीद करनी चाहिए, आमतौर पर कल्पना पत्रक में सूचीबद्ध संख्याओं का 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फ़ाइल का आकार बढ़ाने के लिए तर्क बढ़ाएँ । बड़ी फ़ाइलों का उपयोग करने से आपको ड्राइव तकनीक और फ़र्मवेयर के आधार पर मिलने वाली संख्या कम हो सकती है। छोटी फाइलें घूर्णी मीडिया के लिए "बहुत अच्छा" परिणाम देंगी क्योंकि पढ़े गए सिर को उतना स्थानांतरित करने की आवश्यकता नहीं है। यदि आपका उपकरण खाली है, तो ड्राइव को भरने के लिए फ़ाइल को पर्याप्त रूप से उपयोग करने से आपको प्रत्येक परीक्षण के लिए सबसे खराब स्थिति मिलेगी। SSD के मामले में, फ़ाइल का आकार उतना मायने नहीं रखता है।
हालाँकि, ध्यान दें कि कुछ स्टोरेज मीडिया के लिए फ़ाइल का आकार उतना महत्वपूर्ण नहीं है जितना कि कम समयावधि के दौरान लिखे गए कुल बाइट्स। उदाहरण के लिए, कुछ SSD में पहले से मिटाए गए ब्लॉक के साथ काफी तेज प्रदर्शन हो सकता है या इसमें छोटे SLC फ़्लैश क्षेत्र हो सकते हैं जो कि लेखन कैश के रूप में उपयोग किए जाते हैं और SLC कैश पूर्ण होने पर प्रदर्शन बदल जाता है। एक अन्य उदाहरण के रूप में, सीगेट एसएमआर एचडीडी में लगभग 20 जीबी पीएमआर कैश क्षेत्र होता है जिसमें बहुत अधिक प्रदर्शन होता है, लेकिन एक बार जब यह पूर्ण हो जाता है, तो सीधे एसएमआर क्षेत्र में लेखन मूल से 10% तक कटौती कर सकता है। और इस प्रदर्शन को देखने का एकमात्र तरीका यह है कि पहले जितनी जल्दी हो सके 20+ जीबी लिखें। बेशक, यह सब आपके काम के बोझ पर निर्भर करता है: यदि आपकी लिखावट लंबी-लंबी देरी से भरी हुई है, जो डिवाइस को आंतरिक शरीर को साफ करने की अनुमति देती है, छोटे परीक्षण क्रम आपके वास्तविक विश्व प्रदर्शन को बेहतर ढंग से दर्शाएंगे। यदि आपको बहुत सारे IO करने की आवश्यकता है, तो आपको दोनों को बढ़ाने की आवश्यकता है--io_sizeऔर --runtimeपैरामीटर। ध्यान दें कि कुछ मीडिया (जैसे अधिकांश फ्लैश डिवाइस) को इस तरह के परीक्षण से अतिरिक्त पहनना होगा। मेरी राय में, यदि कोई भी उपकरण इस तरह के परीक्षण को संभालने के लिए पर्याप्त नहीं है, तो इसका उपयोग किसी भी मामले में किसी भी मूल्यवान डेटा को रखने के लिए नहीं किया जाना चाहिए।
इसके अलावा, कुछ उच्च गुणवत्ता वाले SSD उपकरणों में और भी अधिक बुद्धिमान पहनने लेवलिंग एल्गोरिदम हो सकते हैं जहां आंतरिक SLC कैश में डेटा को बदलने के लिए पर्याप्त स्मार्ट होते हैं जो परीक्षण के दौरान फिर से लिखे जा रहे हैं यदि यह उसी पते के स्थान (यानी परीक्षण फ़ाइल) को हिट करता है कुल एसएलसी कैश से छोटा है)। ऐसे उपकरणों के लिए, फ़ाइल आकार फिर से मायने रखना शुरू कर देता है। यदि आपको अपने वास्तविक कार्यभार की आवश्यकता है तो फ़ाइल आकारों के साथ परीक्षण करना सबसे अच्छा है जो आप वास्तव में वास्तविक जीवन में देखेंगे। अन्यथा आपके नंबर बहुत अच्छे लग सकते हैं।
ध्यान दें कि fioपहले रन पर आवश्यक अस्थायी फ़ाइल बनाई जाएगी। इसे स्थायी भंडारण में लिखने से पहले डेटा को संपीड़ित करके धोखा देने वाले उपकरणों से बहुत अच्छे नंबर प्राप्त करने से बचने के लिए यादृच्छिक डेटा से भरा जाएगा। अस्थायी फ़ाइल को fio-tempfile.datउपरोक्त उदाहरणों में बुलाया जाएगा और वर्तमान कार्यशील निर्देशिका में संग्रहीत किया जाएगा। इसलिए आपको सबसे पहले उस डायरेक्टरी में बदलाव करना चाहिए, जिस डिवाइस पर आप टेस्ट करना चाहते हैं।
यदि आपके पास एक अच्छा एसएसडी है और इससे भी अधिक संख्या देखना चाहते हैं, तो --numjobsऊपर की ओर बढ़ें। यह पठन और लिखने के लिए संगति को परिभाषित करता है। उपर्युक्त उदाहरण सभी ने परीक्षण के numjobsलिए निर्धारित किए हैं 1ताकि पढ़ने और लिखने के बारे में एकल पिरोया प्रक्रिया हो (संभवतः एक कतार के साथ सेट iodepth)। उच्च अंत SSDs (जैसे Intel Optane) को बहुत अधिक बढ़ाए बिना भी उच्च संख्या प्राप्त करनी चाहिए numjobs(उदाहरण के 4लिए उच्चतम युक्ति संख्या प्राप्त करने के लिए पर्याप्त होना चाहिए) लेकिन कुछ "एंटरप्राइज़" SSDs को 32- 128उन संख्याओं को प्राप्त करने की आवश्यकता होती है क्योंकि उन की आंतरिक विलंबता उपकरण अधिक है, लेकिन समग्र थ्रूपुट पागल है।
max_sectors_kb। मैंने 1 एमबी ब्लॉक आकार का उपयोग करने के लिए उपरोक्त उदाहरण आदेशों को बदल दिया है क्योंकि यह वास्तविक विश्व हार्डवेयर के साथ काम करता है। और मैंने यह भी परीक्षण किया कि fsyncपढ़ने के लिए कोई फर्क नहीं पड़ता।
iodepthकरने के लिए 1रैंडम एक्सेस बिल्कुल क्योंकि असली दुनिया प्रोग्राम अक्सर एल्गोरिदम चलाने / तर्क यह है कि गहराई किसी भी अधिक 1. नतीजतन साथ काम नहीं करता, अगर इस तरह के गहराई है के लिए "बहुत कम" अपने आई / ओ डिवाइस खराब है। यह सच है कि कुछ एसएसडी डिवाइस 32 से अधिक गहराई से लाभान्वित होंगे। हालांकि, क्या आप किसी भी वास्तविक विश्व कार्यभार की ओर इशारा कर सकते हैं, जिसे पढ़ने की आवश्यकता है और 32 से अधिक iodepth रखने में सक्षम है? टी एल; DR: यदि आप उच्च विलंबता डिवाइस के साथ कुछ insanely उच्च पढ़ा बेंचमार्क नंबर को पुन: उत्पन्न करना चाहते हैं, तो उपयोग करें iodepth=256 --numjobs=4लेकिन कभी भी ऐसे संख्याओं को वास्तविक रूप से देखने की अपेक्षा न करें ।
bonnie ++ अल्टिमेट बेंचमार्क यूटिलिटी है जिसे मैं लिनक्स के लिए जानता हूं।
(मैं इस समय हमारे साथ विंडोज-आधारित मशीन का परीक्षण करने के लिए इस पर bonnie ++ के साथ काम पर एक लिनक्स लाइव एलसीडी तैयार कर रहा हूं!)
यह कैशिंग, सिंकिंग, रैंडम डेटा, डिस्क पर रैंडम लोकेशन, छोटे आकार के अपडेट्स, बड़े अपडेट्स, रीड्स, राइट्स आदि की देखभाल करता है, एक usbkey, a harddisk (रोटरी), सॉलिड-स्टेट ड्राइव और ram-based की तुलना करता है। नौसिखिया के लिए फाइलसिस्टम बहुत जानकारीपूर्ण हो सकता है।
मुझे पता नहीं है कि क्या यह उबंटू में शामिल है, लेकिन आप इसे आसानी से स्रोत से संकलित कर सकते हैं।
गति लिखें
$ dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.82364 s, 223 MB/s
ब्लॉक का आकार वास्तव में काफी बड़ा है। आप 64k या 4k जैसे छोटे आकार के साथ कोशिश कर सकते हैं।
गति पढ़ें
मेमोरी कैश को खाली करने के लिए निम्न कमांड चलाएँ
$ sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
अब लिखित परीक्षा में बनाई गई फ़ाइल पढ़ें:
$ dd if=./largefile of=/dev/null bs=4k
165118+0 records in
165118+0 records out
676323328 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
थोड़ा और अधिक: SIMPLE BONNIE ++ EXAMPLE ।
अखंडता की जाँच करें, नकली फ्लैश ड्राइव और परीक्षण प्रदर्शन का पता लगाएं, एक शॉट में तीनों।
इस जवाब पर अधिक ।