ইএসএক্সআই এনএফএস ডেটাস্টোরগুলিতে সমস্যা সমাধানের বিলম্ব ঘটছে ikes


44

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

এটি fsync-tester (টেড Ts'o দ্বারা) এবং ioping ব্যবহার করে পুনরুত্পাদন করা যেতে পারে । উদাহরণস্বরূপ একটি 8 জিবি ডিস্ক সহ একটি গ্রিমেল লাইভ সিস্টেম ব্যবহার করুন:

Linux 2.6.33-grml64:
root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 5.0391
fsync time: 5.0438
fsync time: 5.0300
fsync time: 0.0231
fsync time: 0.0243
fsync time: 5.0382
fsync time: 5.0400
[... goes on like this ...]

এটি 5 সেকেন্ড, মিলিসেকেন্ড নয়। এটি একই হোস্ট এবং ডেটাস্টোরের চলমান ভিন্ন ভিএম-তে আইও-লেটেন্সিগুলি তৈরি করছে :

root@grml /mnt/sda/ioping-0.5 # ./ioping -i 0.3 -p 20 .
4096 bytes from . (reiserfs /dev/sda): request=1 time=7.2 ms
4096 bytes from . (reiserfs /dev/sda): request=2 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=3 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=4 time=0.9 ms
4096 bytes from . (reiserfs /dev/sda): request=5 time=4809.0 ms
4096 bytes from . (reiserfs /dev/sda): request=6 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=7 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=8 time=1.1 ms
4096 bytes from . (reiserfs /dev/sda): request=9 time=1.3 ms
4096 bytes from . (reiserfs /dev/sda): request=10 time=1.2 ms
4096 bytes from . (reiserfs /dev/sda): request=11 time=1.0 ms
4096 bytes from . (reiserfs /dev/sda): request=12 time=4950.0 ms

আমি যখন প্রথম ভিএম স্থানীয় স্টোরেজে স্থানান্তরিত করি তখন এটি পুরোপুরি স্বাভাবিক দেখায়:

root@dynip211 /mnt/sda # ./fsync-tester
fsync time: 0.0191
fsync time: 0.0201
fsync time: 0.0203
fsync time: 0.0206
fsync time: 0.0192
fsync time: 0.0231
fsync time: 0.0201
[... tried that for one hour: no spike ...]

আমি যে বিষয়গুলি চেষ্টা করেছি তাতে কোন পার্থক্য নেই:

  • বেশ কয়েকটি ESXi বিল্ড পরীক্ষিত: 381591, 348481, 260247
  • বিভিন্ন হার্ডওয়্যার, বিভিন্ন ইন্টেল এবং এএমডি বাক্সে পরীক্ষিত
  • বিভিন্ন এনএফএস সার্ভারের সাথে পরীক্ষিত, সমস্ত একই আচরণ দেখায়:
    • ওপেন ইন্ডিয়ানা বি 147 (জেডএফএস সিঙ্ক সর্বদা বা অক্ষম: কোনও পার্থক্য নেই)
    • ওপেন ইন্ডিয়ানা বি 148 (জেডএফএস সিঙ্ক সর্বদা বা অক্ষম: কোনও পার্থক্য নেই)
    • লিনাক্স ২.6.৩২ (সিঙ্ক বা অ্যাসিঙ্ক: কোনও পার্থক্য নেই)
    • এনএফএস সার্ভার একই মেশিনে (ভার্চুয়াল স্টোরেজ অ্যাপ্লায়েন্স হিসাবে) বা অন্য কোনও হোস্টে থাকলে কোনও পার্থক্য হয় না

অতিথি ওএস পরীক্ষা করা হয়েছে, সমস্যা দেখাচ্ছে:

  • উইন্ডোজ 64৪ বিট (ক্রিস্টালডিস্কমার্ক ব্যবহার করে, লেটেন্সি স্পাইকগুলি বেশিরভাগ ক্ষেত্রে প্রস্তুতির সময় ঘটে)
  • লিনাক্স 2.6.32 (fsync- পরীক্ষক + ioping)
  • লিনাক্স 2.6.38 (fsync- পরীক্ষক + ioping)

আমি লিনাক্স 2.6.18 ভিএম-তে এই সমস্যাটি পুনরুত্পাদন করতে পারিনি।

আর একটি কাজ হ'ল ভার্চুয়াল আইডিই ডিস্ক (বনাম এসসিএসআই / এসএএস) ব্যবহার করা, তবে এটি পারফরম্যান্স এবং ভিএম প্রতি ড্রাইভের সংখ্যা সীমাবদ্ধ করে চলেছে।

আপডেট 2011-06-30:

অ্যাপ্লিকেশনটি একাধিক ছোট ব্লকে fsync এর আগে লিখলে বিলম্বিত স্পাইকগুলি প্রায়শই ঘটবে বলে মনে হয়। উদাহরণস্বরূপ fsync- পরীক্ষক এটি করেন (স্ট্রেস আউটপুট):

pwrite(3, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1048576, 0) = 1048576
fsync(3)                                = 0

ioping ফাইল প্রস্তুত করার সময় এটি করে:

[lots of pwrites]
pwrite(3, "********************************"..., 4096, 1036288) = 4096
pwrite(3, "********************************"..., 4096, 1040384) = 4096
pwrite(3, "********************************"..., 4096, 1044480) = 4096
fsync(3)                                = 0

আইওপিংয়ের সেটআপ পর্বটি প্রায় সর্বদা স্তব্ধ হয়ে যায়, যখন ফাইসিঙ্ক-পরীক্ষক কখনও কখনও সূক্ষ্মভাবে কাজ করে। একাধিক ছোট ব্লক লেখার জন্য কি কেউ ফিএনসিএনসি-টেস্টার আপডেট করতে সক্ষম? আমার সি দক্ষতা স্তন্যপান;)

