क्या "dd" में "bs" विकल्प वास्तव में गति में सुधार करता है?


58

हर अब और फिर, मुझे बताया गया है कि "dd" की गति बढ़ाने के लिए मुझे सावधानीपूर्वक एक उचित "ब्लॉक आकार" चुनना चाहिए।

यहां तक ​​कि सर्वरफॉल्ट पर, किसी और ने लिखा है कि " ... इष्टतम ब्लॉक आकार हार्डवेयर निर्भर है ... " (आईएएन) या " ... सही आकार आपके सिस्टम बस, हार्ड ड्राइव नियंत्रक, विशेष ड्राइव पर निर्भर करेगा स्वयं और उनमें से प्रत्येक के लिए ड्राइवर ... " (क्रिस-एस)

जैसा कि मेरा एहसास थोड़ा अलग था ( BTW: मैंने सोचा था कि bs पैरामीटर को गहराई से ट्यून करने के लिए आवश्यक समय प्राप्त होने के मामले में प्राप्त लाभ की तुलना में बहुत अधिक था, और यह कि डिफ़ॉल्ट उचित था ), आज मैं बस गया कुछ त्वरित और गंदे बेंचमार्क के माध्यम से।

बाहरी प्रभावों को कम करने के लिए, मैंने पढ़ने का फैसला किया:

  • बाहरी एमएमसी कार्ड से
  • आंतरिक विभाजन से

तथा:

  • संबंधित फाइल सिस्टम के साथ umounted
  • "लेखन गति" से संबंधित मुद्दों से बचने के लिए आउटपुट / देव / नल को भेजना;
  • एचडीडी-कैशिंग के कुछ बुनियादी मुद्दों से बचते हुए, कम से कम एचडीडी को शामिल करते समय।

निम्नलिखित तालिका में, मैंने अपने निष्कर्षों की रिपोर्ट की है, "बी एस" के विभिन्न मूल्यों के साथ 1 जीबी डेटा पढ़ रहा है ( आप इस संदेश के अंत में कच्चे नंबर पा सकते हैं ):

यहाँ छवि विवरण दर्ज करें

मूल रूप से यह पता चलता है कि:

  • MMC: bs = 4 (हाँ! 4 बाइट्स) के साथ, मैं 12MB / s के थ्रूपुट पर पहुंच गया। एक बहुत दूर का मान अधिकतम 14.2 / 14.3 तक नहीं है जो मुझे bs = 5 और इसके बाद के संस्करण से मिला;

  • HDD: bs = 10 के साथ मैं 30 MB / s तक पहुँच गया। 95.3 एमबी की तुलना में निश्चित रूप से कम डिफ़ॉल्ट बी एस = 512 के साथ मिला लेकिन ... महत्वपूर्ण भी।

साथ ही, यह बहुत स्पष्ट था कि CPU sys-time, bs मान के व्युत्क्रमानुपाती था (लेकिन यह उचित लगता है, bs जितना कम होगा, dd द्वारा उत्पन्न sys-call की संख्या उतनी ही अधिक होगी)।

उपरोक्त सभी के बाद, अब यह प्रश्न है कि क्या कोई समझा सकता है (कर्नेल हैकर?) ऐसे थ्रूपुट में कौन से प्रमुख घटक / प्रणालियाँ शामिल हैं, और यदि यह वास्तव में डिफ़ॉल्ट से अधिक b को निर्दिष्ट करने के प्रयास के लायक है?


एमएमसी मामला - कच्चे नंबर

bs = 1M

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1M count=1000
1000+0 record dentro
1000+0 record fuori
1048576000 byte (1,0 GB) copiati, 74,1239 s, 14,1 MB/s

real    1m14.126s
user    0m0.008s
sys     0m1.588s

bs = 1k

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1k count=1000000
1000000+0 record dentro
1000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 72,7795 s, 14,1 MB/s

real    1m12.782s
user    0m0.244s
sys     0m2.092s

bs = 512

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=512 count=2000000
2000000+0 record dentro
2000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 72,867 s, 14,1 MB/s

real    1m12.869s
user    0m0.324s
sys     0m2.620s

bs = 10

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=10 count=100000000
100000000+0 record dentro
100000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 70,1662 s, 14,3 MB/s

real    1m10.169s
user    0m6.272s
sys     0m28.712s

bs = 5

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=5 count=200000000
200000000+0 record dentro
200000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 70,415 s, 14,2 MB/s

real    1m10.417s
user    0m11.604s
sys     0m55.984s

bs = 4

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=4 count=250000000
250000000+0 record dentro
250000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 80,9114 s, 12,4 MB/s

real    1m20.914s
user    0m14.436s
sys     1m6.236s

bs = 2

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=2 count=500000000
500000000+0 record dentro
500000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 161,974 s, 6,2 MB/s

real    2m41.976s
user    0m28.220s
sys     2m13.292s

bs = 1

root@iMac-Chiara:/tmp# time dd if=/dev/sdc of=/dev/null bs=1 count=1000000000
1000000000+0 record dentro
1000000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 325,316 s, 3,1 MB/s

