SMB नेटवर्क पर छोटे से लिखता है विंडोज पर धीमी गति से, CIFS लिनक्स माउंट पर तेजी से


10

जब मैं छोटे लेखन करता हूं तो SMB / CIFS शेयर के साथ एक प्रदर्शन समस्या को ठीक करने के लिए संघर्ष कर रहा हूं।

पहले, मुझे अपने वर्तमान नेटवर्क सेटअप का वर्णन करने दें:

सर्वर

  • Synology DS215j (SMB3 समर्थन सक्षम के साथ)

ग्राहक (एक ही कंप्यूटर ड्यूल-बूटेड वायर्ड गिग-ई)

  • Ubuntu 14.04.5 LTS, भरोसेमंद तहर
  • विंडोज 8.1

smb.conf

[global]
    printcap name=cups
    winbind enum groups=yes
    include=/var/tmp/nginx/smb.netbios.aliases.conf
    socket options=TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
    security=user
    local master=no
    realm=*
    passdb backend=smbpasswd
    printing=cups
    max protocol=SMB3
    winbind enum users=yes
    load printers=yes
    workgroup=WORKGROUP

मैं वर्तमान में (GitHub पर सी ++ में लिखा निम्नलिखित कार्यक्रम के साथ छोटे लिखने प्रदर्शन का परीक्षण कर रहा हूँ यहाँ ):

#include <iostream>
#include <fstream>
#include <sstream>

using namespace std;

int main(int argc, char* argv[])
{
    ofstream outFile(argv[1]);
    for(int i = 0; i < 1000000; i++)
    {
        outFile << "Line #" << i << endl;   
    }

    outFile.flush();
    outFile.close();
    return 0;
}

लिनक्स माउंट कॉन्फ़िगरेशन:

//192.168.1.10/nas-main on /mnt/nas-main type cifs (rw,noexec,nodev)

लिनक्स पर प्रोग्राम रन-टाइम (~ 100Mbps पर पीक नेटवर्क आउटपुट):

$ time ./nas-write-test /mnt/nas-main/home/will/test.txt

real    0m0.965s
user    0m0.148s
sys 0m0.672s

PCAP स्नैपशॉट एक ही टीसीपी पैकेट में कई लाइनों का हिस्सा दिखा रहा है:

लिनक्स PCAP स्नैपशॉट

PowerShell द्वारा मापे गए विंडोज पर प्रोग्राम रन-टाइम:

> Measure-Command {start-process .\nas-write-test.exe -argumentlist "Z:\home\will\test-win.txt" -wait}


Days              : 0
Hours             : 0
Minutes           : 9
Seconds           : 29
Milliseconds      : 316
Ticks             : 5693166949
TotalDays         : 0.00658931359837963
TotalHours        : 0.158143526361111
TotalMinutes      : 9.48861158166667
TotalSeconds      : 569.3166949
TotalMilliseconds : 569316.6949

Windows पर PCAP स्नैपशॉट प्रति SMB लिखें अनुरोध के लिए एकल पंक्ति दिखा रहा है:

Windows PCAP स्नैपशॉट

यह वही कार्यक्रम विंडोज पर लगभग 10 मिनट (~ 2.3Mbps) लेता है। जाहिर है, विंडोज पीसीएपी बहुत कम पेलोड दक्षता के साथ शोर शोर एसएमबी वार्तालाप को दर्शाता है।

क्या विंडोज पर कोई सेटिंग्स हैं जो छोटे लेखन प्रदर्शन में सुधार कर सकती हैं? पैकेट कैप्चर को देखने से लगता है कि विंडोज राइट को सही तरीके से बफर नहीं करता है और तुरंत एक बार में डेटा को एक लाइन में भेज देता है। जबकि, लिनक्स पर, डेटा भारी होता है और इस प्रकार उसका बेहतर प्रदर्शन होता है। मुझे बताएं कि क्या PCAP फाइलें मददगार होंगी, और मैं उन्हें अपलोड करने का कोई तरीका खोज सकता हूं।

अपडेट 10/27/16:

जैसा कि @sehafoc ने उल्लेख किया है, मैंने max protocolSMB1 की सेटिंग Samba को निम्न के साथ कम कर दिया है :

max protocol=NT1

उपरोक्त सेटिंग के परिणामस्वरूप सटीक व्यवहार हुआ।