আপডেট 2011-07-02:

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

আপডেট ২০১১-০-0-০6:

এটি একটি ওয়্যারশার্ক ক্যাপচারের অংশ, একই ভিএসউইচটিতে তৃতীয় ভিএম দ্বারা ক্যাপচার করা হয়েছে। এটি সমস্ত একই হোস্টে ঘটে, কোনও শারীরিক নেটওয়ার্ক জড়িত না।

আমি প্রায় ২০ টা সময় ধরেই ইয়োপিং শুরু করেছি। পাঁচ সেকেন্ড বিলম্ব না হওয়া পর্যন্ত কোনও প্যাকেট প্রেরণ করা হয়নি:

No.  Time        Source                Destination           Protocol Info
1082 16.164096   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1085), FH:0x3eb56466 Offset:0 Len:84 FILE_SYNC
1083 16.164112   192.168.250.10        192.168.250.20        NFS      V3 WRITE Call (Reply In 1086), FH:0x3eb56f66 Offset:0 Len:84 FILE_SYNC
1084 16.166060   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet-locate [ACK] Seq=445 Ack=1057 Win=32806 Len=0 TSV=432016 TSER=769110
1085 16.167678   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1082) Len:84 FILE_SYNC
1086 16.168280   192.168.250.20        192.168.250.10        NFS      V3 WRITE Reply (Call In 1083) Len:84 FILE_SYNC
1087 16.168417   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1057 Ack=773 Win=4163 Len=0 TSV=769110 TSER=432016
1088 23.163028   192.168.250.10        192.168.250.20        NFS      V3 GETATTR Call (Reply In 1089), FH:0x0bb04963
1089 23.164541   192.168.250.20        192.168.250.10        NFS      V3 GETATTR Reply (Call In 1088)  Directory mode:0777 uid:0 gid:0
1090 23.274252   192.168.250.10        192.168.250.20        TCP      iclcnet-locate > nfs [ACK] Seq=1185 Ack=889 Win=4163 Len=0 TSV=769821 TSER=432716
1091 24.924188   192.168.250.10        192.168.250.20        RPC      Continuation
1092 24.924210   192.168.250.10        192.168.250.20        RPC      Continuation
1093 24.924216   192.168.250.10        192.168.250.20        RPC      Continuation
1094 24.924225   192.168.250.10        192.168.250.20        RPC      Continuation
1095 24.924555   192.168.250.20        192.168.250.10        TCP      nfs > iclcnet_svinfo [ACK] Seq=6893 Ack=1118613 Win=32625 Len=0 TSV=432892 TSER=769986
1096 24.924626   192.168.250.10        192.168.250.20        RPC      Continuation
1097 24.924635   192.168.250.10        192.168.250.20        RPC      Continuation
1098 24.924643   192.168.250.10        192.168.250.20        RPC      Continuation
1099 24.924649   192.168.250.10        192.168.250.20        RPC      Continuation
1100 24.924653   192.168.250.10        192.168.250.20        RPC      Continuation

