এসএমবি 3 ড্রাইভে কেন ডিডি, সিপি, আরএসএনসি এবং ম্যাকস ফাইন্ডারের মধ্যে লেখার গতির পার্থক্য রয়েছে?


15

টিএল; ডাঃ - এসএমবি এবং এএফপি-র মাধ্যমে দুটি ভিন্ন ম্যাক ক্লায়েন্টের মাধ্যমে আমাদের এনএএস-তে 60 এমবি / সেকেন্ডের সীমিত লেখার গতির কারণ আমরা খুঁজে পাই না। তুলনায় তুলনা করুন: একই নেটওয়ার্কের একটি পুরানো উইন্ডোজ 7 ল্যাপটপ স্থির 100 এমবি / সেকেন্ড লিখেছে।

আপনি যদি প্রথমবার এই প্রশ্নটি পড়ে থাকেন তবে দয়া করে আপডেট 4 বিভাগে যান। rsyncআমরা কেন বুঝতে পারি না তা স্বল্প গতির মূল কারণ, (একক ফাইলের জন্য!)।


আসল প্রশ্ন: ম্যাক ওএস 10.11.5 এবং তারপরে গতি বাধা এসএমবি 3 / এনএএস সন্ধান করুন

আমরা rsync --progress -a /localpath/test.file /nas/test.fileম্যাকোএস এবং উইন্ডোজের অনুলিপি মাধ্যমে পরীক্ষা করেছি ।

এনএএস হ'ল একটি ডিএস 13১ + + তাদের বর্তমান ডিএসএম running.০.২ চালিয়েছে (5..০ এর সাথে পরীক্ষিতও), কেবল দুটি গিগাবিট ইথারনেট উপাদান এবং নূন্যতম ইথারনেট কেবলগুলি (কমপক্ষে Cat5e) সহ RAID1 এ দুটি এইচজিএসটি ডেস্কস্টার নাস SATA 4TB (HDN724040ALE640) রয়েছে with

ম্যাক ক্লায়েন্টরা প্রথমে কেবল 20 এমবি / সেকেন্ড তৈরি করে। তবে স্থির প্রয়োগ signing_required=no( এখানে বর্ণিত ) এসএমবি 2 এবং এসএমবি 3 এর মাধ্যমে লেখার গতি 60 এমবি / সেকেন্ডে চাপিয়ে দিয়েছে। এএফপি প্রায় 60 এমবি / সেকেন্ড সরবরাহ করে। প্রোটোকল এবং (ম্যাক) ক্লায়েন্টের উপর নির্ভর করে ফলাফল প্রায় 5 এমবি / সেকেন্ডে পরিবর্তিত হয়।

আমরা ইতিমধ্যে যা চেষ্টা করেছি:

অন্তর্জাল

  1. Iperf3 এর মাধ্যমে নেটওয়ার্কের পারফরম্যান্স পরীক্ষিত। ফলাফল: 926 Mbit / s। ভাল লাগছে।
  2. দ্বৈত লিঙ্ক একত্রিতকরণ / বন্ডেড নেটওয়ার্ক ইন্টারফেসের চেষ্টা করা। পরিবর্তন নেই.
  3. এমটিইউ 6000 এবং 9000 বৃদ্ধি পেয়েছে No
  4. সমস্ত তারগুলি পরীক্ষা করা হয়েছে। কমপক্ষে Cat5e, ভাল অবস্থায় সব ঠিক আছে।

ডিস্ক

  1. চেক করা স্মার্ট স্বাস্থ্যকর দেখাচ্ছে।
  2. dd if=/dev/zero of=write.test bs=256M count=4বিভিন্ন bsএবং countসেটিংস (128/8, 512M / 2, 1024/1) দিয়ে সরাসরি ডিস্কে লেখার গতি পরীক্ষা করা হয়েছে । ফলাফল: প্রায় 120 এমবি / গুলি (ব্লকের আকার / গণনার উপর নির্ভর করে)