मैंने एक अन्य विंडोज 10 मशीन पर एक हिस्सा बनाकर सांबा के चर को भी हटा दिया, और यह सांबा सर्वर के समान व्यवहार भी प्रदर्शित करता है, इसलिए मुझे विश्वास है कि यह सामान्य रूप से विंडोज क्लाइंट के साथ राइट कैशिंग बग है।

अपडेट: 10/06/17:

पूर्ण लिनक्स पैकेट कैप्चर (14MB)

पूर्ण Windows पैकेट कैप्चर (375MB)

अपडेट: 10/12/17:

मैंने एक NFS शेयर भी सेटअप किया है और विंडोज इसके लिए कोई बफरिंग भी नहीं लिखता है। इसलिए, यह निश्चित रूप से एक अंतर्निहित विंडोज क्लाइंट मुद्दा है जहां तक ​​मैं बता सकता हूं, जो निश्चित रूप से दुर्भाग्यपूर्ण है: - / /

किसी भी सहायता की सराहना की जाएगी!

जवाबों:


2

C ++ एंडल को आउटपुट '\ n' से परिभाषित किया जाता है और उसके बाद फ्लश होता है। फ्लश () एक महंगा ऑपरेशन है, इसलिए आपको आम तौर पर लाइन के अपने डिफ़ॉल्ट छोर के रूप में एंडल का उपयोग करने से बचना चाहिए क्योंकि यह बिल्कुल वही प्रदर्शन मुद्दा बना सकता है जिसे आप देख रहे हैं (और केवल एसएमबी के साथ नहीं, बल्कि स्थानीय कताई सहित महंगे फ्लश के साथ किसी भी बहाव के साथ। जंग या यहां तक ​​कि उत्पादन के कुछ हास्यास्पद उच्च दर पर नवीनतम एनवीएमई)।

एंडल की जगह "\ n" के साथ सिस्टम ऊपर बफर को अनुमति देकर प्रदर्शन को ठीक करेगा। कुछ पुस्तकालयों को छोड़कर "\ n" पर फ्लश हो सकता है, जिस स्थिति में आपके सिर में अधिक दर्द होता है (देखें सिंक () विधि से आगे निकलने वाले समाधान के लिए /programming/21129162/tell-endl-not-to-flush )।