২ য় আপডেট ২০১১-০7-০6:

টিসিপি উইন্ডো আকার থেকে কিছু প্রভাব আছে বলে মনে হচ্ছে। আমি এনএনএফ সার্ভার হিসাবে ফ্রিএনএএস (ফ্রিবিএসডি ভিত্তিক) ব্যবহার করে এই সমস্যাটি পুনরুত্পাদন করতে পারিনি was ওয়্যারশার্ক ক্যাপচারগুলি নিয়মিত বিরতিতে টিসিপি উইন্ডো আপডেটগুলি 29127 বাইটে দেখায়। আমি ওপেন ইন্ডিয়ানা সহ তাদের দেখতে পাইনি, যা ডিফল্টরূপে বড় আকারের উইন্ডো আকার ব্যবহার করে।

আমি যদি ওপেন ইন্ডিয়ানাতে নিম্নলিখিত অপশনগুলি সেট করে এবং এনএফএস সার্ভারটি পুনরায় চালু করতে পারি তবে আমি এই সমস্যাটির আর পুনরুত্পাদন করতে পারি না:

ndd -set /dev/tcp tcp_recv_hiwat 8192 # default is 128000
ndd -set /dev/tcp tcp_max_buf 1048575 # default is 1048576

তবে এটি পারফরম্যান্সকে হত্যা করে: ডিডি_রেস্কু সহ একটি ফাইলে / dev / শূন্য থেকে লিখতে 170MB / s থেকে 80MB / s হয় to

আপডেট ২০১১-০-0-০7:

আমি এই টিসিপিডাম্প ক্যাপচারটি আপলোড করেছি (ওয়্যারশার্ক দিয়ে বিশ্লেষণ করা যেতে পারে)। এই ক্ষেত্রে 192.168.250.2 হ'ল এনএফএস সার্ভার (ওপেনইন্ডিয়ানা বি 148) এবং 192.168.250.10 হ'ল ইএসসি হোস্ট।

এই ক্যাপচারের সময় আমি যে জিনিসগুলি পরীক্ষা করেছি:

"Ioping -w 5 -i 0.2।" শুরু হয়েছে। সময়ে 30, 5 সেকেন্ডে সেটআপ থাকাকালীন সময়ে 40 এ সমাপ্ত।

"Ioping -w 5 -i 0.2।" শুরু হয়েছে। 70 এ শেষ সময়ে 60, 5 সেকেন্ডের হ্যাঙ্গআপ।

নিম্নলিখিত আউটপুট সহ 90 এ সময়ে "fsync- পরীক্ষক" শুরু হয়েছিল, 120 সময় বন্ধ হয়েছিল:

fsync time: 0.0248
fsync time: 5.0197
fsync time: 5.0287
fsync time: 5.0242
fsync time: 5.0225
fsync time: 0.0209

২ য় আপডেট ২০১১-০7-০7:

অন্য একটি এনএফএস সার্ভার ভিএম পরীক্ষিত, এবার নেক্সেন্টাস্টোর 3.0.5 সম্প্রদায় সংস্করণ: একই সমস্যাগুলি দেখায়।

আপডেট ২০১১-০7-৩১:

আমি নতুন ইসএসআই বিল্ড 4.1.0.433742 এও এই সমস্যাটি পুনরুত্পাদন করতে পারি।


12
আমার বলতে হবে যে কোনও ব্র্যান্ড-নতুন ব্যবহারকারী এই জাতীয় ডকুমেন্টেড এবং চিন্তার বাইরে প্রশ্ন নিয়ে বোর্ডে এসেছেন - গুরুত্ব সহকারে, আপনার কাছে টুপি রয়েছে। এটি সত্যই আকর্ষণীয়ও, আমি উভয়ই ধন্যবাদ দেওয়ার আগে সাইকো-পরীক্ষক জুড়ে আসিনি। এটি বলেছিল আমি নিশ্চিত না যে আমার কাছে যোগ করার মতো কিছু আছে, আপনি ইতিমধ্যে যা কিছু করেছেন তা চেষ্টা করেছেন - আমি বলব VMWare এর সাথে কথা বলুন সত্য বলতে, তারা এই ধরণের বিষয়ে খুব ভাল 'দীর্ঘ-লেজ' / 'সত্যিকারের পরিষেবা নয় "বিষয়গুলি গুরুত্ব সহকারে। যাইহোক, আপনি এখন পর্যন্ত যা করেছেন তার পক্ষে ভালভাবে বলতে চেয়েছিলেন :)
চপ্পার 3