সাহায্যে SMB / এ এফ পি

  1. একে অপরের বিপরীতে এসএমবি 2, এসএমবি 3 এবং এএফপি বেঞ্চমার্ক করেছে। প্রায় সমান
    নীচের আপডেটটি দেখুন: ম্যাকোসের এসএমবি বাস্তবায়ন বাতিল করার জন্য ভুল পদ্ধতি ব্যবহৃত হয়েছে। উইন্ডোজ এসএমবি দ্রুততর, ম্যাকোস 10.11 এবং 10.12 এর সাথে আসা নতুন এসএমবি সেটিংস কারণ হতে পারে।
  2. সাহায্যে SMB সেটিংস খামচি করার চেষ্টা করা হয়েছে সহ সকেট অপশন (এই নিম্নলিখিত নির্দেশ )
  3. বিলম্বিত এস্ক সেটিংসের বিভিন্ন সংস্করণ এবং rsync --sockopts=TCP_NODELAYমন্তব্যগুলি চেষ্টা করা হয়েছে

লেখার গতির কোনও উল্লেখযোগ্য পরিবর্তন নেই। আমরা দুবার পরীক্ষা করে দেখেছি যে কনফিগারটিটি সত্যিই লোড হয়েছে এবং আমরা সঠিক smb.conf সম্পাদনা করছি ।

পদ্ধতি

  1. দেখেছেন সিপিইউ এবং র‌্যাম লোড। কিছুই সর্বাধিক আউট। প্রায় 20% সিপিইউ, স্থানান্তরের সময় প্রায় 25% র‍্যাম।
  2. ডিএসএম 5.XX- র সাথে প্রায় অ-অফ-দ্য-বক্স সেটআপে একই এনএএস পরীক্ষিত। কোনও অতিরিক্ত সফ্টওয়্যার ইনস্টল করা নেই। দ্রষ্টব্য: আমাদের বিভিন্ন স্থানে দুটি রয়েছে। এগুলি সিনোলজির ক্লাউডসিঙ্কের মাধ্যমে সিঙ্কে রয়েছে। একই ফলাফল।
  3. সিস্টেমের সংস্থানগুলি আঁকতে পারে এমন অপ্রয়োজনীয় সমস্ত কিছুই নিষ্ক্রিয় করেছে।

আমরা মনে করি এটি একটি বরং ডিফল্ট সেটআপ, কোনও অভিনব অভিযোজন, ক্লায়েন্ট বা নেটওয়ার্ক উপাদান নয়। মেট্রিক্স অনুসারে সিনোলজিটি প্রকাশ করে এনএএসকে 40 এমবি / সেকেন্ড থেকে 75 এমবি / এস দ্রুত সঞ্চালন করা উচিত। তবে আমরা কেবল বাধা খুঁজে পাই না।

ক্লায়েন্টদের মধ্যে / জন্য NAS

ম্যাক ক্লায়েন্টগুলি হ'ল একটি ম্যাকপ্রো 5,1 (স্ট্যান্ডার্ড ওয়্যার্ড এনআইসি, 10.12.3 (16D32) চলছে) এবং একটি ম্যাকবুকপ্রো 10,1 (থান্ডারবোল্ট নেটওয়ার্ক অ্যাডাপ্টার, 10.11.6 চলছে) এনএস থেকে প্রায় 2 মিটার দূরে চলেছে, একই দিকে চলছে are পরীক্ষায় উইন্ডোজ ল্যাপটপ হিসাবে গিগাবিট সুইচ।

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

গুরুত্বপূর্ণ আপডেট

ম্যাকোস / ওএস এক্স এর এসএমবি বাস্তবায়ন বাতিল করার জন্য ব্যবহৃত পদ্ধতিটি ভুল ছিল। আমি এটি ভার্চুয়াল মেশিনের মাধ্যমে পরীক্ষা করেছি, ধরে নিয়েছি এটি এসএমবি এর নিজস্ব সংস্করণ ব্যবহার করবে, তবে স্পষ্টতই ট্র্যাফিকটি ম্যাকওএসের হাতে চলে যায়, এটি এসএমবি এর সংস্করণ দিয়ে চলেছে।

একটি উইন্ডোজ ল্যাপটপ ব্যবহার করে আমি এখন গড়ে 100 এমবি / সেকেন্ড অর্জন করতে সক্ষম হয়েছি। 10.11 এবং 10.12 এর সাথে এসএমবি বাস্তবায়ন / আপডেটগুলি ইঙ্গিত করা খারাপ পারফরম্যান্সের কারণ হতে পারে। এমনকি signing_requiredসেট করা থাকলেও no

