ঠিক আছে, আগ্রহী প্রত্যেকের জন্য,
আমরা কয়েক মাস আগে প্রশ্নটি সমাধান করেছি কেবলমাত্র 3 টি সার্ভারের মধ্যে সরাসরি সংযুক্ত এসএসডি ড্রাইভগুলি ইনস্টল করে, এবং ডিএন ডেটা এবং সান থেকে সেই এসএসডি ড্রাইভে ফাইলগুলি লগ করে moving
আমরা এসএসডি ড্রাইভগুলি ইনস্টল করার সিদ্ধান্ত নেওয়ার আগে, এই সমস্যাটি নিয়ে গবেষণা করার জন্য আমি কী করেছি তার সংক্ষিপ্তসার (এটি এই পোস্টের সমস্ত সুপারিশ ব্যবহার করে):
1) সমস্ত 3 সার্ভারে নিম্নলিখিত ড্রাইভের জন্য পারফমন কাউন্টার সংগ্রহ করা শুরু করেছে:
Disk F:
ল্যামিক ডিস্কটি সান ভিত্তিক, এমডিএফ ডেটা ফাইলগুলি
Disk I:
সান ভিত্তিক লজিকাল ডিস্ক থাকে, এলডিএফ লগ ফাইলগুলি
Disk T:
সরাসরি সংযুক্ত থাকে এসএসডি, কেবলমাত্র টেম্পডিবিতে উত্সর্গীকৃত
নীচের চিত্রটি 2 সপ্তাহের জন্য সংগৃহীত গড় মান
Disk I: (LDF)
এরকম একটি ছোট আইও রয়েছে এবং লেটেন্সি খুব কম, সুতরাং ডিস্ক আই: উপেক্ষা করা যায়
আপনি দেখতে পাচ্ছেন যে Disk T: (TempDB)
এর তুলনায় আরও বড় আইও রয়েছে Disk F: (MDF)
, এবং এটি একই সাথে ল্যাটেন্সির চেয়ে আরও ভাল - 0 এমএস
স্পষ্টতই ডিস্ক এফ-তে কিছু ভুল আছে: যেখানে ডেটা ফাইল থাকে, সেখানে কম আইও থাকা সত্ত্বেও এটির উচ্চতর লেটেন্সি এবং এভ ডিস্ক রাইনের সারি রয়েছে
2) এই ওয়েবসাইট থেকে ক্যোয়ারী ব্যবহার করে স্বতন্ত্র ডাটাবেসের জন্য লেটেন্সি পরীক্ষা করা হয়েছে
https://www.brentozar.com/blitz/slow-storage-reads-writes/
প্রাথমিক সার্ভারে কয়েকটি অ্যাক্টিভ ডাটাবেসে 150-250 এমএসের পাঠের বিলম্ব এবং 150-450 এমএস লেটেন্সি ছিল
কী আকর্ষণীয়, মাস্টার এবং এমএসডিবি ডাটাবেস ফাইলগুলিতে 90 এমএস অবধি ল্যাটেন্সি পড়েছিল যা তাদের ডেটার ছোট আকার এবং কম আইও দেওয়া সন্দেহজনক is আর একটি ইঙ্গিত SAN এর সাথে কিছু ভুল
3) নির্দিষ্ট সময় ছিল না
যার মধ্যে "এসকিউএল সার্ভারটি ঘটনার মুখোমুখি হয়েছে ..." বার্তাগুলি প্রদর্শিত
হয়েছিল যখন এই বার্তাগুলি লগ করা হয়েছিল তখন কোনও রক্ষণাবেক্ষণ বা ডিস্ক ভারী ETL চলছিল না messages
4) উইন্ডোজ ইভেন্ট ভিউয়ার
"এসকিউএল সার্ভারের উপস্থিতি দেখা দিয়েছে ..." ব্যতীত অন্য কোনও এন্ট্রি দেখানো হয়নি যা সমস্যার ইঙ্গিত দেয় would
5) শীর্ষ 10 ক্যোয়ারী চেক করা শুরু করেছে
এসপি_ব্লিটজ ক্যাশে (সিপিইউ, রিডস, ইত্যাদি) থেকে, এবং যেখানে সম্ভব সম্ভব omptimizing
কোনও সুপার আইও ভারী প্রশ্ন যা প্রচুর পরিমাণে ডেটা মন্থন করবে এবং স্টোরেজকে ভারী প্রভাব ফেলবে, যদিও
ডাটাবেসে সূচি ঠিক আছে, আমি এটি বজায় রেখেছি
6) আমাদের SAN টিম নেই
আমাদের কাছে কেবল 1 সিসাদমিন রয়েছে যিনি উপলক্ষ্যে
সান নেটওয়ার্কের পথে সহায়তা করে - এটি মাল্টিপ্যাথযুক্ত, 3 টি সার্ভারের প্রতিটিেরই 2 টি তারের সুইচ এবং তারপরে সান হয়ে যায়, এবং এটি 1 গিগাবাইট / সেকেন্ড বলে মনে করা হয়
7) কোনও ক্রিস্টালডিস্কমার্কের ফলাফল ছিল না
বা সার্ভারগুলি সেট আপ হওয়ার সময় থেকে অন্য কোনও বেঞ্চমার্ক পরীক্ষার ফলাফল, সুতরাং আমি জানি না যে গতিটি কী হওয়া উচিত এবং বর্তমানে এই গতিটি কী হবে তা দেখার জন্য এই মুহুর্তে বেঞ্চমার্ক করা সম্ভব নয়, কারণ এটি উত্পাদনকে প্রভাবিত করেছিল
8) প্রশ্নযুক্ত ডাটাবেসের জন্য চেকপয়েন্ট ইভেন্টে বর্ধিত ইভেন্টস সেশন সেটআপ করুন
এক্সই অধিবেশনটি আবিষ্কার করতে সহায়তা করেছিল যে "এসকিউএল সার্ভারের সময় উপস্থিতিগুলির মুখোমুখি হয়েছে ..." বার্তা, চেকপয়েন্টটি সত্যিই ধীর হয়ে গিয়েছিল (90 সেকেন্ড পর্যন্ত)
9) এসকিউএল সার্ভার ত্রুটি লগ
"ফ্লাশ ক্যাশে" "স্যাচুরেশন" এন্ট্রি ধারণ
করে যখন প্রদত্ত ডাটাবেসের জন্য চেকপয়েন্টের সময় পুনরুদ্ধারের ব্যবধান সেটিংস ছাড়িয়ে যায় তখন এগুলি প্রদর্শিত হবে
বিশদগুলি দেখায় যে চেকপয়েন্টটি ফ্লাশ করার চেষ্টা করছে এমন পরিমাণের পরিমাণ কম এবং এটি সম্পূর্ণ হতে অনেক সময় নিচ্ছে এবং সামগ্রিক গতি প্রায় 0.25 এমবি / সেকেন্ড ... অদ্ভুত
10) অবশেষে, এই ছবিটি স্টোরেজ ট্রাবলশুটিং চার্টটি দেখায়:
দেখা যাচ্ছে আমাদের কেবল একটি "হার্ডওয়্যার সমস্যা: - এসএএন, পুরানো / ত্রুটিযুক্ত ড্রাইভার, নিয়ন্ত্রণকারী, ফার্মওয়্যার ইত্যাদির কোনও ভুল কনফিগারেশন ঠিক করতে সিস্টেম অ্যাডমিন / হার্ডওয়্যার বিক্রেতার সাথে কাজ করুন।"
অন্য একটি প্রশ্নে "স্লো চেকপয়েন্ট ..." ফ্ল্যাশ স্টোরেজে স্লো চেকপয়েন্ট এবং 15 সেকেন্ডের I / O সতর্কতা
শনার সমস্যা সমাধানের জন্য হার্ডওয়্যার এবং সফ্টওয়্যার পর্যায়ে কোন আইটেম চেক করতে হবে তার খুব সুন্দর তালিকা ছিল
আমাদের সিসাদমিন তালিকা থেকে সমস্ত জিনিস পরীক্ষা করতে পারেনি, তাই আমরা কেবলমাত্র এই ইস্যুতে কিছু হার্ডওয়্যার ফেলে দেওয়া বেছে নিই - এটি মোটেই ব্যয়বহুল ছিল না
রেজোলিউশন:
আমরা 1 টিবি এসএসডি ড্রাইভ অর্ডার করেছি এবং সরাসরি সার্ভারে ইনস্টল করেছি
যেহেতু আমাদের উপলভ্যতা দলগুলি রয়েছে, গৌণ প্রতিরূপগুলিতে SAN থেকে এসএসডি-তে স্থানান্তরিত ডিবি ডেটা ফাইলগুলি, অতঃপর ব্যর্থ হয় এবং প্রাইমারি প্রাথমিক ফাইলগুলিতে স্থানান্তরিত ফাইলগুলি ন্যূনতম মোট ডাউনটাইমের জন্য অনুমতি দেয় - 1 মিনিটেরও কম নয়
এখন প্রতিটি সার্ভারের ডিবি ডেটার স্থানীয় অনুলিপি রয়েছে এবং উল্লিখিত এসএএন-এর সাথে সম্পূর্ণ / ডিফ / লগ ব্যাকআপগুলি সম্পন্ন হবে
উইন্ডোজ ইভেন্ট ভিউয়ার লগগুলিতে আর "এসকিউএল সার্ভারের উপস্থিতি ..." বার্তা, এবং ব্যাকআপ, সততা যাচাই, সূচী পুনর্নির্মাণ, প্রশ্নসমূহ ইত্যাদি উল্লেখযোগ্যভাবে বৃদ্ধি পেয়েছে
আমরা ডিবি ফাইলগুলি এসএসডি-তে স্থানান্তরিত করার পর থেকে আইও লেটেনসের ক্ষেত্রে কতটা পারফরম্যান্স উন্নত হয়েছে?
প্রভাব মূল্যায়নের জন্য, ব্যবহৃত পারফরম্যান্স উইন্ডোজ পারফরম্যান্স মনিটরের মাইগ্রেশনের 2 সপ্তাহ আগে এবং মাইগ্রেশনের 4 সপ্তাহ পরে লগ হয়:
এছাড়াও নীচে ডিবি স্তরের ল্যাটেন্সি পরিসংখ্যান তুলনা করা হয়েছে (মাইগ্রেশনের আগে এবং পরে এসকিউএল সার্ভারের ক্যাপচার করা ভার্চুয়াল ফাইলের পরিসংখ্যান ব্যবহৃত হয়েছে)
সারসংক্ষেপ
SAN থেকে সরাসরি সংযুক্ত স্থানীয় এসএসডিগুলিতে স্থানান্তর
এটির পক্ষে মূল্যবান ছিল এটি স্টোরেজটির বিলম্বের উপর দুর্দান্ত প্রভাব ফেলেছিল এবং গড়ে 90% এর বেশি উন্নত হয়েছিল (বিশেষত WRITE অপারেশনস), এবং আমাদের আর আইওতে 20-50 সেকেন্ড স্পাইক নেই do
স্থানীয় এসএসডি-তে সরানো কেবলমাত্র স্টোরেজ কর্মক্ষমতা সম্পর্কিত সমস্যাগুলিই নয় বরং আমি যে ডেটা সুরক্ষার জন্যও উদ্বিগ্ন হয়েছিল তা সমাধান করেছে (যদি SAN ব্যর্থ হয় তবে সমস্ত 3 সার্ভার একই সাথে তাদের ডেটা হারাবে)