अब चीजों को जटिल करने के लिए, फ्लश () केवल लाइब्रेरी बफ़र्स के भीतर क्या होता है के लिए परिभाषित किया गया है। ऑपरेटिंग सिस्टम, डिस्क और अन्य बाहरी बफ़र्स पर फ्लश का प्रभाव परिभाषित नहीं किया गया है। Microsoft.NET के लिए "जब आप FileStream.Flush विधि को कॉल करते हैं, तो ऑपरेटिंग सिस्टम I / O बफर भी फ्लश हो जाता है।" ( https://msdn.microsoft.com/en-us/library/2bw4h516(v=vs.110).aspx ) यह विजुअल स्टूडियो C ++ के लिए विशेष रूप से महंगा फ्लश करता है क्योंकि यह राउंड-ट्रिप को लिखने के सभी तरह से बाहर कर देगा। आप देख रहे हैं के रूप में अपने दूरस्थ सर्वर के दूर अंत में भौतिक मीडिया। दूसरी ओर जीसीसी का कहना है "एक अंतिम अनुस्मारक: आमतौर पर भाषा / पुस्तकालय स्तर पर उन लोगों की तुलना में अधिक बफ़र शामिल होते हैं। कर्नेल बफ़र्स, डिस्क बफ़र्स, और इस तरह का भी प्रभाव पड़ेगा। सिस्टम पर निर्भर होने का निरीक्षण करना और बदलना। । "https://gcc.gnu.org/onbuildocs/libstdc++/manual/streambufs.html ) आपके उबंटू निशान से प्रतीत होता है कि ऑपरेटिंग सिस्टम / नेटवर्क बफ़र्स लाइब्रेरी फ्लश () द्वारा फ्लश नहीं किए गए हैं। सिस्टम डिपेंडेंट बिहेवियर एंडल से बचने और जरूरत से ज्यादा फ्लशिंग करने के लिए और अधिक कारण होगा। यदि आप VC ++ का उपयोग कर रहे हैं, तो आप यह देखने के लिए विंडोज जीसीसी व्युत्पन्न पर स्विच करने का प्रयास कर सकते हैं कि सिस्टम निर्भर व्यवहार कैसे प्रतिक्रिया करते हैं, या वैकल्पिक रूप से उबंटू पर विंडोज निष्पादन योग्य चलाने के लिए वाइन का उपयोग कर रहे हैं।

अधिक आम तौर पर आपको यह निर्धारित करने के लिए अपनी आवश्यकताओं के बारे में सोचने की ज़रूरत है कि क्या प्रत्येक पंक्ति फ्लशिंग उचित है या नहीं। एंडल आम तौर पर इंटरेक्टिव स्ट्रीम जैसे कि डिस्प्ले के लिए उपयुक्त है (हमें उपयोगकर्ता को वास्तव में हमारे आउटपुट को देखने की जरूरत है, और फट में नहीं), लेकिन आम तौर पर फाइलों सहित अन्य प्रकार की धाराओं के लिए उपयुक्त नहीं है जहां फ्लशिंग ओवरहेड महत्वपूर्ण हो सकता है। मैंने हर 1 और 2 और 4 को ऐप फ्लश देखा है और 8 बाइट लिखता है ... 1MB फ़ाइल लिखने के लिए OS के लाखों IO को देखने के लिए यह सुंदर नहीं है।

एक उदाहरण के रूप में एक लॉग फ़ाइल को हर लाइन को फ्लशिंग करने की आवश्यकता हो सकती है यदि आप क्रैश को डिबग कर रहे हैं क्योंकि क्रैश होने से पहले आपको नदी के ऊपर फ्लश करने की आवश्यकता होती है; हालांकि एक अन्य लॉग फ़ाइल को हर लाइन को फ्लशिंग करने की आवश्यकता नहीं हो सकती है यदि यह सिर्फ वर्बोज़ सूचनात्मक लॉगिंग का उत्पादन कर रहा है जो कि एप्लिकेशन समाप्त होने से पहले स्वचालित रूप से फ्लश होने की उम्मीद है। इसकी आवश्यकता नहीं है / या जैसा कि आप विशिष्ट आवश्यकताओं के अनुरूप एक अधिक परिष्कृत फ्लश एल्गोरिथ्म के साथ एक वर्ग प्राप्त कर सकते हैं।

अपने मामले की तुलना ऐसे लोगों से करें, जिन्हें यह सुनिश्चित करने की जरूरत है कि उनका डेटा पूरी तरह से डिस्क पर टिका हुआ है और ऑपरेटिंग सिस्टम बफर में कमजोर नहीं है ( /programming/7522479/how-do-i-ensure-data -is-लिखा-से-डिस्क-पहले-समापन-फ़्लोस्ट )।

ध्यान दें कि जैसा कि लिखा गया है, आउटफिल.फ्लश () पहले से ही फ्लश किए गए फ्लश को फ्लश करता है। पांडित्यपूर्ण होने के लिए, आपको अकेले या अधिमानतः \ n "" आउटफाइल.फ्लश () के साथ उपयोग करना चाहिए था, लेकिन दोनों नहीं।


बहुत - बहुत धन्यवाद! आप 100 से अधिक अंकों के लायक हैं, लेकिन यह सब मैं दे सकता हूं :) यह निश्चित रूप से समस्या थी!
मेवाट्रॉन

2

मेरे पास एक टिप्पणी छोड़ने के लिए पर्याप्त प्रतिष्ठा नहीं है (जो मुझे लगता है कि बेहतर होगा कि इस उत्तर पर सत्यापन का स्तर दिया जाए)।

मुझे लगता है कि आपके लिनक्स बनाम विंडोज स्तर के ट्रेस में एक बड़ा परिवर्तन यह है कि आप लिनक्स पर एसएमबी 1 और विंडोज में एसएमबी 2 का उपयोग कर रहे हैं। शायद SMB2 अनन्य पट्टा कार्यान्वयन की तुलना में SMB1 सांबा में बैच ऑपलॉक तंत्र बेहतर प्रदर्शन करता है। दोनों ही मामलों में इन्हें क्लाइंट साइड कैशिंग की कुछ राशि के लिए अनुमति देनी चाहिए।

1) शायद SMB1 के साथ खिड़कियों की कोशिश करने के लिए सांबा में एक कम से कम अधिकतम प्रोटोकॉल स्तर स्थापित करने की कोशिश करें) यह सत्यापित करें कि अनन्य ऑप्लक्स या पट्टे बाहर निकाले गए हैं

उम्मीद है की यह मदद करेगा :)


2

