এসএমবি নেটওয়ার্ক শেয়ারে ছোট লেখাগুলি সিআইএফএস লিনাক্স মাউন্টের ওপরে দ্রুত উইন্ডোজে ধীর হয়


10

ছোট লেখাগুলি সম্পাদন করার সময় আমি একটি এসএমবি / সিআইএফএস শেয়ারের সাথে একটি পারফরম্যান্স সমস্যা সমাধানের জন্য সংগ্রাম করছি।

প্রথমে আমাকে আমার বর্তমান নেটওয়ার্ক সেটআপটি বর্ণনা করতে দিন:

সার্ভার

  • Synology DS215j (এসএমবি 3 সমর্থন সক্ষম সহ)

ক্লায়েন্ট (একই কম্পিউটারের দ্বৈত বুটযুক্ত তারযুক্ত গিগ-ই)

  • উবুন্টু 14.04.5 এলটিএস, ট্রাস্টি তাহর
  • উইন্ডোজ 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

আমি বর্তমানে সি ++ তে লিখিত নিম্নলিখিত প্রোগ্রামটির সাথে ছোট লেখার পারফরম্যান্সটি পরীক্ষা করছি ( এখানে গিটহাবের উপর ):

#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)

লিনাক্সে প্রোগ্রাম রানটাইম (~ 100 এমবিপিএসে নেটওয়ার্ক আউটপুট পিক করে):

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

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

পিসিএপি স্ন্যাপশট একক টিসিপি প্যাকেটে অনেকগুলি লাইন ছাঁটাই করে দেখায়:

লিনাক্স পিসিএপি স্ন্যাপশট

উইন্ডোজে পাওয়ারশেলের দ্বারা পরিমাপকৃত প্রোগ্রাম রানটাইম:

> 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

উইন্ডোজটিতে পিসিএপি স্ন্যাপশট প্রতি এসএমবিতে একক লাইন দেখায় অনুরোধ লিখুন:

উইন্ডোজ পিসিএপি স্ন্যাপশট

এই একই প্রোগ্রামটি উইন্ডোজে প্রায় 10 মিনিট (~ 2.3Mbps) নেয় takes স্পষ্টতই, উইন্ডোজ পিসিএপি খুব কম পে-লোড দক্ষতার সাথে খুব শোরগোলের এসএমবি কথোপকথন দেখায়।

উইন্ডোজে এমন কোনও সেটিংস রয়েছে যা ছোট লেখার পারফরম্যান্সকে উন্নত করতে পারে? প্যাকেট ক্যাপচারগুলি দেখে মনে হয় উইন্ডোজ সঠিকভাবে লেখাগুলি বাফার করে না এবং সঙ্গে সঙ্গে একবারে ডেটা এক লাইনে প্রেরণ করে। যদিও লিনাক্সে, ডেটাগুলি ভারীভাবে বাফার করা হয় এবং এর ফলে আরও উচ্চতর পারফরম্যান্স রয়েছে। পিসিএপি ফাইলগুলি সহায়ক হবে কিনা তা আমাকে জানিয়ে দিন এবং আমি সেগুলি আপলোড করার উপায় খুঁজে পেতে পারি।

আপডেট 10/27/16:

@ শেফোক দ্বারা উল্লিখিত হিসাবে, আমি max protocolনিম্নলিখিতটি দিয়ে এসএমবি 1 এ সাম্বা সার্ভার সেটিংকে কমিয়েছি:

max protocol=NT1

উপরের সেটিংটির ফলে ঠিক একই আচরণ হয়েছে।

আমি অন্য উইন্ডোজ 10 মেশিনে একটি অংশ তৈরি করে সাম্বার পরিবর্তনশীলটিও সরিয়েছি এবং এটি সাম্বা সার্ভারের মতোই আচরণটি প্রদর্শন করে, তাই আমি বিশ্বাস করতে শুরু করি যে এটি সাধারণভাবে উইন্ডোজ ক্লায়েন্টদের সাথে একটি লেখার ক্যাচিং বাগ।

আপডেট: 10/06/17:

সম্পূর্ণ লিনাক্স প্যাকেট ক্যাপচার (14MB)

সম্পূর্ণ উইন্ডোজ প্যাকেট ক্যাপচার (375 এমবি)

আপডেট: 10/12/17:

আমি একটি এনএফএস শেয়ার সেটআপও করি এবং উইন্ডোজও এর জন্য কোনও বাফারিংয়ের সাথে লিখেনি। সুতরাং, আমি অবশ্যই যতদূর বলতে পারি এটি অবশ্যই অন্তর্নিহিত উইন্ডোজ ক্লায়েন্টের সমস্যা, যা অবশ্যই দুর্ভাগ্যজনক: - /