দুর্ভাগ্যক্রমে ভিএমওয়্যার ওয়েবসাইট আমাকে তাদের সাথে যোগাযোগ করতে দেবে না: "আপনার বর্তমানে কোনও সক্রিয় সমর্থন এনটাইটেলমেন্ট নেই"
exo_cw

আহ, হ্যাঁ, এটি অবশ্যই সমস্যা হতে পারে ...
চপ্পার 3

3
এনএফএসের সাথে 5 সেকেন্ডের সময়সীমা পরিচিত মনে হয়েছিল। লিনাক্স এনএফএসে আরপিসির জন্য একটি .7 দ্বিতীয় সময়সামগ্রী রয়েছে যা প্রতিটি ব্যর্থতার পরে দ্বিগুণ হয় এবং 3 ব্যর্থতার পরে একটি ডিফল্ট টান দেয় (ডিফল্ট সেটিংস)। .7 + 1.4 + 2.8 = 4.9 সেকেন্ড। বিভিন্ন ধরণের আরপিসি প্রমাণীকরণ সংক্রান্ত সমস্যা রয়েছে যা এর কারণ হতে পারে।
চিহ্নিত করুন

2
@ রায়ান: আমি ক্যাপচার ফাইলটি আপলোড করেছি। আমি এনএফএসস্ট্যাট আউটপুটও আপলোড করেছি ।
exo_cw

উত্তর:


5

এই সমস্যাটি ESXi 5 এ স্থির হয়েছে বলে মনে হচ্ছে আমি সাফল্যের সাথে 469512 নির্মাণের পরীক্ষা করেছি।


3

ধন্যবাদ, এনএফএসটিট দেখতে ভাল লাগছে। আমি ক্যাপচার পর্যালোচনা করেছি। চূড়ান্ত কিছু খুঁজে পাওয়া যায় নি, তবে আকর্ষণীয় কিছু খুঁজে পেয়েছি। আমি tcp.time_delta> 5 এ ফিল্টার করেছি 5.. প্রতি বিলম্বের ঘটনায় আমি যা পেয়েছি তা হ'ল একটি আরপিসি কলের সঠিক সূচনা। সমস্ত নতুন আরপিসি কলগুলি ধীর ছিল না, তবে আরপিসি কলের ঠিক শুরুতেই সমস্ত ধীরগতি হয়েছিল। এছাড়াও, ক্যাপচার থেকে দেখা যাচ্ছে যে 192.168.250.10 এ সমস্ত বিলম্ব রয়েছে। 192.168.250.2 সমস্ত অনুরোধের সাথে সাথে প্রতিক্রিয়া জানায়।

ফলাফল:

  • আরপিসি কলের প্রথম প্যাকেটে সর্বদা বিলম্ব ঘটে
  • এনএফএস কমান্ডের প্রকারগুলি দেরীতে দৃষ্টান্তগুলির সাথে সম্পর্কিত হয়নি
  • ফ্র্যাগমেন্টেশন = কেবল প্রথম প্যাকেটটি বিলম্ব করে

একটি বৃহত রাইটিং কল 300 টি পৃথক টিসিপি প্যাকেটগুলিতে বিভক্ত হতে পারে এবং কেবল প্রথমটি বিলম্বিত হয়, তবে বাকী সমস্তগুলিই এর মধ্যে দিয়ে যায়। মাঝে মাঝে দেরি হয় না। আমি নিশ্চিত নই যে উইন্ডোর আকার কীভাবে সংযোগের শুরুতে এত মারাত্মকভাবে প্রভাব ফেলতে পারে ।