दूरस्थ फ़ाइल संचालन का प्रदर्शन, जैसे कि पढ़ना / लिखना, एसएमबी प्रोटोकॉल का उपयोग करना सर्वर और क्लाइंट द्वारा आवंटित बफ़र्स के आकार से प्रभावित हो सकता है। बफर आकार निश्चित डेटा भेजने के लिए आवश्यक गोल यात्राओं की संख्या निर्धारित करता है। हर बार जब क्लाइंट और सर्वर के बीच अनुरोध और प्रतिक्रियाएं भेजी जाती हैं, तो लिया गया समय दोनों पक्षों के बीच कम से कम विलंबता के बराबर होता है, जो वाइड एरिया नेटवर्क (WAN) के मामले में बहुत महत्वपूर्ण हो सकता है।

SMB बफ़र - MaxBufferSize को निम्न रजिस्ट्री सेटिंग के माध्यम से कॉन्फ़िगर किया जा सकता है:

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\SizeReqBuf

डाटा प्रकार: REG_DWORD

रेंज: 1024 से 65535 (5000 से ऊपर अपनी आवश्यकता के अनुसार मूल्य चुनें)

लेकिन SMB साइनिंग प्रभाव अधिकतम बफर आकार की अनुमति देता है। इस प्रकार हमें अपने लक्ष्य को हासिल करने के लिए एसएमबी साइनिंग को अक्षम करना होगा। निम्नलिखित रजिस्ट्री दोनों सर्वर साइड पर बनाया जाना चाहिए और यदि संभव हो तो क्लाइंट साइड पर भी।

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters

मान का नाम: EnableSecuritySignature

डाटा प्रकार: REG_DWORD

डेटा: 0 (अक्षम), 1 (सक्षम)


पारितोषिक के लिए धन्यवाद; हालाँकि, मैंने इन दोनों उपायों की कोशिश की और मैं अभी भी उपरोक्त व्यवहार देख रहा हूँ: - /
mevatron

आप यह भी जाँचना पसंद करते हैं कि "Synology DS215j" SMB3 का उपयोग क्यों नहीं कर रहा है। डिफ़ॉल्ट रूप से SMB3 Win 8.1 पर सक्षम है।
आदि झा

1

दिलचस्प घटना। यहाँ मैं क्या कोशिश करूँगा - मुझे कोई पता नहीं है अगर यह वास्तव में मदद करता है। अगर यह मेरी मशीन होती, तो मैं बड़े पैमाने पर एसएमबी परफैक्टर्स को देखता। उनमें से एक होगा कारण दिखाई देते हैं।

कोशिश करने के लिए और चीजें

अधिक कार्यकर्ता सूत्र जोड़ें

यदि SMB_RDR एक पंक्ति I / O अनुरोध प्रति पंक्ति (यहां क्या नहीं होना चाहिए ) लिखता है , तो इससे निष्पादन इंजन में कुछ सूत्र जोड़ने में मदद मिल सकती है

"अतिरिक्त क्रिटिकलवॉकर थ्रेड्स" को 2 पर सेट करें, फिर 4 पर।

HKLM\System\CurrentControlSet\Control\Session Manager\Executive\AdditionalCriticalWorkerThreads

डिफ़ॉल्ट 0 है, जिसका अर्थ है कि कोई अतिरिक्त महत्वपूर्ण कर्नेल कार्यकर्ता थ्रेड्स नहीं जोड़े गए हैं। जो सामान्य रूप से ठीक है। यह मान उन थ्रेड की संख्या को प्रभावित करता है जो फ़ाइल सिस्टम कैश रीड-फॉरवर्ड और राइट-बैक अनुरोधों के लिए उपयोग करता है। इस मूल्य को बढ़ाकर स्टोरेज सबसिस्टम (जो अच्छा है, जब आप लाइन-बाय-लाइन लिखना चाहते हैं) में अधिक कतारबद्ध I / O के लिए अनुमति दे सकते हैं , लेकिन यह अधिक CPU महंगा है।

अधिक कतार लंबाई जोड़ें

"अतिरिक्त क्रिटिकलवॉर्कर थ्रेड्स" मूल्य में वृद्धि से उन थ्रेड्स की संख्या बढ़ जाती है जो फ़ाइल सर्वर समवर्ती अनुरोधों की सेवा के लिए उपयोग कर सकते हैं ।

HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\MaxThreadsPerQueue

डिफ़ॉल्ट 20 है। एक संकेत है कि मान को बढ़ाने की आवश्यकता हो सकती है यदि SMB2 कार्य कतार बहुत बड़ी हो रही है (perfcounter 'सर्वर कार्य कतार \ कतार लंबाई \ SMB2 *' होना चाहिए <100)।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.