কোন সাহায্য প্রশংসা হবে!

উত্তর:


2

সি ++ এন্ডেল আউটপুট '\ n' এর পরে সংশ্লেষিত হয় এবং তারপরে ফ্লাশ হয়। ফ্লাশ () একটি ব্যয়বহুল ক্রিয়াকলাপ, সুতরাং আপনার সাধারণত লাইনের আপনার ডিফল্ট প্রান্ত হিসাবে আন্ডল ব্যবহার করা এড়ানো উচিত কারণ এটি আপনি যে পারফরম্যান্সের সমস্যাটি দেখছেন ঠিক তা তৈরি করতে পারে (এবং কেবল এসএমবি দিয়ে নয়, স্থানীয় স্পিনিং সহ ব্যয়বহুল ফ্লাশ সহ যে কোনও প্রবাহের সাথে) with মরিচা বা এমনকি সর্বনিম্ন NVMe আউটপুট কিছু হাস্যকরভাবে উচ্চ হারে)।

"\ N" এর সাথে আন্ডল প্রতিস্থাপনের ফলে সিস্টেমটিকে বাফার করার উদ্দেশ্যে উপরের পারফরম্যান্সটি ঠিক করা হবে। কিছু লাইব্রেরি বাদ দিয়ে "\ n" এ ফ্লাশ করতে পারে, সেক্ষেত্রে সিঙ্ক () পদ্ধতির ওভাররাইডিং সমাধানের জন্য আপনার আরও মাথাব্যথা রয়েছে ( /programming/21129162/tell-endl-not-to-flush দেখুন ) )।

এখন জিনিসগুলিকে জটিল করার জন্য, ফ্লাশ () কেবল গ্রন্থাগারের বাফারগুলির মধ্যে যা ঘটে তার জন্যই সংজ্ঞায়িত করা হয়। অপারেটিং সিস্টেম, ডিস্ক এবং অন্যান্য বহিরাগত বাফারগুলিতে ফ্লাশের প্রভাব সংজ্ঞায়িত হয় না। মাইক্রোসফট.নাইটের জন্য "আপনি যখন ফাইল স্ট্রিমটি কল করেন। ( https://msdn.microsoft.com/en-us/library/2bw4h516(v=vs.110).aspx ) এটি ভিজুয়াল স্টুডিও সি ++ এর জন্য বিশেষত ব্যয়বহুল করে তোলে কারণ এটি লেখার সমস্ত দিক থেকে রাউন্ড ট্রিপ করবে write আপনার রিমোট সার্ভারের প্রান্তে দৈহিক মিডিয়া যেমন আপনি দেখছেন। অন্যদিকে জিসিসি বলেছে "একটি সর্বশেষ অনুস্মারক: সাধারণত ভাষা / গ্রন্থাগার স্তরের তুলনায় আরও বেশি বাফার জড়িত থাকে Ker কার্নেল বাফার, ডিস্ক বাফার এবং এর মতোগুলিও প্রভাব ফেলবে those এগুলি পরীক্ষা-নিরীক্ষা ও পরিবর্তন সিস্টেম-নির্ভর । "https://gcc.gnu.org/onlinesocs/libstdc++/manual/streambufs.html ) আপনার উবুন্টু ট্রেসগুলি ইঙ্গিত দেয় যে অপারেটিং সিস্টেম / নেটওয়ার্ক বাফারগুলি লাইব্রেরির ফ্লাশ () দ্বারা ফ্লাশ করা হয়নি। সিস্টেম নির্ভর আচরণ হ'ল এন্ডেল এবং অতিরিক্তভাবে ফ্লাশিং এড়ানোর আরও বেশি কারণ। আপনি যদি ভিসি ++ ব্যবহার করে থাকেন তবে সিস্টেম নির্ভরশীল আচরণগুলি কীভাবে প্রতিক্রিয়া দেখায় বা বিকল্পভাবে উইবিনকে উবুন্টুতে এক্সিকিউটেবল চালানোর জন্য ওয়াইন ব্যবহার করে তা দেখতে আপনি কোনও উইন্ডোজ জিসিসি ডেরিভেটিভে স্যুইচ করার চেষ্টা করতে পারেন।

