टीएल; ड्र - हम दो अलग-अलग मैक क्लाइंट से एसएमबी और एएफपी के माध्यम से हमारे एनएएस को 60 एमबी / सेकंड की सीमित लिखने की गति का कारण नहीं ढूंढ सकते हैं। तुलना में: एक ही नेटवर्क में एक पुराना विंडोज 7 लैपटॉप स्थिर 100 एमबी / सेकंड लिखता है।
यदि आप पहली बार इस प्रश्न को पढ़ते हैं, तो कृपया अपडेट 4 अनुभाग पर जाएं। rsyncकम गति के लिए मुख्य कारण है, भले ही हम यह क्यों नहीं समझते (एक फ़ाइल के लिए!)।
मूल प्रश्न: मैक ओएस 10.11.5 और ऊपर के साथ गति अड़चन SMB3 / NAS खोजें
हमने rsync --progress -a /localpath/test.file /nas/test.fileमैकओएस और विंडोज की कॉपी जानकारी पर परीक्षण किया ।
NAS एक DS713 + है जो अपने वर्तमान DSM 6.0.2 (5.x के साथ भी परीक्षण किया गया है), दो HGST डेस्कस्टार NAS SATA 4TB (HDN724040640) RAID1 में केवल गीगाबिट ईथरनेट घटकों और नए ईथरनेट केबल (कम से कम Cat5e) के साथ है।
मैक क्लाइंट ने पहले केवल 20 एमबी / सेकंड बनाया था। लेकिन signing_required=noफिक्स ( यहां वर्णित ) को लागू करने से SMB2 और SMB3 के माध्यम से लेखन की गति 60 एमबी / सेकंड हो गई। एएफपी भी लगभग 60 एमबी / सेकंड बचाता है। परिणाम प्रोटोकॉल और (मैक) क्लाइंट के आधार पर लगभग 5 एमबी / सेकंड भिन्न होता है।
हमने पहले से ही क्या प्रयास किया है:
नेटवर्क
- Iperf3 के माध्यम से नेटवर्क प्रदर्शन का परीक्षण किया। परिणाम: 926 Mbit / s। अछा लगता है।
- कोशिश की दोहरी लिंक एकत्रीकरण / बंधुआ नेटवर्क इंटरफेस। कोई परिवर्तन नहीं होता है।
- एमटीयू को 6000 और 9000 तक बढ़ाया। कोई बदलाव नहीं।
- सभी केबलों की जांच की। सभी ठीक है कम से कम Cat5e, अच्छी हालत में।
डिस्क
- जाँच की गई SMART स्वस्थ दिखती है।
dd if=/dev/zero of=write.test bs=256M count=4विभिन्नbsऔरcountसेटिंग्स (128/8, 512M / 2, 1024/1) के साथ डिस्क के लिए सीधे लिखित गति का परीक्षण किया । परिणाम: लगभग 120 एमबी / एस (ब्लॉक आकार / गणना के आधार पर)
SMB / एएफपी
एक दूसरे के खिलाफ बेंचमार्क SMB2, SMB3 और AFP। बराबर के बारे में।
नीचे अपडेट देखें: macOS के SMB कार्यान्वयन को हटाने के लिए गलत तरीके का उपयोग किया गया। विंडोज पर एसएमबी तेज है, मैक 10.11 और 10.12 के साथ आने वाली नई एसएमबी सेटिंग्स इसका कारण हो सकता है।- सॉकेट विकल्पों (इस निर्देश के बाद ) सहित SMB सेटिंग्स को ट्विक करने की कोशिश की
- विलंबित सेटिंग्स के अलग संस्करण की कोशिश की और
rsync --sockopts=TCP_NODELAY(टिप्पणियाँ)
लेखन की गति का कोई महत्वपूर्ण परिवर्तन नहीं। हमने डबल चेक किया कि कॉन्फ़िगरेशन वास्तव में भरी हुई थी और हम सही smb.conf का संपादन कर रहे थे ।
प्रणाली
- सीपीयू और रैम लोड देखा। कुछ भी नहीं अधिकतम। 20% के आसपास CPU, स्थानांतरण के दौरान RAM लगभग 25%।
- लगभग आउट-ऑफ-द-बॉक्स सेटअप में DSM 5.xx के साथ एक ही NAS का परीक्षण किया गया। कोई अतिरिक्त सॉफ़्टवेयर स्थापित नहीं है। नोट: हमारे पास विभिन्न स्थानों में इनमें से दो हैं। वे Synology के CloudSync के माध्यम से सिंक में हैं। एक ही परिणाम।
- अनावश्यक सब कुछ निष्क्रिय कर दिया जो सिस्टम संसाधनों को आकर्षित कर सकता है।
हमें लगता है कि यह एक डिफ़ॉल्ट डिफ़ॉल्ट सेटअप है, कोई फैंसी अनुकूलन, क्लाइंट या नेटवर्क घटक नहीं है। मेट्रिक्स के अनुसार सिनोलॉजी प्रकाशित करती है कि NAS को 40 MB / s से 75 MB / s तेज प्रदर्शन करना चाहिए। लेकिन हम सिर्फ अड़चन नहीं खोज सकते।
ग्राहकों / NAS
मैक क्लाइंट एक macpro 5,1 हैं (मानक वायर्ड एनआईसी, 10.12.3 (16D32) चल रहा है) और एक मैकबुकप्रो 10,1 (थंडरबोल्ट नेटवर्क एडेप्टर, 10.11.6 रनिंग) केवल NAS से लगभग 2 मीटर की दूरी पर चल रहा है, उसी पर चल रहा है टेस्टिंग में विंडोज लैपटॉप के रूप में गीगाबिट स्विच।
हमारे पास अलग-अलग स्थानों में इनमें से दो NAS हैं और परिणाम समान हैं। सेकंड एनएएस अधिक या कम फ़ैक्टरी डिफ़ॉल्ट है (3 जी पार्टी सॉफ़्टवेयर स्थापित नहीं है)। बस दो RAID1, EXT4 स्वरूपित क्लाउड डिस्क के माध्यम से दूसरे NAS पर सिंक करने के लिए स्वरूपित डिस्क। हम स्विच के बिना NAS से सीधे जुड़ने के रूप में दूर तक गए हैं, वही परिणाम।
महत्वपूर्ण अद्यतन
MacOS / OS X के SMB कार्यान्वयन को गलत करने के लिए उपयोग की गई विधि गलत थी। मैंने एक वर्चुअल मशीन के माध्यम से इसका परीक्षण किया, यह मानते हुए कि यह एसएमबी के अपने संस्करण का उपयोग करेगा, लेकिन जाहिर है कि ट्रैफिक मैकओएस को सौंप दिया जाता है, एसएमबी के अपने संस्करण के माध्यम से चल रहा है।
Windows लैपटॉप का उपयोग करके अब मैं औसतन 100 एमबी / सेकेंड हासिल करने में सक्षम हूं। 10.11 और 10.12 के साथ आने वाले एसएमबी कार्यान्वयन / अपडेट का संकेत देना खराब प्रदर्शन का कारण हो सकता है। भले ही signing_requiredसेट हो जाए no।
बहुत अच्छा होगा यदि कोई व्यक्ति कुछ और सेटिंग्स को अपडेट कर सकता है जो अपडेट के साथ बदल सकता है और प्रदर्शन को प्रभावित कर सकता है।
अद्यतन 2 - नई अंतर्दृष्टि
एंड्रयूहेल ने टिप्पणियों में बताया कि मुझे अधिक जानकारी के लिए विंडसरक का उपयोग करके यातायात की विस्तार से जांच करनी चाहिए।
मैं इसलिए sudo tcpdump -i eth0 -s 65535 -w tcpdump.dumpएनएएस पर भागा , जबकि दो परीक्षण फाइलों को 512 एमबी और 1 जीबी के साथ एक को स्थानांतरित किया। और विंडसरक के साथ डंप का निरीक्षण किया।
मुझे क्या मिला:
- OS X और Windows दोनों SMB2 का उपयोग करते प्रतीत होते हैं, हालांकि SMB3 NAS पर सक्षम है (कम से कम Wireshark के अनुसार)।
- OS X MTU के साथ चिपका हुआ लगता है । पैकेट में 1514 बाइट्स हैं, जिससे अधिक नेटवर्क ओवरहेड और भेजे गए पैकेट्स (डंपों में दिखाई देने वाले) हो सकते हैं।
- विंडोज 26334 बाइट्स तक पैकेट भेजने लगता है (यदि मैं डेटा सही ढंग से पढ़ता हूं! तो कृपया सत्यापित करें।) भले ही एमटीयू को अनुमति नहीं देनी चाहिए, क्योंकि यह NAS पर 1500 पर सेट है, अधिकतम सेटिंग वहां 9000 होगी (Synology भी) उनके परीक्षणों में 1500 सेटिंग का उपयोग करता है)।
- जोड़कर उपयोग SMB3 को MacOS के लिए मजबूर करने की कोशिश कर रहा
smb_neg=smb3_onlyकरने के लिए /etc/nsmb.conf काम नहीं किया था या कम से कम तेजी से स्थानान्तरण करने के लिए नेतृत्व नहीं किया था। rsync --sockopts=TCP_NODELAYटीसीपी के विभिन्न संयोजनों के साथ चलने से एसी सेटिंग्स में देरी हुई (0 से 3) का कोई प्रभाव नहीं पड़ा (नोट: मैंने 3 के डिफ़ॉल्ट एसी सेटिंग के साथ tcpdump को चलाया)।
मैंने .csv फ़ाइलों के रूप में 4 डंप बनाए हैं, 2 512 एमबी (टेस्ट-2. फाइल) की नकल करते हुए और 1024 एमबी (टेस्ट.फाइल) की नकल करते हुए 2। आप यहां (25.2 एमबी) वायरशर्क निर्यात डाउनलोड कर सकते हैं । वे अंतरिक्ष को बचाने के लिए ज़िप किए जाते हैं और स्व-व्याख्यात्मक रूप से नामित होते हैं।
अद्यतन 3 - smbutil आउटपुट
टिप्पणियों में harrymcsmbutil statshares -a द्वारा अनुरोध के अनुसार आउटपुट ।
==================================================================================================
SHARE ATTRIBUTE TYPE VALUE
==================================================================================================
home
SERVER_NAME server-name._smb._tcp.local
USER_ID 502
SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED
SMB_VERSION SMB_3.0
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
LARGE_FILE_SUPPORTED TRUE
OS_X_SERVER TRUE
QUERYINFO_NOT_SUPPORTED TRUE
DFS_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
--------------------------------------------------------------------------------------------------
इस पर ध्यान दें: मुझे यकीन है कि यहाँ SIGNING_SUPPORTEDहोने trueका मतलब यह नहीं है कि विन्यास में सेटिंग काम नहीं करती है। लेकिन केवल यह कि यह NAS द्वारा समर्थित है। मैंने ट्रिपल चेक किया है कि signing_requiredमेरे कॉन्फिगरेशन में सेटिंग बदलने से राइट स्पीड (~ 20 एमबी / एस पर ट्यून होने पर, ~ 60 एमबी / एस बंद होने पर) पर असर पड़ता है।
अद्यतन 4 - सांबा युद्धों: एक नई आशा
यह कुछ हद तक शर्मनाक लगता है, लेकिन यहां मुख्य समस्या - फिर से - माप प्रतीत होती है।
rsync --progress -aलेखन गति के बारे में 30 एमबी / एस की लागत निकलती है । ddSMB शेयर के साथ सीधे लिखना और उपयोग करना time cp /local/test.file /NAS/test.fileलगभग 85-90 MB / s पर तेज़ है और जाहिरा तौर पर कॉपी करने का सबसे तेज़ तरीका लगभग 100 MB / s पर macOS खोजक है (जो मापने के लिए सबसे कठिन तरीका भी है, क्योंकि कोई भी नहीं है समय या गति सूचक - जिसे इसकी आवश्यकता है, ठीक है? o_O)। हमने पहले स्टॉपवॉच का उपयोग करके 1 जीबी फ़ाइल और फिर 10 जीबी फ़ाइल की प्रतिलिपि बनाकर इसे मापा।
इस प्रश्न के अंतिम अद्यतन के बाद से हमने क्या प्रयास किया है।
- मैक क्लाइंट से मैक क्लाइंट पर कॉपी करें। दोनों के पास SSDs हैं (MacPro 250 एमबी / एस के साथ डिस्क पर लिखते हैं, मैकबुक प्रो 300 एमबी / एस के साथ)। परिणाम:
ddमैकबुक प्रो से मैकप्रो (rsync25 एमबी / एस) तक लेखन के माध्यम से 65 एमबी / एस । 25 एमबी / एस देखना वह क्षण था जब हमने rsync पर सवाल उठाना शुरू किया। अभी भी 65 एमबी / एस बेहद धीमी हैं। तो macOS पर एसएमबी कार्यान्वयन लगता है ... अच्छी तरह से, संदिग्ध। - Dd और cp के साथ अलग-अलग ack सेटिंग्स की कोशिश की - कोई भाग्य नहीं।
- अंत में हमें सभी उपलब्ध nsmb.conf विकल्पों को सूचीबद्ध करने का एक तरीका मिला। यह एक सरल है
man nsmb.conf। सावधानी ऑनलाइन संस्करण पुराना है!
इसलिए हमने उनमें से कुछ और सेटिंग्स की कोशिश की:
notify_off=yes
validate_neg_off=yes
read_async_cnt=16
write_async_cnt=16
dir_cache_async_cnt=40
protocol_vers_map=4
streams=no
soft=yes
नोट: smb_neg=smb3_only- जैसा कि मैंने पहले ही उम्मीद की थी - वैध सेटिंग नहीं। protocol_vers_map=4मान्य समकक्ष होना चाहिए।
वैसे भी, इनमें से किसी भी सेटिंग से हमारे लिए कोई फर्क नहीं पड़ा।
एक नज़र में नए सवाल
Rsync एक (1!) फ़ाइल को कॉपी करने का इतना महंगा तरीका क्यों है। यहाँ सिंक्रनाइज़ / तुलना करने के लिए बहुत कुछ नहीं है, क्या वहाँ है? Tcpdump संभव ओवरहेड को इंगित नहीं करता है।
SMB शेयर को स्थानांतरित करते समय macOS खोजक की तुलना में धीमी
ddऔरcpधीमी क्यों होती हैं ? ऐसा लगता है कि खोजक के साथ नकल करते समय टीसीपी संचार में काफी कम स्वीकृति है। (फिर से: ack सेटिंग जैसेdelayed_ack=1हमारे लिए कोई फर्क नहीं पड़ा ।)ऐसा प्रतीत होता है कि विंडोज़ एमटीयू को नजरअंदाज करता है, क्योंकि मैकओएस के लिए हर चीज की तुलना में सबसे अच्छा प्रदर्शन के परिणामस्वरूप, काफी बड़ा और इसलिए कम टीसीपी पैकेट भेजना।
यह वह पैकेट है जो macOS से दिखता है (लगातार 1514)
"TCP","1514","[TCP segment of a reassembled PDU]"
"TCP","66","445 > 56932 [ACK] Seq=6603 Ack=35239 Win=4505 Len=0 TSval=520980697 TSecr=650208630"
और यह विंडोज से आ रहा है (26334 तक, आकार में भिन्न)
"SMB2","1466","Write Request Len:65536 Off:196608 File: test.file"
"TCP","26334","[TCP segment of a reassembled PDU]"
"TCP","7354","[TCP segment of a reassembled PDU]"
"TCP","54","445 > 49220 [ACK] Seq=6831 Ack=267030 Win=4074 Len=0"
आप यहां (25.2 MB) पूर्ण .csv डाउनलोड कर सकते हैं , फ़ाइल नाम बताते हैं कि क्या कॉपी किया गया है (OS, स्थानांतरण विधि और फ़ाइल का आकार)।