পরবর্তী পদক্ষেপ: আমি এনসিএসএসভিসি_এমএক্সবিএলকেএসআইজে জাতীয় এনএসএস বিকল্পগুলি টিসিপি উইন্ডোটির চেয়ে নীচে দিকে ট্যুইচ করা শুরু করব। এছাড়াও, আমি লক্ষ্য করেছি যে 2.6.18 কাজ করে যখন 2.6.38 কাজ করে না। আমি জানি যে সময়সীমার সময় ভিএমএক্সনেট 3 ড্রাইভারের জন্য সমর্থন যুক্ত করা হয়েছিল। হোস্টগুলিতে আপনি কোন এনআইসি ড্রাইভার ব্যবহার করছেন? টিসিপি অফলোড হচ্ছে হ্যাঁ / না? 95 সেকেন্ড চিহ্নের আশেপাশে একটি একক এনএফএস লিখন কলের জন্য 500 টিরও বেশি টিসিপি প্যাকেট রয়েছে। টিসিপির দায়িত্বে থাকা এবং বৃহত পিডিইউ ভাঙলে যা কিছু অবরুদ্ধ হতে পারে।


আমি এনএফএস: nfs3_max_transfer_size, nfs: nfs3_max_transfer_size_cots এবং nfs: nfs3_bsize সব মিলিয়ে 8192 এ সেট করার চেষ্টা করেছি: কোনও পার্থক্য নেই, একই সমস্যা। লিনাক্স গেস্টগুলি কেবল তাদের এসসিএসআই / এসএএস-ডিস্ক ব্যবহার করে, কোনও এনএফএস নেই - ইএসএক্সআই এনএফএস-ক্লায়েন্ট, সুতরাং লিনাক্স গেস্টে কোনও নেটওয়ার্ক ড্রাইভারের সমস্যা নেই। এনএফএস সার্ভারের দিকে আমি ভার্চুয়াল ই 1000 এবং ভিএমএক্সনেট 3 উভয়ই চেষ্টা করেছি: কোনও পার্থক্য নেই। আমি যতদূর জানি ইএসএক্সআই কেবলমাত্র এসএসআইএসআইয়ের জন্য টিসিপি অফলোডিং ব্যবহার করে।
exo_cw

বৃহত্তম ? আমার কাছে কেন টিসিপি উইন্ডোটি সামঞ্জস্য করা তার ফলে একটি তাত্পর্য হয়ে উঠবে ... আমার অন্ত্রটি আমাকে বলেছে যে টিসিপি-র মাধ্যমে big বড় পিডিইউগুলিকে টুকরো টুকরো করা with নেটওয়ার্কিং স্ট্যাকের এমন কিছু যা এটিকে দমিয়ে দিচ্ছে। আমরা যে আচরণটি দেখছি তার সাথে খাপ খায় এমন কোনও কিছুই ভাবতে পারি না। উইন্ডোর আকারটি যদি একটি সমস্যা হয়ে থাকে তবে আমাদের উচিত বৃহত্তর স্থানান্তরের মাঝামাঝি সময়ে ব্যান্ডউইদথকে সীমাবদ্ধতা দেখানো উচিত, শুরু নয়, তবে এটি সর্বদা আরপিসি কলের প্রথম প্যাকেট ... শক্ত একটি।
রায়ান

2

ESXi4.1U1 এবং CentOS ভিএম ব্যবহার করে একই সমস্যার মতো দেখতে আমার কাছে রয়েছে। হোস্টগুলি হ'ল ডেল আর 610, স্টোরেজটি একটি ইএমসি 2 ইসিলন ক্লাস্টার।

আপনি কি ভিএলএনএস ব্যবহার করে কোনও সুযোগেই এসেছিলেন? আমি ভিএমকারেল বন্দরে ভিএলএএন ব্যবহারের জন্য সঞ্চয়স্থানের জন্য দেখতে পেয়েছি কারণ ভিএমহোস্টের সমস্ত স্টোরেজ ট্র্যাফিকের জন্য 4000-5000ms 'হ্যাং' হয়েছে। তবে আমি যদি ভিএমকারেল পোর্টটি ভিএলএএন থেকে সরিয়ে নিয়ে যাই তবে এটি যাতে অবরুদ্ধ প্যাকেট পায় আমি সমস্যাটি দেখতে পাচ্ছি না।

নীচের সাধারণ সেটআপটি আমার নেটওয়ার্কে সমস্যা সৃষ্টি করবে:

1) সার্ভার বা ওয়ার্কস্টেশনে ESXi 4.1U1 ইনস্টল করুন (আমি চেষ্টা করার পরে উভয়ই বিষয়টি প্রদর্শিত হয়েছিল)