real    5m25.318s
user    0m56.212s
sys     4m28.176s

एचडीडी केस - कच्चे नंबर

bs = 1

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1 count=1000000000
1000000000+0 record dentro
1000000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 341,461 s, 2,9 MB/s

real    5m41.463s
user    0m56.000s
sys 4m44.340s

bs = 2

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=2 count=500000000
500000000+0 record dentro
500000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 164,072 s, 6,1 MB/s

real    2m44.074s
user    0m28.584s
sys 2m14.628s

bs = 4

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=4 count=250000000
250000000+0 record dentro
250000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 81,471 s, 12,3 MB/s

real    1m21.473s
user    0m14.824s
sys 1m6.416s

bs = 5

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=5 count=200000000
200000000+0 record dentro
200000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 66,0327 s, 15,1 MB/s

real    1m6.035s
user    0m11.176s
sys 0m54.668s

bs = 10

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=10 count=100000000
100000000+0 record dentro
100000000+0 record fuori
1000000000 byte (1,0 GB) copiati, 33,4151 s, 29,9 MB/s

real    0m33.417s
user    0m5.692s
sys 0m27.624s

bs = 512 (कैशिंग से बचने के लिए रीडिंग ऑफसेट करना)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=512 count=2000000 skip=6000000
2000000+0 record dentro
2000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 10,7437 s, 95,3 MB/s

real    0m10.746s
user    0m0.360s
sys 0m2.428s

bs = 1 k (कैशिंग से बचने के लिए रीडिंग को ऑफ़सेट करना)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1k count=1000000 skip=6000000
1000000+0 record dentro
1000000+0 record fuori
1024000000 byte (1,0 GB) copiati, 10,6561 s, 96,1 MB/s

real    0m10.658s
user    0m0.164s
sys 0m1.772s

bs = 1 k (कैशिंग से बचने के लिए रीडिंग को ऑफ़सेट करना)

root@iMac-Chiara:/tmp# time dd if=/dev/sda3 of=/dev/null bs=1M count=1000 skip=7000
1000+0 record dentro
1000+0 record fuori
1048576000 byte (1,0 GB) copiati, 10,7391 s, 97,6 MB/s

real    0m10.792s
user    0m0.008s
sys 0m1.144s

11
क्या वास्तव में अच्छा होगा एक bs=autoविशेषता है ddकि डिवाइस से इष्टतम बी एस पैरामीटर का पता लगाएगा और उसका उपयोग करेगा।

4
क्या बहुत अच्छा होगा bsएक ही प्रश्न में 15 दर्जन कोड ब्लॉक के बजाय गति के खिलाफ प्लॉट किए गए कई आकारों का एक ग्राफ है । कम जगह लेगा और पढ़ने के लिए असीम तेज होगा। एक तस्वीर वास्तव में एक थोरसंड शब्दों के लायक है।
MDMoore313

2
@ बिगहॉमी - मैंने एक ग्राफ प्रदान करने के बारे में सोचा लेकिन ... कई "स्केलिंग" समस्याएं हैं। यह, शायद, दोनों अक्ष पर एक लघुगणकीय पैमाने की आवश्यकता होगी और ... यह सोचते हुए, मैंने सोचा कि यह हल करने के लिए एक आसान (और त्वरित) समस्या नहीं थी। इसलिए मैंने "टेबल" संस्करण पर स्विच किया। "... 15 दर्जन कोड ब्लॉक" के रूप में, मैं चाहता था कि सभी को "कच्चे नंबर" की जांच करने का मौका मिले, किसी भी (व्यक्तिगत, मेरा) हस्तक्षेप से बचने के लिए।
डेमियानो Verzulli

1
@DamianoVerzulli तालिका मस्त है, कृपया मेरे शेख़ी को नज़रअंदाज़ करें, मैंने आपको हमारे अंधविश्वासों को साबित करने के लिए एक अपवोट दिया है, और मुझे पहले से पता है कि बाइट के आकार के साथ फ़िडलिंग गति को बदल देगी, मैं इसे एक उत्तर के रूप में भी डाल सकता हूं।
MDMoore313 20

1
@warren - 4G पाने के लिए आप 2 अतीत की शक्तियों को भी याद नहीं रख सकते हैं bs=8k count=512Kया bs=1M count=4K65536
user313114

जवाबों:


24

आपने जो किया है, वह केवल पढ़ने की गति का परीक्षण है। यदि आप वास्तव में किसी अन्य डिवाइस के ब्लॉक को कॉपी कर रहे हैं जिसे आप रीडिंग में रोकते हैं, जबकि दूसरा डिवाइस आपके द्वारा लिखे गए डेटा को स्वीकार कर रहा है, जब ऐसा होता है तो आप रीड डिवाइस पर घूर्णी विलंबता मुद्दों को हिट कर सकते हैं (यदि यह एक हार्ड डिस्क है) और इसलिए जैसे ही आप घूर्णन विलंबता के खिलाफ आते हैं, तो अक्सर HDD से 1M हिस्सा पढ़ना काफी तेज होता है।

