সাধারণত আমাদের সাপ্তাহিক ফুল ব্যাকআপগুলি প্রায় 35 মিনিটের মধ্যে শেষ হয়, প্রতিদিনের ডিফ ব্যাকআপগুলি 5 মিনিটের মধ্যে শেষ হয়। মঙ্গলবার থেকে দৈনিকগুলি সম্পূর্ণ করতে প্রায় 4 ঘন্টা সময় নিয়েছে, প্রয়োজনের চেয়ে আরও বেশি উপায়। কাকতালীয়ভাবে, আমরা একটি নতুন SAN / ডিস্ক কনফিগার পাওয়ার ঠিক পরে এটি ঘটতে শুরু করে।
নোট করুন যে সার্ভারটি উত্পাদন চলছে এবং আমাদের কোনও সামগ্রিক সমস্যা নেই, এটি সুচারুভাবে চলছে - আইও ইস্যু ব্যতীত যা প্রাথমিকভাবে ব্যাকআপ কার্য সম্পাদনে প্রকাশিত হয়।
ব্যাকআপের সময় dm_exec_requests এ খুঁজছেন, ব্যাকআপটি নিয়মিত ASYNC_IO_COMPLETION এ অপেক্ষা করছে। আহা, তাই আমাদের ডিস্ক কনটেন্ট আছে!
তবে এমডিএফ (লগগুলি স্থানীয় ডিস্কে সঞ্চিত থাকে) বা ব্যাকআপ ড্রাইভে কোনও ক্রিয়াকলাপ নেই (আইওপিএস 0 = 0 - আমাদের প্রচুর স্মৃতি রয়েছে)। ডিস্কের সারির দৈর্ঘ্য = 0 সিপিইউ প্রায় ২-৩% ঘোরাফেরা করে, কোনও সমস্যা নেই।
SAN হ'ল একটি ডেল MD3220i, 6X10 কে এসএএস ড্রাইভ সমন্বিত LUN। সার্ভারটি দুটি শারীরিক পাথের মাধ্যমে SAN এর সাথে সংযুক্ত রয়েছে, প্রত্যেকে SAN এর সাথে রিডানড্যান্ট সংযোগের সাথে একটি পৃথক সুইচ দিয়ে চলেছে - মোট চারটি পথ, এর মধ্যে দুটি যে কোনও সময় সক্রিয় রয়েছে। আমি যাচাই করতে পারি যে দুটি সংযোগই টাস্ক ম্যানেজারের মাধ্যমে সক্রিয় রয়েছে - লোডকে পুরোপুরি সমানভাবে বিভক্ত করে। দুটি সংযোগই 1 জি পূর্ণ দ্বৈত চলছে।
আমরা জাম্বো ফ্রেম ব্যবহার করতাম, তবে আমি এখানে কোনও সমস্যা বাতিল করতে তাদের অক্ষম করে রেখেছি - কোনও পরিবর্তন নেই। আমাদের অন্য একটি সার্ভার রয়েছে (একই ওএস + কনফিগারেশন, ২০০৮ আর 2) যা অন্যান্য এলইউএনগুলির সাথে সংযুক্ত এবং এটি কোনও সমস্যা দেখায় না। এটি এসকিউএল সার্ভার চালাচ্ছে না, তবে কেবল তাদের শীর্ষে সিআইএফএস ভাগ করছে। যাইহোক, এর অন্যতম LUNs পছন্দের পথটি ঝামেলা LUNs হিসাবে একই সান নিয়ন্ত্রকের উপর রয়েছে - তাই আমি এটিকেও রায় দিয়েছি।
বেশ কয়েকটি এসকিউআইওও পরীক্ষা চালানো (10 জি টেস্ট ফাইল) মনে হচ্ছে যে সমস্যাগুলি সত্ত্বেও আইও ভদ্র is
sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec: 3582.20
MBs/sec: 27.98
Min_Latency(ms): 0
Avg_Latency(ms): 3
Max_Latency(ms): 98
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 45 9 5 4 4 4 4 4 4 3 2 2 1 1 1 1 1 1 1 0 0 0 0 0 2
sqlio -kW -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec: 4742.16
MBs/sec: 37.04
Min_Latency(ms): 0
Avg_Latency(ms): 2
Max_Latency(ms): 880
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 46 33 2 2 2 2 2 2 2 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 1
sqlio -kR -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec: 1824.60
MBs/sec: 114.03
Min_Latency(ms): 0
Avg_Latency(ms): 8
Max_Latency(ms): 421
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 1 3 14 4 14 43 4 2 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 6
sqlio -kW -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec: 3238.88
MBs/sec: 202.43
Min_Latency(ms): 1
Avg_Latency(ms): 4
Max_Latency(ms): 62
histogram:
ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 0 0 0 9 51 31 6 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0আমি বুঝতে পারি যে এগুলি কোনওভাবেই নিখরচায় পরীক্ষা নয়, তবে তারা এটি জঞ্জাল নয় বলে জেনে আমাকে স্বাচ্ছন্দ্য বোধ করে। নোট করুন যে উচ্চতর রচনার পারফরম্যান্স দুটি সক্রিয় MPIO পাথের কারণে হয়, তবে পঠন কেবল তাদের মধ্যে একটির ব্যবহার করবে।
অ্যাপ্লিকেশন ইভেন্টের লগ চেক করা চারদিকে ছড়িয়ে ছিটিয়ে থাকা এই জাতীয় ইভেন্টগুলি প্রকাশ করে:
SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [J:\XXX.mdf] in database [XXX] (150). The OS file handle is 0x0000000000003294. The offset of the latest long I/O is: 0x00000033da0000এগুলি স্থির নয়, তবে তারা নিয়মিত ঘটে (ব্যাকআপের সময় কয়েক ঘন্টা, আরও কিছু)। এই ইভেন্টের পাশাপাশি, সিস্টেম ইভেন্ট লগ এগুলি পোস্ট করবে:
Initiator sent a task management command to reset the target. The target name is given in the dump data.
Target did not respond in time for a SCSI request. The CDB is given in the dump data.এগুলি একই SAN / কন্ট্রোলারে চালিত অ-সমস্যাযুক্ত সিআইএফএস সার্ভারে ঘটে এবং আমার গুগলিং থেকে তারা মনে হয় এটি সমালোচনামূলক নয়।
নোট করুন যে সমস্ত সার্ভারগুলি একই এনআইসি ব্যবহার করে - ব্রডকম 5709 সি-তে আপ-টু-ডেট ড্রাইভার রয়েছে। সার্ভারগুলি নিজেরাই ডেল আর 610 এর।
আমি নিশ্চিত না পরবর্তী কি পরীক্ষা করা উচিত। কোন পরামর্শ?
আপডেট - পারফমন চলমান
আমি গড় রেকর্ড করার চেষ্টা করেছি। ব্যাকআপ সম্পাদন করার সময় ডিস্ক সেকেন্ড / পড়ুন এবং নিখুঁত কাউন্টারগুলি লিখুন। ব্যাকআপটি চমকপ্রদভাবে শুরু হয় এবং তারপরে মূলত মৃতদেহটি 50% এ থামে, ধীরে ধীরে 100% এর দিকে ক্রল করে, তবে 20x সময় লাগলে এটি হওয়া উচিত।
দুটি SAN পাথ ব্যবহার করা হচ্ছে, তারপরে ছেড়ে দেওয়া দেখায়।
ব্যাকআপ 15:38:50 প্রায় শুরু হয়েছিল - সমস্ত ভাল দেখাচ্ছে লক্ষ্য করুন, এবং তারপরে একটি শিখর রয়েছে। আমি লেখকদের সাথে উদ্বিগ্ন নই, কেবল পাঠ্যগুলি স্তব্ধ বলে মনে হচ্ছে।
চালু / বন্ধ খুব কম অ্যাকশন নোট করুন, যদিও খুব শেষের দিকে জ্বলজ্বলে পারফরম্যান্স।
সর্বোচ্চ 12 সেকেন্ড নোট করুন, যদিও সামগ্রিকভাবে গড় ভাল।
আপডেট - NUL ডিভাইসে ব্যাক আপ নেওয়া
পঠন সমস্যাগুলি আলাদা করতে এবং জিনিসগুলি সহজ করার জন্য, আমি নিম্নলিখিতগুলি চালিত করেছি:
BACKUP DATABASE XXX TO DISK = 'NUL'ফলাফলগুলি হুবহু একই ছিল - একটি ফেটে পড়া দিয়ে শুরু হয় এবং তারপরে স্টলগুলি শুরু হয় এবং এখন এবং তারপরে পুনরায় কার্যক্রম শুরু করা হচ্ছে:
আপডেট - আইও স্টলগুলি শন দ্বারা প্রস্তাবিত
আমি জোনাথন কেহায়িয়াস এবং টেড ক্রুয়েজার্স বই (29 পৃষ্ঠা) থেকে dm_io_virtual_file_stats কোয়েরি চালিয়েছি । উপরের 25 টি ফাইলের (প্রতিটি ফাইলের জন্য একটি ফাইল ফাইল - সমস্ত ফলাফল ডেটা ফাইল হিসাবে দেখা যায়) দেখে মনে হবে পাঠকরা লেখার চেয়ে আরও খারাপ are সম্ভবত কারণ লেখাগুলি সরাসরি সান ক্যাশে চলেছে যেখানে শীত পড়ার ক্ষেত্রে ডিস্ককে আঘাত করা দরকার - যদিও এটি একটি অনুমান ।
আপডেট -
অপেক্ষার পরিসংখ্যান কিছু অপেক্ষার পরিসংখ্যান সংগ্রহ করার জন্য আমি তিনটি পরীক্ষা করেছি। অপেক্ষার পরিসংখ্যানগুলি গ্লেন বেরি / পল র্যান্ডেলস স্ক্রিপ্ট ব্যবহার করে জিজ্ঞাসা করা হয় । এবং কেবল তা নিশ্চিত করার জন্য - ব্যাকআপগুলি টেপ করা হচ্ছে না, তবে একটি আইএসসিএসআই লুনে করা হচ্ছে। স্থানীয় ডিস্কের সাথে করা ফলাফলগুলি একই রকম হয়, ফলাফলগুলি NUL ব্যাকআপের মতো।
পরিসংখ্যান পরিস্কার 10 মিনিটের জন্য দৌড়ে, সাধারণ বোঝা:
পরিসংখ্যান পরিস্কার 10 মিনিটের জন্য দৌড়ে, সাধারণ লোড + সাধারণ ব্যাকআপ চলছে (সম্পূর্ণ হয়নি):
পরিসংখ্যান পরিস্কার 10 মিনিটের জন্য দৌড়ে, সাধারণ লোড + এন ইউ এল ব্যাকআপ চলছে (সম্পূর্ণ হয়নি):
আপডেট - ডাব্লুটিএফ, ব্রডকম?
মার্ক স্টোরি-স্মিথের পরামর্শ এবং কাইল ব্র্যান্ডস ব্রডকম এনআইসির সাথে পূর্ববর্তী অভিজ্ঞতার ভিত্তিতে, আমি কিছু পরীক্ষা-নিরীক্ষা করার সিদ্ধান্ত নিয়েছি। যেহেতু আমরা একাধিক সক্রিয় পাথ পেয়েছি, আমি সহজেই কোনও ছাড় ছাড়াই এনআইসির কনফিগারেশনটি সহজেই পরিবর্তন করতে পারি change
TOE অক্ষম করা এবং বৃহত প্রেরণ অফলোড একটি নিখুঁত নিখুঁত রান পেয়েছিল:
Processed 1064672 pages for database 'XXX', file 'XXX' on file 1.
Processed 21 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064693 pages in 58.533 seconds (142.106 MB/sec).তাহলে অপরাধী, টো বা এলএসও কোনটি? TOE সক্ষম, LSO অক্ষম:
Didn't finish the backup as it took forever - just as the original problem!TOE অক্ষম, LSO সক্ষম - ভাল দেখাচ্ছে:
Processed 1064680 pages for database 'XXX', file 'XXX' on file 1.
Processed 29 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064709 pages in 59.073 seconds (140.809 MB/sec).এবং নিয়ন্ত্রণ হিসাবে, আমি সমস্যাটি চলে গেছে তা নিশ্চিত করতে আমি TOE এবং LSO উভয়কেই অক্ষম করেছিলাম:
Processed 1064720 pages for database 'XXX', file 'XXX' on file 1.
Processed 13 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064733 pages in 60.675 seconds (137.094 MB/sec).উপসংহারে মনে হয় এটি সক্ষম ব্রডকম এনআইসিসি টিসিপি অফলোড ইঞ্জিন সমস্যা তৈরি করেছে। TOE অক্ষম হওয়ার সাথে সাথে সমস্ত কিছুই কবজির মতো কাজ করেছিল। অনুমান করুন আমি আর কোনও ব্রডকম এনআইসিকে এগিয়ে যাওয়ার আদেশ দেব না।
আপডেট - ডাউন সিআইএফএস সার্ভারে যায়
আজ একইরকম এবং কার্যকারী সিআইএফএস সার্ভার আইও অনুরোধগুলি হ্যাং প্রদর্শন করা শুরু করে। এই সার্ভারটি এসকিউএল সার্ভার চালাচ্ছিল না, কেবল উইন্ডোজ ওয়েব সার্ভার ২০০ R আর -২ সিআইএফএস-এর উপর শেয়ার পরিবেশন করছে। এটির সাথে সাথে আমি এখানে অক্ষম করার সাথে সাথে সমস্ত কিছু মসৃণ চলতে ফিরে আসল।
কেবলমাত্র আমি নিশ্চিত হয়েছি যে আমি ব্রডকম এনআইসি-তে আর কখনও টোই ব্যবহার করব না, যদি আমি ব্রডকম এনআইসিগুলি এড়াতে না পারি তবে তা।