প্রতিটি লাইনে ফ্লাশ করা উপযুক্ত কিনা তা নির্ধারণ করার জন্য আপনাকে সাধারণত আপনার প্রয়োজনীয়তাগুলি নিয়ে ভাবতে হবে। এন্ডেল সাধারণত ইন্টারেক্টিভ স্ট্রিম যেমন ডিসপ্লে (যেমন আমাদের আমাদের আউটপুট দেখতে বার্স্ট দেখতে প্রয়োজন) এর জন্য সাধারণত উপযুক্ত তবে এটি ফাইল সহ অন্যান্য ধরণের স্ট্রিমের জন্য সাধারণত উপযুক্ত নয় যেখানে ফ্লাশিং ওভারহেড উল্লেখযোগ্য হতে পারে। আমি প্রতি 1 এবং 2 এবং 4 এবং 8 বাইট রাইটে অ্যাপ্লিকেশন ফ্লাশ দেখেছি ... ওএস 1MB ফাইল লিখতে কয়েক মিলিয়ন আইও পিষে দেখলে অবাক হয় না।

উদাহরণস্বরূপ একটি লগ ফাইলের প্রতিটি লাইন ফ্লাশ করার প্রয়োজন হতে পারে যদি আপনি ক্র্যাশ ডিবাগ করছেন তবে ক্র্যাশ হওয়ার আগে আপনার প্রবাহকে ফ্লাশ করতে হবে; যখন অন্য লগ ফাইলের জন্য প্রতিটি লাইন ফ্লাশ করার প্রয়োজন না পড়তে পারে যদি এটি কেবল ভার্জোজ তথ্য সংক্রান্ত লগিং তৈরি করে যা অ্যাপ্লিকেশনটি শেষ হওয়ার আগে স্বয়ংক্রিয়ভাবে ফ্লাশ হওয়ার আশা করা হয়। এটি প্রয়োজন হয় না / বা হিসাবে আপনি নির্দিষ্ট প্রয়োজনীয়তা অনুসারে আরও পরিশীলিত ফ্লাশ অ্যালগরিদম সহ একটি শ্রেণি অর্জন করতে পারেন।

আপনার কেসটি তাদের বিপরীত মামলার সাথে তুলনা করুন যাঁরা তাদের ডেটা সম্পূর্ণরূপে ডিস্কের কাছে স্থির রাখতে এবং কোনও অপারেটিং সিস্টেম বাফারে ঝুঁকিপূর্ণ নয় তা নিশ্চিত করতে হয় ( /programming/7522479/how-do-i-ensure-data -আইস-লিখিত-থেকে-ডিস্ক-আগে-ক্লোজিং-এফস্ট্রি )।

মনে রাখবেন যে লিখিত হিসাবে, আউটফিল.ফ্লুশ () অতিমাত্রায় প্রবাহিত হওয়ায় এটি ইতিমধ্যে প্রবাহিত প্রবাহকে প্রবাহিত করে। পেডেন্টিক হতে, আপনার আউটল একা বা পছন্দসই "\ n" আউটফিল.ফ্লুশ () দিয়ে ব্যবহার করা উচিত ছিল তবে দুটি নয়।


অসংখ্য ধন্যবাদ! আপনি 100 টিরও বেশি পয়েন্টের জন্য প্রাপ্য, তবে আমি এটিই দিতে পারি :) এটি অবশ্যই সমস্যা ছিল!
মেভাট্রন

2

আমার কোনও মন্তব্য দেওয়ার মতো যথেষ্ট খ্যাতি নেই (যা আমি মনে করি যে এই উত্তরের যাচাইয়ের স্তরটি দিয়ে আরও ভাল দেওয়া হবে)।

আমি লক্ষ্য করেছি যে আপনার লিনাক্স বনাম উইন্ডোজ স্তরের ট্রেসগুলির একটি বড় প্রকারভেদ হ'ল আপনি লিনাক্সে এসএমবি 1 এবং উইন্ডোজের এসএমবি 2 ব্যবহার করছেন। সম্ভবত ব্যাচ ওপলক প্রক্রিয়াটি এসএমবি 2 সাম্বায় এসএমবি 2 এক্সক্লুসিভ ইজারা বাস্তবায়নের চেয়ে আরও ভাল পারফর্ম করে। উভয় ক্ষেত্রে এগুলিকে ক্লায়েন্ট সাইড ক্যাচিংয়ের কিছু পরিমাণের জন্য অনুমতি দেওয়া উচিত।

1) সম্ভবত এসএমবি 1 দিয়ে উইন্ডোজ চেষ্টা করার জন্য সাম্বায় একটি নিম্নতম প্রোটোকল স্তর নির্ধারণের চেষ্টা করুন 2) একচেটিয়া অপলক বা লিজ নেওয়া হয়েছে তা যাচাই করুন

আশাকরি এটা সাহায্য করবে :)


2