मुझे पता है कि जब मैं हार्ड डिस्क की नकल कर रहा होता हूं तो मैं bs=1Mउपयोग bs=4kया डिफ़ॉल्ट की तुलना में निर्दिष्ट करके तेज दर प्राप्त करता हूं । मैं 30 से 300 प्रतिशत की गति सुधार की बात कर रहा हूं। जब तक यह सब आप हर दिन नहीं करते, तब तक इसे पूरी तरह से ट्यून करने की आवश्यकता नहीं है। लेकिन डिफ़ॉल्ट से बेहतर कुछ लेने से निष्पादन समय बंद हो सकता है।

जब आप इसे वास्तविक के लिए उपयोग कर रहे हैं तो कुछ अलग संख्याओं को आज़माएं और एक स्थिति रिपोर्ट जारी करने के लिए ddप्रक्रिया को SIGUSR1सिग्नल भेजें ताकि आप देख सकें कि यह कैसे चल रहा है।

✗ killall -SIGUSR1 dd
1811+1 records in
1811+1 records out
1899528192 bytes (1.9 GB, 1.8 GiB) copied, 468.633 s, 4.1 MB/s

2014 मैकबुक प्रो रेटिना 90 एमबी / एस लिखने पर रेटेड यूएसबी 3 स्टिक की नकल: $ sudo dd if=~/Downloads/Qubes-R4.0-rc4-x86_64.iso of=/dev/rdisk2 status=progressशो 6140928 bytes (6.1 MB, 5.9 MiB) copied, 23 s, 267 kB/s। मैंने इसे रद्द कर दिया क्योंकि इसमें बहुत समय लग रहा था। अब बाइट्स को निर्दिष्ट करते हुए: $ sudo dd if=~/Downloads/Qubes-R4.0-rc4-x86_64.iso of=/dev/rdisk2 bs=1M status=progressशो4558159872 bytes (4.6 GB, 4.2 GiB) copied, 54 s, 84.4 MB/s
एरिक डंकन

9

साथ आंतरिक हार्ड डिस्क के संबंध में, कम से कम - जब आप डिवाइस से पढ़ रहे हैं ब्लॉक परत कम से कम एक क्षेत्र है जो 512 बाइट्स है पुनः प्राप्त करने के है।

इसलिए, जब एक 1 बाइट पढ़ी जाती है, तो आप केवल डिस्क पर संरेखित बाइट पुनर्प्राप्ति से पढ़ते हैं। शेष 511 बार कैश द्वारा सेवा दी जाती है।

आप इसे निम्नानुसार साबित कर सकते हैं, इस उदाहरण sdbमें ब्याज की एक डिस्क है:

# grep sdb /proc/diskstats
8      16 sdb 767 713 11834 6968 13710 6808 12970792 6846477 0 76967 6853359
...
# dd if=/dev/sdb of=/dev/null bs=1 count=512
512+0 records in
512+0 records out
512 bytes (512 B) copied, 0.0371715 s, 13.8 kB/s
# grep sedb /proc/diskstats
8      16 sdb 768 713 11834 6968 13710 6808 12970792 6846477 0 76967 6853359
...

चौथा स्तंभ (जो पढ़ता है गिनता है) इंगित करता है कि केवल 1 रीड हुआ, इस तथ्य के बावजूद कि आपने 1 बाइट का अनुरोध किया था। यह अपेक्षित व्यवहार है क्योंकि इस डिवाइस (एक SATA 2 डिस्क) को न्यूनतम रिटर्न अपने सेक्टर आकार में देना है। कर्नेल बस पूरे क्षेत्र को कैच कर रहा है।

इन आकार अनुरोधों में खेलने का सबसे बड़ा कारक एक पढ़ने या लिखने के लिए एक सिस्टम कॉल जारी करने का ओवरहेड है। वास्तव में, <512 के लिए कॉल जारी करना अक्षम है। बहुत बड़ी रीड को अधिक मेमोरी की लागत पर कम सिस्टम कॉल की आवश्यकता होती है जो इसे करने के लिए उपयोग की जा रही है।

4096 आम तौर पर पढ़ने के लिए एक 'सुरक्षित' संख्या है क्योंकि:

  • एक पृष्ठ पर कैशिंग के साथ पढ़ने पर (डिफ़ॉल्ट) एक पृष्ठ 4k है। <4k पठन के साथ एक पृष्ठ भरना पठन और पृष्ठ के आकार को समान रखने की तुलना में अधिक जटिल है।
  • अधिकांश फाइलसिस्टम ब्लॉक आकार 4k पर सेट हैं।
  • इसकी एक छोटी पर्याप्त संख्या नहीं है (शायद SSDs के लिए यह अब हालांकि है) क्योंकि सिस्केल ओवरहेड का कारण बनता है लेकिन बहुत बड़ी संख्या में बहुत सारी मेमोरी का उपभोग करने के लिए नहीं।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.