কেউ আপডেটের সাথে পরিবর্তিত হয়ে পারফরম্যান্সকে প্রভাবিত করতে পারে এমন আরও কিছু সেটিংস নির্দেশ করতে পারলে দুর্দান্ত হত।

আপডেট 2 - নতুন অন্তর্দৃষ্টি

অ্যান্ড্রুহেনেল মন্তব্যগুলিতে উল্লেখ করেছেন যে আমার আরও অন্তর্দৃষ্টির জন্য ওয়্যারশার্ক ব্যবহার করে ট্র্যাফিকের বিশদ তদন্ত করা উচিত।

অতএব আমি sudo tcpdump -i eth0 -s 65535 -w tcpdump.dumpদুটি পরীক্ষার ফাইলের মধ্যে একটি 512 এমবি এবং একটি 1 জিবি দিয়ে ট্রান্সফার করার সময়, এনএএস-তে ছুটে এসেছি । এবং ওয়্যারশার্কের সাথে ডাম্প পরিদর্শন করেছেন।

যা আমি পেয়েছি:

  1. ওএস এক্স এবং উইন্ডোজ উভয়ই এসএমবি 2 ব্যবহার করে বলে মনে হচ্ছে যদিও এসএমবি 3 এনএএস-তে সক্ষম হয়েছে (কমপক্ষে ওয়্যারশার্ক অনুসারে)।
  2. ওএস এক্স এমটিইউয়ের সাথে লেগে আছে বলে মনে হচ্ছে । প্যাকেটগুলিতে আরও বেশি 1515 বাইট রয়েছে যা আরও বেশি নেটওয়ার্কের ওভারহেড এবং প্রেরিত প্যাকেটগুলিতে পৌঁছায় (ডাম্পগুলিতে দৃশ্যমান)।
  3. উইন্ডোজ 26334 বাইট পর্যন্ত প্যাকেটগুলি প্রেরণ করবে বলে মনে হয় (যদি আমি তথ্যটি সঠিকভাবে পড়ে থাকি তবে দয়া করে যাচাই করুন)) এমনকি এমটিইউ এটির অনুমতি না দেয়, যেহেতু এটি এনএএস-এ 1500 সেট করা হয়েছে, সর্বাধিক সেটিংটি সেখানে 9000 হবে (সাইনোলজিও তাদের পরীক্ষায় 1500 সেটিং ব্যবহার করে)।
  4. /Etc/nsmb.conf এ যোগ smb_neg=smb3_onlyকরে ম্যাকোসকে এসএমবি 3 ব্যবহার করতে বাধ্য করার চেষ্টা করা কার্যকর হয়নি বা কমপক্ষে দ্রুত স্থানান্তরিত হতে পারে না।
  5. চলমান rsync --sockopts=TCP_NODELAYবিভিন্ন TCP বিভিন্ন সমন্বয় সঙ্গে কোনো প্রভাব ACK সেটিংস (3 0) দেরি করেছে করেছিলেন (দ্রষ্টব্য: আমি 3 ডিফল্ট ACK সেটিংস থেকে tcpdump দৌড়ে)।