2) একটি ভিএলএএন-তে একটি ভিএমকারেল পোর্ট যুক্ত করুন।

3) একটি এনএফএস ডেটাস্টোর যুক্ত করুন (খনিটি একই ভিএলএএন-তে রয়েছে, অর্থাৎ ইসিলন ট্যাগযুক্ত প্যাকেটগুলি গ্রহণ করে)

4) 2 সেন্টস 5.5 ভিএম ইনস্টল করুন, একটি আইওপিং সহ।

5) একক ব্যবহারকারী মোডে বুট করুন ভিএম (যেমন কোনও নেটওয়ার্ক নয়, সর্বনিম্ন পরিষেবাগুলি)

)) একটি মেশিনে আইওপিং চালান যাতে এটি এটি ভার্চুয়াল ডিস্কে লেখা হয়

)) অন্যান্য মেশিনে / ডিএমপি বা অনুরূপ 100MB ডেটা লিখতে ডিডি বা সামসুচ চালান

প্রায়শই না আমি 4-5 সেকেন্ডের জন্য উভয় ভিএম-র হিমাঙ্ক দেখতে পাই।

অন্য কেউ অনুরূপ দেখেছেন কিনা তা দেখতে সত্যিই আগ্রহী হন।


সার্ভার ফল্ট আপনাকে স্বাগতম! এটি একটি পুরানো প্রশ্ন। যদি এর উত্তরগুলি আপনাকে সরাসরি সহায়তা না করে তবে আপনার জিজ্ঞাসা জিজ্ঞাসা বোতামটি ক্লিক করে একটি নতুন নতুন প্রশ্ন জিজ্ঞাসা করা উচিত ।
ব্যবহারকারী 9517 GoFundMonica

হ্যাঁ, অবশ্যই আমি ট্যাগ ভিএলএএন ব্যবহার করছি। যেহেতু আমি এগুলি সর্বত্র ব্যবহার করছি আমি তাদের এই সমস্যার সম্ভাব্য উত্স হিসাবে ভাবিও নি। আমি একটি অবিকৃত বন্দরে পুনরুত্পাদন করার চেষ্টা করতে যাচ্ছি।
exo_cw

আমি এই সমস্যাটি একটি অবিরত বন্দরেও পুনরুত্পাদন করতে পারি, কোনও হোস্টের সাথে জড়িত কোনও ভিএলএএন নেই।
exo_cw

আমি আবার চেষ্টা করছিলাম এবং অবিরত বন্দরেও সমস্যাটি দেখতে পাচ্ছিলাম, এটি একটু কমই ঘন ঘন, সম্ভবত সে কারণেই আমি এটি মিস করেছি। বাম স্টিয়ারের জন্য দুঃখিত। আমি উইন 64৪ বিটে আইওমিটারটি ব্যবহার করে সমস্যাটি দেখতে পাচ্ছি না, আরও মনে হচ্ছে যে আমি সি ব্রাউজ করতে পারি: অন্যান্য লিনাক্স ভিএমএস স্তব্ধ হয়ে রয়েছে। আমি ক্রিস্টাল ডিস্কমার্ক দিয়ে চেষ্টা করতে যাচ্ছি
নিক

আসলে আমি উইন x এক্স 64৪ এর আইওমিটারের সাথে আপনার ফলাফলগুলি দেখতে আগ্রহী। এটি বিলম্বের বিষয়টি পরিমাপ করে তবে আমি প্রাপ্ত সর্বোচ্চ সামগ্রিক চিত্রটি 4000 পড়ার পরীক্ষা ব্যবহার করে 300ms ছিল, 4000 + এমএস নয়
নিক

2

আমরা ঠিক দুই সপ্তাহ আগে একই সমস্যা ছিল। ESX41 U1 এবং নেটঅ্যাপ FAS3170 + এনএফএস ডেটাস্টোর। RHEL5 ভিএম 2 বা 4 সেকেন্ডের জন্য স্তব্ধ থাকে এবং আমরা ভার্চুয়াল কেন্দ্রের পারফরম্যান্স কনসোল থেকে খুব উচ্চ স্পাইক দেখতে পেয়েছি।

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

আমরা দ্বিতীয়টি যা করি তা হ'ল সুইচজে এবং ফাইলারের প্রবাহ নিয়ন্ত্রণ মুছে ফেলা কারণ আমরা সন্দেহ করি যে এটি বিরতি ফ্রেম প্রেরণে সন্দেহ send