এসএমবি প্রোটোকল ব্যবহার করে রিড / রাইটিংয়ের মতো রিমোট ফাইল অপারেশনের কর্মক্ষমতা সার্ভার এবং ক্লায়েন্টদের দ্বারা বরাদ্দ করা বাফার আকার দ্বারা প্রভাবিত হতে পারে। বাফারের আকার নির্দিষ্ট পরিমাণের ডেটা প্রেরণের জন্য প্রয়োজনীয় রাউন্ড ট্রিপের সংখ্যা নির্ধারণ করে। প্রতিবার যখন ক্লায়েন্ট এবং সার্ভারের মধ্যে অনুরোধ এবং প্রতিক্রিয়াগুলি প্রেরণ করা হয় তখন সময় নেওয়া পরিমাণ উভয় পক্ষের মধ্যে কমপক্ষে বিলম্বের সমান, যা ওয়াইড এরিয়া নেটওয়ার্ক (ডাব্লুএএন) এর ক্ষেত্রে খুব গুরুত্বপূর্ণ হতে পারে।

এসএমবি বাফার - ম্যাক্সবফারসাইজটি নিম্নলিখিত রেজিস্ট্রি সেটিংয়ের মাধ্যমে কনফিগার করা যেতে পারে:

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

তথ্য প্রকার: REG_DWORD

ব্যাপ্তি: 1024 থেকে 65535 (5000 এর উপরে আপনার প্রয়োজন অনুসারে মান চয়ন করুন)

তবে এসএমবি সাইন ইন করার ফলে সর্বাধিক বাফার আকার অনুমোদিত। সুতরাং আমাদের লক্ষ্য অর্জনের জন্য আমাদের এসএমবি সাইন ইন করতে অক্ষম করতে হবে। নিম্নলিখিত রেজিস্ট্রি উভয় সার্ভার সাইডে তৈরি করা প্রয়োজন এবং ক্লায়েন্ট সাইডেও সম্ভব হলে।

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters

মান নাম: EnableSecuritySignature

তথ্য প্রকার: REG_DWORD

ডেটা: 0 (অক্ষম), 1 (সক্ষম)


ভকভগক; যাইহোক, আমি এই উভয় প্রতিকারের চেষ্টা করেছি এবং আমি এখনও উপরের আচরণটি দেখছি: - /
মেভাট্রন

আপনি "সিএনোলজি ডিএস 215j" এসএমবি 3 ব্যবহার করছেন না তাও পরীক্ষা করতে চান ma ডিফল্টরূপে এসএমবি 3 উইন 8.1 তে সক্ষম হয়।
আদি ঝা

1

আকর্ষণীয় ঘটনা। আমি যা চেষ্টা করব তা এখানে - এটি সত্যিই সহায়তা করে কিনা আমার কোনও ধারণা নেই। এটি যদি আমার মেশিন হয় তবে আমি এসএমবি পারফেক্ট কাউন্টারগুলিকে ব্যাপকভাবে দেখতাম। তাদের মধ্যে একজন হবে কারণ প্রদর্শন করুন।

আরও কিছু চেষ্টা করার দরকার

আরও কর্মী থ্রেড যুক্ত করুন

এসএমবি_আরডিআর প্রতি লাইনে I / O রিকোয়েস্ট লিখতে বাধ্য করে ( এখানে কী হওয়া উচিত নয় ), এটি এক্সিকিউশন ইঞ্জিনে কিছু থ্রেড যুক্ত করতে সহায়তা করতে পারে।

"অতিরিক্ত ক্রিটিক্যাল ওয়ার্কার থ্রেডস" 2 এ সেট করুন, তারপরে 4 এ।

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

ডিফল্টটি 0 হয়, যার অর্থ অতিরিক্ত তাত্পর্যপূর্ণ কার্নেল কর্মী থ্রেড যুক্ত করা হয় না। যা স্বাভাবিকভাবেই ঠিক আছে। এই মানটি ফাইল সিস্টেম ক্যাশে রিড-ফরোয়ার এবং রাইট-পিছনের অনুরোধগুলির জন্য ব্যবহার করে এমন থ্রেডের সংখ্যাকে প্রভাবিত করে। এই মানটি বাড়ানো স্টোরেজ সাবসিস্টেমের আরও সারি আই / ও-র জন্য অনুমতি দিতে পারে (যা ভাল, যখন আপনি লাইন-লাইন লিখতে চান), তবে এটি সিপিইউ ব্যয়বহুল।

আরও সারি দৈর্ঘ্য যুক্ত করুন

"অতিরিক্ত ক্রিটিক্যাল ওয়ার্কারথ্রেডস" মান বৃদ্ধি করা ফাইল সার্ভারের সমবর্তী অনুরোধগুলিতে পরিষেবা ব্যবহার করতে পারে এমন থ্রেডের সংখ্যা বাড়িয়েছে ।

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

ডিফল্টটি 20 হয়।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.