আমি .csv ফাইল হিসাবে 4 টি ডাম্প তৈরি করেছি, 512 এমবি (টেস্ট-2.file) অনুলিপি করার সময় 2 টি এবং 1024 এমবি (টেস্ট.ফাইল) অনুলিপি করার সময়। আপনি এখানে ওয়্যারশার্ক রফতানি ডাউনলোড করতে পারেন (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অর্থ কনফিগারেশনের সেটিংটি কাজ করে না। তবে কেবল এটিই নাস দ্বারা সমর্থিত। আমি ট্রিপল পরীক্ষা করে দেখেছি যে signing_requiredআমার কনফিগারেশনে সেটিংস পরিবর্তন করার ফলে লেখার গতিতে প্রভাব পড়ে (~ 20 এমবি / গুলি টিউন করা হলে, MB 60 এমবি / সেকস বন্ধ থাকে)।

আপডেট 4 - সাম্বা যুদ্ধসমূহ: একটি নতুন আশা

এটি কিছুটা বিব্রত বোধ করে তবে এখানে মূল সমস্যাটি আবার - এটি পরিমাপ বলে মনে হচ্ছে।

সক্রিয় আউট rsync --progress -a30 মেগাবাইট সম্পর্কে খরচ / গতি লেখার s। ddসরাসরি এসএমবি শেয়ারের সাথে লেখা এবং ব্যবহার time cp /local/test.file /NAS/test.fileকরা প্রায় 85-90 এমবি / সেকেন্ডে দ্রুত হয় এবং স্পষ্টতই অনুলিপি করার দ্রুততম উপায় হ'ল ম্যাকোস ফাইন্ডার প্রায় 100 এমবি / এস (যা পদ্ধতিটি পরিমাপ করা সবচেয়ে কঠিন, কারণ এটি নেই) সময় বা গতির সূচক - কার এটির প্রয়োজন, ঠিক? o_O)। আমরা প্রথমে স্টপওয়াচ ব্যবহার করে 1 জিবি ফাইল এবং তারপরে একটি 10 ​​জিবি ফাইল অনুলিপি করে এটি পরিমাপ করেছি।

এই প্রশ্নের শেষ আপডেটের পরে আমরা কী চেষ্টা করেছি।

  1. ম্যাক ক্লায়েন্ট থেকে ম্যাক ক্লায়েন্টে অনুলিপি করুন। উভয়েরই এসএসডি রয়েছে (ম্যাকপ্রো 250 এমবি / সেকেন্ড ডিস্কের মালিক, 300 এমবি / গুলি সহ ম্যাকবুক প্রো লিখেছেন)। ফলাফল: ddম্যাকবুক প্রো থেকে ম্যাকপ্রো ( rsync25 এমবি / গুলি) পর্যন্ত লেখার মাধ্যমে একটি পরিমিত 65 এমবি / সেকেন্ড । 25 এমবি / সেকেন্ড দেখার মুহূর্তটি যখন আমরা আরএসসিএনকে প্রশ্ন করা শুরু করি। এখনও 65 এমবি / গুলি অত্যন্ত ধীর গতির। সুতরাং ম্যাকোজে এসএমবি বাস্তবায়ন মনে হচ্ছে ... ভাল, প্রশ্নবিদ্ধ।
  2. ডিডি এবং সিপির সাহায্যে বিভিন্ন এসকে সেটিংস ব্যবহার করার চেষ্টা করা হয়েছে - ভাগ্য নেই।
  3. অবশেষে আমরা সমস্ত উপলব্ধ 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বৈধ সমতুল্য হওয়া উচিত।

যাইহোক, এই সেটিংসগুলির কোনওটিই আমাদের পক্ষে আলাদা হয়নি।

এক নজরে নতুন প্রশ্ন

  1. কেন একটি (1!) ফাইল অনুলিপি করার জন্য ব্যয়বহুল পদ্ধতিতে আরএসআইএনসি হয়। এখানে সিঙ্ক্রোনাইজ / তুলনা করার মতো অনেক কিছুই নেই, আছে কি? Tcpdump সম্ভব ওভারহেড নির্দেশ করে না।

  2. এসএমবি শেয়ারে স্থানান্তরিত করার সময় ম্যাকোস অনুসন্ধানকারীর চেয়ে কম ddও কেন cpধীর হয়? এটি ফাইন্ডারের সাথে অনুলিপি করার সময় মনে হয় টিসিপি যোগাযোগের ক্ষেত্রে উল্লেখযোগ্যভাবে কম স্বীকৃতি রয়েছে। (আবার: অ্যাক সেটিং উদাহরণস্বরূপ delayed_ack=1আমাদের জন্য কোনও পার্থক্য নেই।)

  3. উইন্ডোজ এমটিইউকে কেন উপেক্ষা করবে বলে মনে হচ্ছে, উল্লেখযোগ্যভাবে বৃহত্তর এবং অতএব কম টিসিপি প্যাকেট প্রেরণ করবে, যার ফলে ম্যাকোএসের মাধ্যমে সম্ভব সমস্ত কিছুর তুলনায় সেরা পারফরম্যান্স হবে।

প্যাকেটগুলি ম্যাকোস থেকে দেখতে এমন হয় (ক্রমাগত 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"

আপনি এখানে পুরো .csv ডাউনলোড করতে পারেন (25.2 এমবি), ফাইলের নামগুলি কী অনুলিপি করা হয়েছে তা ব্যাখ্যা করে (ওএস, স্থানান্তর পদ্ধতি এবং ফাইলের আকার)।


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

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

একটি উইন্ডোজ ল্যাপটপ ব্যবহার করে আমি এখন গড়ে 100 এমবি / সেকেন্ড অর্জন করতে সক্ষম হয়েছি। 10.11 এবং 10.12 এর সাথে এসএমবি বাস্তবায়ন / আপডেটগুলি ইঙ্গিত করা খারাপ পারফরম্যান্সের কারণ হতে পারে। যদিও সম্ভবত সত্য, এখানে একটা হয় অনেক এই Windows ল্যাপটপ এবং আপনার OS X এর ইনস্টলেশন (গুলি) মাত্র 60 মেগাবাইট / সেকেন্ড পাচ্ছেন মধ্যে অন্যান্য পার্থক্যের। নেটওয়ার্ক ড্রাইভার, নেটওয়ার্ক সেটিংস, হার্ডওয়্যার এবং আরও অনেক কিছুই অবদান রাখতে পারে। 100 এমবি / সেকেন্ড থেকে পারফরম্যান্সটি নক করতে খুব বেশি লাগে না - যা গিগাবিট ইথারনেটের সীমা - প্রায় 60 এমবি / সেকেন্ডের মধ্যে।
অ্যান্ড্রু হেনেল

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

@ ওয়েনরো আপনি কি দ্রুত উইন্ডোজ ল্যাপটপ এবং ধীর ওএস এক্স মেশিনগুলি থেকে স্থানান্তরগুলির জন্য কমপক্ষে প্যাকেটের আকার এবং সময়গুলি ক্যাপচার করতে পারেন? একটি পার্থক্য কমপক্ষে আপনাকে কিছু তথ্য দিয়ে শুরু করতে পারে। উইন্ডোজ ল্যাপটপের তুলনায় নাগলের অ্যালগরিদম / বিলম্বিত টিসিপি অ্যাকের জন্য ওএস এক্স সেটিংস কী? এটি প্রাসঙ্গিক হতে পারে: shabangs.net/osx/…
অ্যান্ড্রু হেনেল

উত্তর:


1
  1. অনুরূপ প্রশ্ন কিন্তু আকর্ষণীয় উত্তর রয়েছে, আপনি সম্ভবত এই মন্তব্যটি 5 টি মন্তব্য করতে পারেন: https://bugzilla.samba.org/show_bug.cgi?id=8512#c5

এখানে "পিটার ভ্যান হুফ্ট" উদ্ধৃত করুন। আমি কী / কোন লিনাক্স ডিস্টের ভিত্তিতে পরীক্ষার ভিত্তিতে নিশ্চিত তা নিশ্চিত নই Al এবং rsync এর সংস্করণও। তবে: ১. তিনি আমাদের পারফরম্যান্স বাড়াতে পারলে - স্পার পতাকা ব্যবহার করার চিন্তাভাবনা করেন । ২. তিনি এনএফএস প্রোটোকলে পরীক্ষা করেছেন তবে একই গতির সমস্যার সাথে দেখা করেছেন, সুতরাং এটি প্রোটোকল (এসএমবি 2/3, এএফপি, ইত্যাদি) কারণে নয়।

আমরা একটি 10 ​​জিবি লিঙ্কের উপরে এনএফএস 3 মাউন্টগুলি ব্যবহার করে একটি ফাইল সার্ভার থেকে অন্য ফাইলটিতে ডাটা অনুলিপি করতে আরএসসিএনসি ব্যবহার করি । আমরা দেখতে পেলাম যে বাফার আকারগুলি দ্রুত চালনা (দ্রুত পরীক্ষা হিসাবে) কর্মক্ষমতা বাড়ায়। - স্পার্স ব্যবহার করার সময় এটি 2 এমবিপিএস থেকে 100 এমবিপিএস পর্যন্ত পঞ্চাশের ফ্যাক্টরের সাথে কর্মক্ষমতা বাড়ায়।

  1. আরএসসিএনএইচ পারফরম্যান্স সম্পর্কে এখানে আরও একটি আকর্ষণীয় পরিদর্শন। https://lwn.net/Articles/400489/

LWN.net এর একটি উপসংহার রয়েছে যা পারফরম্যান্স ইস্যু কার্নেলের সাথে প্রাসঙ্গিক হতে পারে এমনকি ২০১০-এ পোস্ট করা নিবন্ধ এবং আমরা NAS বা MacOS এ পরিবর্তন করতে পারি না। তবে এই নিবন্ধটি আমাদের একটি ধারণা দেয় যে কার্নেল ইস্যুটি চেকসাম (আমার অনুমান) গণনা দ্বারা সৃষ্ট হতে পারে ।

একটি বিষয় পরিষ্কার: আমার Mythtv সিস্টেমে কার্নেলটি আপগ্রেড করা উচিত। সাধারণভাবে, 2.6.34 এবং 2.6.35-rc3 কার্নেলগুলি পুরানো 2.6.27 কার্নেলের চেয়ে ভাল পারফরম্যান্স দেয়। তবে, টিঙ্কিং বা না, আরএসসিএনসি এখনও 100 এমআইবি / সেকেন্ডে অনুলিপি করে এমন একটি সাধারণ সিপিকে পরাজিত করতে পারে না। প্রকৃতপক্ষে, সহজ স্থানীয় কপিগুলির জন্য আরএসসিএনকে সত্যই প্রচুর সিপিইউ পাওয়ার প্রয়োজন needs সর্বোচ্চ ফ্রিকোয়েন্সিতে, সিপি-র কেবলমাত্র 0.34 + 20.95 সেকেন্ডের সিপিইউ সময় প্রয়োজন, আরএসসিএনসি এর 70 + 55 সেকেন্ডের সাথে তুলনা করে।

এছাড়াও উদ্ধৃতি মন্তব্য এই আছে:

নোট করুন যে আরএসসিএনসি সর্বদা এটি যাচাই করে যে ফাইলটি স্থানান্তরিত হওয়ার সাথে সাথে তৈরি হওয়া একটি সম্পূর্ণ-ফাইল চেকসাম যাচাই করে প্রতিটি স্থানান্তরিত ফাইল সঠিকভাবে পুনর্নির্মাণ করা হয়েছিল receiving

আপডেট 1 : আমার ভুল, এই বর্ণনাটি - চেকসামের জন্য। এটি এখানে দেখুন: [--checksum বিকল্পের বর্ণনা উন্নত করা হয়েছে।] পিএস, আমার 2 টির বেশি লিঙ্ক পোস্ট করার মতো খ্যাতি নেই।

তবে আরএসসিএন ম্যান পৃষ্ঠা থেকে আমি একই বিবরণ পাই না, সুতরাং অনুমান করছি যে কেউ বোল্ডের নীচে কথা বলছে:

রাইকিঙ্ক এমন ফাইলগুলি সন্ধান করে যা "দ্রুত চেক" অ্যালগরিদম (ডিফল্টরূপে) ব্যবহার করে স্থানান্তর করা দরকার যা আকারে বা সর্বশেষ-পরিবর্তিত সময়ে পরিবর্তিত ফাইলগুলির সন্ধান করে। অন্যান্য সংরক্ষিত বৈশিষ্ট্যের কোনও পরিবর্তন (বিকল্পগুলির দ্বারা অনুরোধ হিসাবে) সরাসরি গন্তব্য ফাইলটিতে করা হয় যখন দ্রুত চেকটি নির্দেশ করে যে ফাইলটির ডেটা আপডেট করার প্রয়োজন নেই।

অতএব, সিপি / টার / বিড়ালের সাথে তুলনা করুন, যদি আমরা ছোট বা বড় ফাইলগুলির গুচ্ছ অনুলিপি করতে rsync ব্যবহার করি তবে এটি পারফরম্যান্স সমস্যার কারণ হতে পারে। তবে আমি আরএসসিএনসি এর সোর্স কোডটি পড়তে পারছি না বলেই আমি নিশ্চিত করতে পারছি না এটিই চূড়ান্ত কারণ।

আমার ধারণা চেক রাখা হয়:

  1. আরএসএনসি সংস্করণটি পরীক্ষার জন্য কীভাবে ব্যবহার করা হচ্ছে? আপনি সর্বশেষ সংস্করণে আপডেট করতে পারেন?
  2. --debug = FLAGS সহ --stats এবং -v ব্যবহার করার সময় কোন আউটপুট দেখতে দিন

পতাকা

- স্ট্যাটাস এটি ফাইলের ট্রান্সফারের উপর পরিসংখ্যানগুলির একটি ভারবোজ সেট মুদ্রণ করতে আরএসসিএনকে বলেছে, আপনার ডেটার জন্য আরএসসিএন অ্যালগরিদম কতটা কার্যকর তা আপনাকে বলতে দেয়।

--debug = FLAGS এই বিকল্পের সাহায্যে আপনি যে ডিবাগ আউটপুটটি দেখতে চান তার উপর সূক্ষ্ম-নিয়ন্ত্রণযুক্ত নিয়ন্ত্রণ পেতে দেয়। একটি পৃথক পতাকা নাম একটি স্তরের সংখ্যা দ্বারা অনুসরণ করা যেতে পারে, যার সাথে 0 আউটপুটটি নিঃশব্দ করা হয়, 1 হ'ল ডিফল্ট আউটপুট স্তর এবং উচ্চতর সংখ্যাগুলি পতাকাটির আউটপুট বাড়িয়ে তোলে (যারা উচ্চ স্তরের সমর্থন করে তাদের জন্য)। ভার্জোজ স্তরের প্রতিটি বৃদ্ধির জন্য সমস্ত উপলব্ধ পতাকার নাম , তারা কী আউটপুট দেয় এবং কোন পতাকা নাম যুক্ত হয় তা দেখতে --debug = সহায়তা ব্যবহার করুন

শেষ পর্যন্ত, আমি আরও জ্ঞান পাওয়ার জন্য এই পরিপূরক পোস্টটি পড়ার পরামর্শ দেব।
"নেটওয়ার্কের মাধ্যমে কীভাবে বৃহত পরিমাণে ডেটা স্থানান্তর করবেন" moo.nac.uci.edu/~hjm/HOWTO_move_data.html


আপনি কি এখানে সম্পর্কিত তথ্য অন্তর্ভুক্ত করতে পারেন?
বার্তেব

এটি তাত্ত্বিকভাবে প্রশ্নের উত্তর দিতে পারে তবে উত্তরটির প্রয়োজনীয় অংশগুলি এখানে অন্তর্ভুক্ত করা এবং রেফারেন্সের জন্য লিঙ্ক সরবরাহ করা ভাল।
স্টিফেন রাউচ

0

Rsync / ssh এনক্রিপ্ট করে সংযোগ এসএমএস করে না, যদি আমি সঠিকভাবে মনে করি। যদি এটি কেবল একটি ফাইল হয় তবে একটি সিস্টেম সেই ফাইলটি পড়তে সক্ষম হতে পারে এবং অন্যটি নাও। আরও মনে রাখবেন যে 1514 এর উপরে এমটিইউ রাখার জন্য আপনাকে "দৈত্য" / "জাম্বো ফ্রেমস" প্যাকেটগুলি সক্ষম করতে হবে যে প্যাকেটগুলিকে আরও কেটে ফেলতে হবে যে জড়িত হতে পারে যে প্যাকেটটির "পুনরায়" চাপানোর জন্য ওভারহেড রয়েছে। দ্বিতীয় বিষয়টি লক্ষ্যণীয় হ'ল "দৈত্য" / "জাম্বো ফ্রেম" উভয় প্রান্তে এবং এরপরে সমস্ত কিছুই সক্ষম করা দরকার।

1514 হ'ল সাধারণ ইথারনেট ফ্রেম। 6 কে -9 কে ফ্রেম ওএস / অ্যাপ্লিকেশন উপর নির্ভর করে জায়ান্ট বা "জাম্বো ফ্রেম" বলা হয়

আমার নাসের মধ্যে আমার গড় গড়ে ৮০ এমবি / এস (ভিএমএসের সাথে একটি পিসি হ'ল এনএএস হ'ল) ​​এবং এসএফটিপি সহ আমার স্টেশন (পিসি) (এসএসএফএস ব্যবহার করে) [দৈত্যগুলি সক্ষম নয়] এবং এর মধ্যে থাকা ডিভাইসটি একটি মাইক্রোটিক ২০১১ (চলছে) ট্রু সুইচ চিপ শুধুমাত্র)

মনে রাখবেন যে এমটিইউ দুটি পয়েন্টের মধ্যে সমঝোতা হয়েছে এবং একটি পথ ধরে আপনার বিভিন্ন ক্ষমতাতে বেশ কয়েকটি এমটিইউ থাকতে পারে এবং এমটিইউ সর্বনিম্ন উপলব্ধ হবে।

সম্পাদনা: এসএমবি ফাইল স্থানান্তরের জন্য খুব দক্ষ নয়।

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