जवाबों:
मैं आमतौर पर hdparmअपने HDD के बेंचमार्क का उपयोग करता हूं। आप दोनों डायरेक्ट रीड और कैश्ड रीड को बेंचमार्क कर सकते हैं। आप एक औसत मूल्य स्थापित करने के लिए कई बार कमांड चलाना चाहेंगे।
यहाँ एक सीधा पढ़ा है।
$ sudo hdparm -t /dev/sda2
/dev/sda2:
Timing buffered disk reads: 302 MB in 3.00 seconds = 100.58 MB/sec
और यहाँ एक कैश्ड रीड है।
$ sudo hdparm -T /dev/sda2
/dev/sda2:
Timing cached reads: 4636 MB in 2.00 seconds = 2318.89 MB/sec
-t Perform timings of device reads for benchmark and comparison
purposes. For meaningful results, this operation should be repeated
2-3 times on an otherwise inactive system (no other active processes)
with at least a couple of megabytes of free memory. This displays
the speed of reading through the buffer cache to the disk without
any prior caching of data. This measurement is an indication of how
fast the drive can sustain sequential data reads under Linux, without
any filesystem overhead. To ensure accurate measurements, the
buffer cache is flushed during the processing of -t using the
BLKFLSBUF ioctl.
-T Perform timings of cache reads for benchmark and comparison purposes.
For meaningful results, this operation should be repeated 2-3
times on an otherwise inactive system (no other active processes)
with at least a couple of megabytes of free memory. This displays
the speed of reading directly from the Linux buffer cache without
disk access. This measurement is essentially an indication of the
throughput of the processor, cache, and memory of the system under
test.
मैंने भी ddइस प्रकार के परीक्षण के लिए उपयोग किया है । एक संशोधन मैं उपरोक्त आदेश को देते थे और अपनी कमांड के अंत करने के लिए इस बिट जोड़ने के लिए है ; rm ddfile।
$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile
ddfileकमांड पूरा होने के बाद यह हटा देगा । नोट: ddfile एक क्षणिक फ़ाइल है जिसे आपको रखने की आवश्यकता नहीं है, यह वह फ़ाइल है जो dd( of=ddfile) को लिख रही है , जब यह आपके एचडीडी को लोड में डाल रही है।
यदि आपको अपने HDD के अधिक कठोर परीक्षण की आवश्यकता है तो आप बोनी ++ का उपयोग कर सकते हैं ।
hdparmत्वरित बेंचमार्क के लिए भी पसंद है । केवल नकारात्मक पक्ष यह है कि केवल बेंचमार्क रीड बैंडविड्थ और कई प्रकार के ब्लॉक डिवाइस (जैसे RAID, iSCSI) का प्रदर्शन बहुत ही विषम हो सकता है। एक ही बॉक्स पर 'पहले' और बाद में 'प्रदर्शन' की तुलना के लिए, ddअच्छी तरह से भी काम करता है।
hdparm+ ddया सिर्फ bonnie++एक या सभी 3.
(यह एक बहुत लोकप्रिय प्रश्न है - आप https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 और https://askubuntu.com/q पर इसके रूपांतर देख सकते हैं / 87035/740413 )
क्या [dd] से [बेंचमार्क डिस्क] तक बेहतर तरीके हैं?
हां, लेकिन उन्हें चलाने में अधिक समय लगेगा और परिणामों की व्याख्या करने के लिए ज्ञान की आवश्यकता होगी - कोई एक संख्या नहीं है जो आपको एक बार में सब कुछ बताएगी क्योंकि निम्नलिखित प्रभाव आपको परीक्षण के प्रकार को चलाने चाहिए:
और इसी तरह।
नीचे शीर्ष पर चलने के लिए सबसे आसान और कठिन / अधिक गहन / बेहतर निकटवर्ती टूल की एक छोटी सूची यहां दी गई है:
ग्रेग - जेन्स का FIO कोड प्राप्त करें। यह चीजों को सही करता है, जिसमें वास्तविक छद्म यादृच्छिक सामग्री लिखना शामिल है, जो दिखाता है कि क्या डिस्क कुछ "डी-डुप्लीकेशन" (उर्फ "बेंचमार्क के लिए अनुकूलन) करती है:
[ https://github.com/axboe/fio/ ]
कुछ भी संदिग्ध है - बोनी या अन्य पारंपरिक उपकरणों के बारे में भूल जाओ।
स्रोत: लिनुस टोरवाल्ड्स द्वारा ग्रेग क्रोहा-हार्टमैन के लिए Google प्लस पर छोड़ी गई टिप्पणी ।
यदि आप यह सब पढ़ने के लिए परेशान नहीं हो सकते हैं तो मैं सिर्फ IOPS टूल की सिफारिश करूंगा । यह आपको ब्लॉक-आकार के आधार पर वास्तविक-दुनिया की गति बताएगा।
अन्यथा - IO बेंचमार्क करते समय मैं निम्नलिखित बातों पर ध्यान दूंगा:
सीपीयू का उपयोग
आप किस अवरोधक का उपयोग करेंगे : यदि आप / GB से / डिस्क पर 1 GB पढ़ना / लिखना चाहते हैं तो यदि आप एक I / O ऑपरेशन करते हैं तो यह त्वरित होगा। लेकिन अगर आपके आवेदन को गैर-अनुक्रमिक टुकड़ों में हार्डडिस्क पर 512 बाइट विखंडू में लिखने की आवश्यकता है (जिसे यादृच्छिक I / O कहा जाता है, हालांकि यह यादृच्छिक नहीं है) यह अलग तरह से दिखेगा। अब, डेटाबेस अपनी प्रकृति के कारण लॉग वॉल्यूम के लिए डेटा वॉल्यूम और अनुक्रमिक I / O के लिए यादृच्छिक I / O करेंगे । तो, पहले आपको स्पष्ट होना चाहिए कि आप क्या मापना चाहते हैं। यदि आप बड़ी वीडियो फ़ाइलों को कॉपी करना चाहते हैं जो लिनक्स स्थापित करना चाहते हैं तो इससे अलग है।
यह अवरोधक आपके द्वारा किए जाने वाले I / O संचालन की गिनती को प्रभावित कर रहा है। यदि आप उदाहरण के लिए 8 अनुक्रमिक पढ़ते हैं (या लिखते हैं, सिर्फ मिश्रित नहीं) तो संचालन मैं / ओएस के अनुसूचक उन्हें मर्ज कर देगा। यदि ऐसा नहीं होता है, तो नियंत्रक का कैश मर्ज कर देगा। यदि आप 512 बाइट्स के 8 अनुक्रमिक ब्लॉक या 4096 बाइट्स चंक पढ़ते हैं, तो व्यावहारिक रूप से कोई अंतर नहीं है। एक अपवाद - यदि आप प्रत्यक्ष सिंक IO करने का प्रबंधन करते हैं और अगले 512 बाइट्स का अनुरोध करने से पहले 512 बाइट्स की प्रतीक्षा करें। इस मामले में, ब्लॉक का आकार बढ़ाना कैश जोड़ने जैसा है।
इसके अलावा, आपको पता होना चाहिए कि सिंक और async IO है: सिंक IO के साथ आप अगले IO अनुरोध को वर्तमान रिटर्न से पहले जारी नहीं करेंगे। Async IO के साथ आप अनुरोध कर सकते हैं जैसे 10 चंक्स डेटा और फिर प्रतीक्षा के रूप में वे आते हैं। अप्रचलित डेटाबेस थ्रेड्स आमतौर पर लॉग के लिए सिंक IO और डेटा के लिए Async IO का उपयोग करेंगे। IOPS टूल 512 बाइट्स से शुरू होने वाले सभी संबंधित ब्लॉक आकारों को मापकर इसका ख्याल रखता है।
क्या आप पढ़ेंगे या लिखेंगे : आमतौर पर पढ़ने लिखने से तेज होता है। लेकिन ध्यान दें कि कैशिंग पढ़ने और लिखने के लिए काफी अलग तरीके से काम करता है:
लिखने के लिए, डेटा नियंत्रक को सौंप दिया जाएगा और यदि यह कैश हो जाता है, तो यह तब तक स्वीकार करेगा जब तक कि कैश भरा न हो। उपकरण iozone का उपयोग करके आप कैश इफ़ेक्ट (CPU कैश इफ़ेक्ट और बफर कैशे इफ़ेक्ट) के पठारों के सुंदर रेखांकन बना सकते हैं। कैश कम कुशल हो जाता है जितना अधिक लिखा गया है।
रीड्स के लिए, पहले पढ़े जाने के बाद रीड डेटा कैश में आयोजित किया जाता है। पहले पढ़ता है सबसे लंबे समय तक ले लो और कैशिंग अपटाइम के दौरान अधिक से अधिक प्रभावी हो जाता है। उल्लेखनीय कैश सीपीयू कैश, ओएस फाइल सिस्टम कैश, आईओ कंट्रोलर कैश और स्टोरेज कैश हैं। IOPS उपकरण केवल उपाय पढ़ता है। यह इसे "सभी जगह पढ़ने" की अनुमति देता है और आप नहीं चाहते कि यह पढ़ने के बजाय लिखें।
आप कितने थ्रेड्स का उपयोग करेंगे : यदि आप एक थ्रेड ( डिस्क बेंचमार्क के लिए dd का उपयोग करके ) का उपयोग करते हैं, तो आपको संभवतः कई थ्रेड्स की तुलना में बहुत खराब प्रदर्शन मिलेगा। IOPS टूल इसे ध्यान में रखता है और कई थ्रेड्स पर पढ़ता है।
आपके लिए विलंबता कितनी महत्वपूर्ण है : डेटाबेस को देखते हुए, IO विलंबता काफी महत्वपूर्ण हो जाती है। किसी भी इंसर्ट / अपडेट / डिलीट एसक्यूएल कमांड को स्वीकार किए जाने से पहले डेटाबेस जर्नल (डेटाबेस लॉग इन में "लॉग" में) लिखा जाएगा। इसका मतलब है कि पूरा डेटाबेस इस IO ऑपरेशन के पूरा होने की प्रतीक्षा कर सकता है। मैं यहां दिखाता हूं कि iostat टूल का उपयोग करके औसत प्रतीक्षा समय (प्रतीक्षा) को कैसे मापें ।
आपके लिए CPU का उपयोग कितना महत्वपूर्ण है : आपका CPU आपके एप्लिकेशन के प्रदर्शन के लिए आसानी से अड़चन बन सकता है। इस स्थिति में आपको पता होना चाहिए कि सीपीयू चक्र प्रति बाइट / पढ़े जाने पर कितना जल जाता है और उस दिशा में अनुकूलित हो जाता है। यह आपके माप परिणामों के आधार पर PCIe फ्लैश मेमोरी के लिए / के खिलाफ निर्णय लेने के लिए हो सकता है। फिर से iostat उपकरण आपको अपने IO परिचालनों द्वारा CPU उपयोग पर एक मोटा अनुमान दे सकता है।
यदि आपने PostgreSQL स्थापित किया है, तो आप उनके उत्कृष्ट pg_test_fsync बेंचमार्क का उपयोग कर सकते हैं । यह मूल रूप से आपके लेखन सिंक प्रदर्शन का परीक्षण करता है।
उबंटू पर आप इसे यहाँ पाते हैं: /usr/lib/postgresql/9.5/bin/pg_test_fsync
इसके बारे में महान बात यह है कि यह उपकरण आपको दिखाएगा कि उद्यम एसएसडी अतिरिक्त डॉलर के लायक क्यों हैं।
postgresql-contribपैकेज में उपलब्ध है ।
आप उपयोग कर सकते हैं fio- मल्टीथ्रेडेड IO पीढ़ी उपकरण । इसे कई वितरणों द्वारा पैक किया जाता है, जैसे फेडोरा 25, डेबियन और ओपनसीएसडब्ल्यू।
फियो टूल बहुत लचीला है, इसे आसानी से विभिन्न आईओ परिदृश्यों को बेंचमार्क करने के लिए इस्तेमाल किया जा सकता है - समवर्ती वाले सहित। पैकेज कुछ उदाहरण विन्यास फाइल (cf. उदा /usr/share/doc/fio/examples।) के साथ आता है । यह चीजों को ठीक से मापता है, अर्थात यह कुछ आंकड़ों के लिए मानक विचलन और मात्रात्मक आंकड़े भी छापता है। कुछ अन्य लोकप्रिय बेंचमार्किंग टूल के बारे में परवाह नहीं है।
एक सरल उदाहरण (सरल परिदृश्यों का एक क्रम: अनुक्रमिक / यादृच्छिक एक्स रीड / राइट):
$ cat fio.cfg
[global]
size=1g
filename=/dev/sdz
[randwrite]
rw=randwrite
[randread]
wait_for=randwrite
rw=randread
size=256m
[seqread]
wait_for=randread
rw=read
[seqwrite]
wait_for=seqread
rw=write
कॉल:
# fio -o fio-seagate-usb-xyz.log fio.cfg
$ cat fio-seagate-usb-xyz.log
[..]
randwrite: (groupid=0, jobs=1): err= 0: pid=11858: Sun Apr 2 21:23:30 2017
write: io=1024.0MB, bw=16499KB/s, iops=4124, runt= 63552msec
clat (usec): min=1, max=148280, avg=240.21, stdev=2216.91
lat (usec): min=1, max=148280, avg=240.49, stdev=2216.91
clat percentiles (usec):
| 1.00th=[ 2], 5.00th=[ 2], 10.00th=[ 2], 20.00th=[ 7],
| 30.00th=[ 10], 40.00th=[ 11], 50.00th=[ 11], 60.00th=[ 12],
| 70.00th=[ 14], 80.00th=[ 16], 90.00th=[ 19], 95.00th=[ 25],
| 99.00th=[ 9408], 99.50th=[10432], 99.90th=[21888], 99.95th=[38144],
| 99.99th=[92672]
bw (KB /s): min= 7143, max=371874, per=45.77%, avg=15104.53, stdev=32105.17
lat (usec) : 2=0.20%, 4=15.36%, 10=6.58%, 20=69.35%, 50=6.07%
lat (usec) : 100=0.49%, 250=0.07%, 500=0.01%, 750=0.01%
lat (msec) : 4=0.01%, 10=1.20%, 20=0.54%, 50=0.08%, 100=0.03%
lat (msec) : 250=0.01%
cpu : usr=1.04%, sys=4.79%, ctx=4977, majf=0, minf=11
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=0/w=262144/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=1
randread: (groupid=0, jobs=1): err= 0: pid=11876: Sun Apr 2 21:23:30 2017
read : io=262144KB, bw=797863B/s, iops=194, runt=336443msec
[..]
bw (KB /s): min= 312, max= 4513, per=15.19%, avg=591.51, stdev=222.35
[..]
ध्यान दें कि इस [global]खंड में वैश्विक चूक हैं जिन्हें अन्य वर्गों द्वारा समाप्त किया जा सकता है। प्रत्येक अनुभाग एक नौकरी का वर्णन करता है, अनुभाग नाम नौकरी का नाम है और स्वतंत्र रूप से चुना जा सकता है। डिफ़ॉल्ट रूप से, विभिन्न नौकरियों को समानांतर में शुरू किया जाता है, इस प्रकार उपरोक्त उदाहरण wait_forकुंजी के साथ नौकरी के निष्पादन को स्पष्ट रूप से अनुक्रमित करता है
। इसके अलावा, फियो 4 KiB के ब्लॉक आकार का उपयोग करता है - जिसे बदला भी जा सकता है। उदाहरण सीधे पढ़ने और लिखने के लिए कच्चे उपकरण का उपयोग करता है, इस प्रकार, सुनिश्चित करें कि आप सही डिवाइस का उपयोग करते हैं। यह टूल मौजूदा फाइल सिस्टम पर एक फाइल / डायरेक्टरी का उपयोग करने का भी समर्थन करता है।
hdparmउपयोगिता एक बहुत ही सरल पढ़ने बेंचमार्क, जैसे प्रदान करता है:
# hdparm -t -T /dev/sdz
यह फियो जैसे अत्याधुनिक बेंचमार्किंग टूल के लिए एक प्रतिस्थापन नहीं है, इसे सिर्फ पहली बार जांच के लिए इस्तेमाल किया जाना चाहिए। उदाहरण के लिए, यह जांचने के लिए कि क्या बाहरी USB 3 ड्राइव गलत रूप से USB 2 डिवाइस के रूप में पहचानी जाती है (आप ~ 100 MiB / s बनाम ~ 30 MiB / s रेट तब देखेंगे)।
के रूप में यहाँ बताया यहाँ , आप उपयोग कर सकते हैं gnome-disks(यदि आप ग्नोम उपयोग करें)।
उस ड्राइव पर क्लिक करें जिसे आप परीक्षण करना चाहते हैं और "अतिरिक्त विभाजन विकल्प" (पहियों) पर क्लिक करें। तब Benchmark Partition। आपको MB / s में औसत पढ़ने / लिखने और मिलीसेकंड में औसत एक्सेस समय मिलेगा। मुझे वह बहुत सहज लगी।
यह थोड़ा कच्चा है, लेकिन यह चुटकी में काम करता है:
find <path> -type f -print0 | cpio -0o >/dev/null
आप इस तकनीक के साथ कुछ दिलचस्प चीजें कर सकते हैं, जिसमें सभी /libऔर /usr/binफाइलों को कैशिंग करना शामिल है । आप इसे बेंचमार्किंग प्रयास के भाग के रूप में भी उपयोग कर सकते हैं:
find / -xdev -type f -print0 |
sort -R --from0-file=- |
timeout "5m" cpio -0o >/dev/null
रूट पर सभी फ़ाइलनाम पाए जाते हैं, यादृच्छिक रूप से सॉर्ट किए जाते हैं, और उन्हें 1 मिनट तक कैश में कॉपी किया जाता है। Cpio से आउटपुट आपको बताता है कि कितने ब्लॉक कॉपी किए गए थे। ब्लॉक-प्रति-मिनट का औसत प्राप्त करने के लिए 3 बार दोहराएं। (ध्यान दें, खोज / सॉर्ट ऑपरेशन में कॉपी की तुलना में बहुत लंबा समय लग सकता है। फाइंड / splitसैंपल प्राप्त करने के लिए फाइंड / सॉर्ट को कैश करना बेहतर होगा ।)