1

আপনার ডিএনএস দেখতে কেমন লাগে? আপনার /etc/resolv.confসঠিক? ডিফল্ট সময়সীমাটি 5 সেকেন্ড।

থেকে man resolv.conf

timeout:n
                 sets the amount of time the  resolver  will  wait  for  a
                 response  from  a  remote name server before retrying the
                 query via a different name server.  Measured in  seconds,
                 the default is RES_TIMEOUT (currently 5, see <resolv.h>).

timeout:3আপনার সংযোজন চেষ্টা করুন /etc/resolv.confএবং তারপরে আবার আপনার fsync পরীক্ষা চালান।


আমি এটি এনএফএস সার্ভারে (এই ক্ষেত্রে ওপেনডিয়ানা) এবং ইএসএক্সআই হোস্টে যুক্ত করার চেষ্টা করেছি। দুর্ভাগ্যক্রমে এটি কোনও পার্থক্য করে না। আমি ঠিক মতো সার্ভার ও গেস্ট আইপি সমাধান করতে পারি।
exo_cw

দেখে মনে হচ্ছে আপনি এনএফএস স্ট্রিমের সাথে সম্পর্কিত না হয়ে সমস্ত ট্র্যাফিক ফিল্টার করে ফেলেছেন, আমাদের আরও দেখার প্রয়োজন হতে পারে!
টনি রথ 6'11

@ টনি রথ: আসলে এটিই সেই সময়ের পুরো ট্র্যাফিক। আমি এটি কেবলমাত্র হোস্ট এবং এটিতে এনএফএস-সার্ভারের সাথে একটি পৃথক ভিএসউইচে পরীক্ষা করেছি।
exo_cw

আপনি কি ওয়্যারশার্ক দিয়ে ডিএনএস ফেলতে পারবেন?
জোসেফ কার্ন

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

1

এখানে স্ট্রগুলি আঁকড়ে ধরেছে, তবে আপনি এই সার্ভারগুলিতে কোন এনআইসি ব্যবহার করছেন? স্ট্যাক ওভারফ্লো সিস্টেমেডমিনদের ব্রডকম এনআইসি-র সাথে অদ্ভুত নেটওয়ার্কিংয়ের সমস্যা রয়েছে যা তারা যখন ইন্টেল এনআইসিতে স্যুইচ করেছে তখন চলে গেছে: http://blog.serverfault.com/post/broadcom-die-mutha/


সর্বশেষ পরীক্ষাগুলি কেবল একটি ভিএসউইচ-এ করা হয়েছিল, কোনও শারীরিক নেটওয়ার্ক জড়িত ছিল না (e1000 এবং vmxnet3: কোনও পার্থক্য নেই)। তবে আমি এটি ইন্টেল 82574 এল, ইন্টেল 82576 এল এবং ইন্টেল 82567 এলএফ -3 এও পরীক্ষা করেছি, যা সমস্যাটি দেখায়। আমি এখনও কোনও হার্ডওয়্যার পাইনি যেখানে আমি এটি পুনরুত্পাদন করতে পারি না।
exo_cw

1

এখানে অন্য অনুমান করা যায় ... আপনার আইপিভি 6 কি এক্সএস হোস্টে সক্ষম? যদি হ্যাঁ, তবে এটি বন্ধ করার চেষ্টা করবেন? আমার অভিজ্ঞতা থেকে যদি আপনার পুরো নেটওয়ার্কটি আইপিভি 6 (যেমন আরএডিভি, ডিএইচসিপি 6, ডিএনএস, বিপরীত ডিএনএস) জন্য সঠিকভাবে কনফিগার করা না থাকে তবে এটি কিছু পরিষেবার ক্ষেত্রে সমস্যা হতে পারে। এছাড়াও, নিশ্চিত হয়ে নিন যে এটি এনএফএস সার্ভারে বন্ধ আছে।


আইপিভি 6 ইএসসি হোস্টে ইতিমধ্যে অক্ষম ছিল। আমি এনপিএস সার্ভারে আইপিভি 6 অক্ষম করেছি (ifconfig -a6 এখন খালি), তবে এটি কোনও পার্থক্য রাখে না: এটি একই সমস্যাগুলি দেখায়।
exo_cw
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.