এসকিউএল সার্ভারটি 15 সেকেন্ডের চেয়ে বেশি সময় নেওয়ার ক্ষেত্রে I / O অনুরোধগুলির সম্মুখীন হয়েছে


16

প্রোডাকশন এসকিউএল সার্ভারে, আমাদের নিম্নলিখিত কনফিগার রয়েছে:

3 ডেল পাওয়ারজেজ আর 630 সার্ভারগুলি, উপলভ্যতা গোষ্ঠীতে মিলিত সমস্ত 3 একক ডেল এসএএন স্টোরেজ ইউনিটের সাথে সংযুক্ত যা একটি রেড অ্যারে

সময়ে সময়ে, PRIMARY এ আমরা নীচের মত বার্তাগুলি দেখতে পাচ্ছি:

এসকিউএল সার্ভারের আই / ডি অনুরোধগুলির 11 টি ঘটনার মুখোমুখি হয়েছে ফাইলটি [এফ: [ডেটা \ মাইডাটাবেস.এমডিএফ] ডাটাবেস আইডিতে 8 সেকেন্ডের বেশি সময় নেয়
The ওএস ফাইল হ্যান্ডেলটি 0x0000000000001FBC BC
সর্বশেষতম I / O এর অফসেটটি হল: 0x000004295d0000।
দীর্ঘ I / O এর সময়কাল: 37397 এমএস।

পারফরম্যান্স ট্রাবলশুটিংয়ে আমরা নবজাতক

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



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

@ ম্যাক্স ভার্নন নো, এসকিউএল সার্ভার ভিএম এর ভিতরে নেই; তবে হাইপার-ভি ভূমিকা এই সার্ভারগুলিতে ইনস্টল করা হয়েছে কারণ তারা কয়েকটি ছোট ভিএম (আইআইএস ওয়েব সার্ভার) হোস্ট করছে ... এই ক্ষেত্রে হাইপারভাইজার সেটিংস পরীক্ষা করে নেওয়া দরকার কি?
আলেক্সি ভিটকো

উত্তর:


15

আমাদের অনুরূপ সেটআপ রয়েছে এবং লগগুলিতে এই বার্তাগুলির মুখোমুখি হয়েছিল। আমরা একটি ডেল কম্পাইলেন্ট সান ব্যবহার করছি। এই বার্তাগুলি গ্রহণ করার সময় এখানে কিছু জিনিস যা আমাদের সমাধান খুঁজে পেতে সহায়তা করে check

  • আপনার ডিস্কগুলির জন্য আপনার উইন্ডোজ পারফরম্যান্স কাউন্টারগুলি পর্যালোচনা করুন যা সতর্কতা বার্তাগুলি নির্দেশ করছে, বিশেষত:
    • ডিস্ক গড় সময় পড়ুন
    • ডিস্ক গড় সময় লিখুন
    • ডিস্ক পড়া বাইট / সেকেন্ড
    • ডিস্ক লেখার বাইট / সেকেন্ড
    • ডিস্ক স্থানান্তর / সেকেন্ড
    • গড়। ডিস্কের সারির দৈর্ঘ্য
  • উপরের গড় হয়। আপনার যদি এক ড্রাইভে অনেকগুলি ডাটাবেস ফাইল থাকে তবে এই গড়গুলি ফলাফলটি স্কিউ করতে পারে এবং নির্দিষ্ট ডাটাবেস ফাইলগুলিতে বোতল ঘাড়টি মাস্ক করতে পারে। পল এস রেন্ডাল থেকে এই কোয়েরিটি দেখুন যা ডিএমভি থেকে প্রতিটি ফাইলের জন্য গড় বিলম্বিত করে sys.dm_io_virtual_file_stats। আমাদের ক্ষেত্রে গড় বিলম্বিত প্রতিবেদনটি গ্রহণযোগ্য ছিল তবে কভারগুলির নীচে আমাদের> 200 এমএস গড় বিলম্বিত অনেকগুলি ফাইল ছিল had
  • সময় পরীক্ষা করুন। কোন প্যাটার্ন আছে? রাতের নির্দিষ্ট সময়ে এটি কি আরও ঘন ঘন ঘটে? যদি তা পরীক্ষা করে থাকে যে কোনও রক্ষণাবেক্ষণ কাজ সেই সময়ে চলছে বা কোনও নির্ধারিত কার্যকলাপ যা ডিস্ক ক্রিয়াকলাপ বাড়িয়ে তুলতে পারে এবং আপনার আইও সাবসিস্টেমের বোতল ঘাড় উন্মোচিত করতে পারে।
  • ত্রুটির জন্য উইন্ডোজ ইভেন্ট ভিউয়ারটি পরীক্ষা করুন। আপনার অ্যাপ্লিকেশনটির জন্য যদি আপনার স্যুইচ বা সান অতিরিক্ত লোড হচ্ছে বা সঠিকভাবে সেটআপ না করা থাকে তবে আপনি এই লগটিতে কিছু বার্তা পেতে পারেন এবং এই তথ্যটি আপনার সান প্রশাসকের কাছে নেওয়া ভাল is আমাদের ক্ষেত্রে আমরা সমস্যাটি ইঙ্গিত করে সারা দিন প্রায়শই iSCSI সংযোগ ত্রুটি পেয়েছি।
  • আপনার এসকিউএল সার্ভার কোডটি পর্যালোচনা করুন। আপনি এই বার্তাগুলি গ্রহণ করার পরে অবিলম্বে এটি কোনও আইও সাবসিস্টেম সমস্যা বলে মনে করা উচিত নয় এবং এটি আপনার SAN প্রশাসকের কাছে প্রেরণ করা উচিত। আপনার নিজের অংশটি করা এবং ডাটাবেস পর্যালোচনা করা দরকার। আপনার কি সত্যিই খারাপ প্রশ্নগুলি প্রায়শই টন ডেটার মাধ্যমে মন্থন করা হয়? খারাপ ইনডেক্সিং? অতিরিক্ত লেনদেনের লগ লিখছেন? আপনার ডাটাবেসে স্বাস্থ্য পরীক্ষা করতে আপনি কিছু ওপেন সোর্স ক্যোয়ারী ব্যবহার করতে পারেন, আপনার ক্যোয়ারী প্ল্যানটি কেমন দেখাচ্ছে তা যাচাই করার জন্য উদাহরণ sp_blitzCache
  • এগুলি উপেক্ষা করবেন না। আজ আপনি হয়ত এগুলিকে দিনে কয়েকবার পেয়ে যাচ্ছেন ... তারপরে কয়েক মাস পরে যখন আপনার কাজের চাপ বাড়বে এবং আপনি সেগুলি নিরীক্ষণ করতে ভুলে গিয়েছিলেন যে তারা বাড়তে শুরু করে। এই বার্তাগুলির প্রচুর প্রাপ্তি এসকিউএল সার্ভারকে একটি নির্দিষ্ট ফাইল অ্যাক্সেস করা থেকে আটকাতে পারে এবং যদি এটি টেম্পডিবি হয় তবে এটি ভাল নয়। আমাদের ক্ষেত্রে এটি এতই খারাপ হয়ে গেছে যে এসকিউএল সার্ভার নিজেই বন্ধ হয়ে যায়।

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

আপগ্রেড করার সাথে সাথেই, আইএসসিএসআই ত্রুটিগুলি চলে গিয়েছিল এবং সমস্ত ফাইলের জন্য গড় বিলম্বিতা প্রায় 50 এমএসে নেমে আসে এবং এটি অ্যাপ্লিকেশনটিতে আরও ভাল পারফরম্যান্সের সাথে সম্পর্কিত। আশা করি এই বিষয়গুলি মনে রেখে আপনি সমাধানটি সন্ধান করতে পারেন।


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

এটি সঠিক শান। আপনার পরামর্শ অনুসারে আমি আরও কিছু তথ্য যুক্ত করতে সক্ষম হব, আমি আমার উত্তরটি একসাথে রাখার পরে আপডেট করব।
কেভিনহীন

26

এটি প্রায়শই একটি ডিস্ক ইস্যু এবং প্রায়শই একটি নেটওয়ার্কিং সমস্যা। আপনি জানেন, সান মধ্যে এন?

আপনি যদি নিজের সান দলে যান এবং ডিস্কগুলি ধীর হয়ে যাওয়ার বিষয়ে কথা বলতে শুরু করেন, তারা আপনাকে এটিতে 0 মিলিসেকেন্ড বিলম্বিত করে একটি অভিনব গ্রাফ প্রদর্শন করবে এবং তারপরে আপনাকে একটি স্ট্যাপলারটি নির্দেশ করবে।

পরিবর্তে, তাদের সান নেটওয়ার্কের পথ সম্পর্কে জিজ্ঞাসা করুন। গতি পান, যদি এটি বহুপাঠ হয় ইত্যাদি etc. আপনার যে গতিটি দেখা উচিত সেগুলি সম্পর্কে তাদের কাছ থেকে নম্বর পান। যখন সার্ভারগুলি সেট আপ হয়েছিল তখন থেকেই তাদের কাছে বেঞ্চমার্ক রয়েছে কিনা জিজ্ঞাসা করুন।

তারপরে আপনি সেই গতি বৈধ করতে ক্রিস্টাল ডিস্ক মার্ক বা ডিস্কপিডি ব্যবহার করতে পারেন । যদি তারা লাইন না ধরে, আবার, সম্ভবত নেটওয়ার্কিং।

"ফ্লাশক্যাচ" এবং "স্যাচুরেশন" থাকা বার্তাগুলির জন্য আপনার ত্রুটি লগটিও অনুসন্ধান করা উচিত, কারণ সেগুলিও নেটওয়ার্ক যুক্তির লক্ষণ হতে পারে।

ডিবিএ হিসাবে এই জিনিসগুলি এড়াতে আপনি যা করতে পারেন তা হ'ল নিশ্চিত করুন যে আপনার রক্ষণাবেক্ষণ এবং অন্য কোনও ডেটা-ভারী কাজ (যেমন ইটিএল) একই সময়ে চলছে না। এটি অবশ্যই স্টোরেজ নেটওয়ার্কিংয়ে প্রচুর চাপ চাপতে পারে।

আরও পরামর্শগুলির জন্য আপনি এখানে উত্তরগুলিও দেখতে চাইতে পারেন: ফ্ল্যাশ স্টোরেজে ধীর চেকপয়েন্ট এবং 15 সেকেন্ডের I / O সতর্কতা

আমি এখানে একটি অনুরূপ বিষয় সম্পর্কে ব্লগ করেছি: সার্ভার থেকে সান পর্যন্ত To


8

কেন একটি SAN- তে ডেটা সংরক্ষণ করা হচ্ছে? আলোচ্য বিষয়টি কি? সমস্ত ডাটাবেস কর্মক্ষমতা ডিস্ক I / O- এ আবদ্ধ এবং আপনি তাদের পিছনে I / O এর জন্য কেবল একটি ডিভাইস সহ 3 টি সার্ভার ব্যবহার করছেন। এটি কোনও তাত্পর্যপূর্ণ নয় ... এবং দুর্ভাগ্যক্রমে এত সাধারণ।

আমি আমার জীবনটি খারাপভাবে ডিজাইন করা হার্ডওয়্যার প্ল্যাটফর্মের সাথে কাটিয়েছি যেখানে লোকেরা কেবলমাত্র একটি বৃহত স্কেল কম্পিউটার ডিজাইন করার চেষ্টা করে। এখানে সমস্ত সিপিইউ শক্তি, সমস্ত ডিস্ক রয়েছে ... আশা করি দূরবর্তী র্যামের মতো জিনিস নেই। এবং সবচেয়ে দুঃখের বিষয় তারা এই ডিজাইনের দক্ষতার অভাবকে বিশাল সার্ভার দিয়ে ক্ষতিপূরণ করে যার জন্য তাদের চেয়ে দশগুণ বেশি খরচ হয় cost আমি k 1k ল্যাপটপের চেয়ে ধীরে ধীরে 400k ra ইনফ্রা দেখেছি।

একটি এসকিউএল সার্ভার সফ্টওয়্যারটি একটি অত্যন্ত উন্নত সফ্টওয়্যার, এটি কোনও হার্ডওয়ার, সিপিইউ কোর, সিপিইউ ক্যাশে, টিএলবি, র‌্যাম, ডিস্ক নিয়ন্ত্রক, হার্ড ড্রাইভ ক্যাশে সুবিধা গ্রহণের জন্য ডিজাইন করা হয়েছে ... এগুলিতে প্রায় সমস্ত ফাইল সিস্টেম যুক্তি যুক্ত রয়েছে। এগুলি নিয়মিত কম্পিউটারে উন্নত এবং উচ্চ প্রান্তের সিস্টেমে বেঞ্চমার্কযুক্ত। এরপরে একটি এসকিউএল সার্ভারের নিজস্ব ডিস্ক থাকা উচিত। এসএএন এ সেগুলি ইনস্টল করা কোনও কম্পিউটারকে "অনুকরণ" করার মতো, আপনি সমস্ত কর্মক্ষমতা অপটিমাইজেশন হারাবেন। সানগুলি ব্যাকআপ, অপরিবর্তনীয় ফাইল এবং যে ফাইলগুলি সবেমাত্র (লগগুলিতে ডেটা সংযুক্ত করে) সংরক্ষণের জন্য are

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

আপনি মন্তব্যে বলেছেন, আপনি আপনার সার্ভারে এসএসডি রাখার বিষয়ে বিবেচনা করছেন। আপনি SAN এর সাথে তুলনা করে ডেডিকেটেড এসএসডি সহ আপনার সেটআপটি চিনতে পারবেন না আপনি একই ড্রাইভে থাকা ডেটা এবং লেনদেন লগ ফাইলগুলির সাথেও 500x উন্নতির মতো কিছু পাবেন। আর্ট এসকিউএল সার্ভারের একটি স্থিতিতে বিভিন্ন হার্ডওয়্যার নিয়ামক চ্যানেলগুলিতে ডেটা এবং লেনদেনের লগের জন্য দ্রুত পৃথক এসএসডি থাকবে (বেশিরভাগ সার্ভারের মাদারবোর্ড বেশ কয়েকটি রয়েছে)। তবে আপনার বর্তমান সেটআপের তুলনায় আমরা সেখানে সায়েন্স-ফাইয়ের কথা বলছি। এসএসডি একবার চেষ্টা করে দেখুন।


1
এটি আমাকে একই প্রতিস্থাপনের পরিবর্তে সমস্ত 3 এর পরিবর্তে প্রতিটি প্রতিলিপি (ডেটা ফাইলগুলির জন্য, লগ ফাইলগুলির জন্যও) ডেডিকেটেড এসএসডি ড্রাইভ কেনার ধারণা সম্পর্কে আবার ভাবতে বাধ্য করে। উপরের অন্যান্য ছেলেরা পোস্ট করা সমস্ত আইটেম আমি ধীরে ধীরে ডাবল করে যাচ্ছি
আলেক্সি ভিটস্কো

2

ঠিক আছে, আগ্রহী প্রত্যেকের জন্য,

আমরা কয়েক মাস আগে প্রশ্নটি সমাধান করেছি কেবলমাত্র 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) অবশেষে, এই ছবিটি স্টোরেজ ট্রাবলশুটিং চার্টটি দেখায়:

ধীর ডিস্ক IO সমস্যা সমাধানের পদক্ষেপ

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

অন্য একটি প্রশ্নে "স্লো চেকপয়েন্ট ..." ফ্ল্যাশ স্টোরেজে স্লো চেকপয়েন্ট এবং 15 সেকেন্ডের I / O সতর্কতা শনার সমস্যা সমাধানের জন্য হার্ডওয়্যার এবং সফ্টওয়্যার পর্যায়ে কোন আইটেম চেক করতে হবে তার খুব সুন্দর তালিকা ছিল

আমাদের সিসাদমিন তালিকা থেকে সমস্ত জিনিস পরীক্ষা করতে পারেনি, তাই আমরা কেবলমাত্র এই ইস্যুতে কিছু হার্ডওয়্যার ফেলে দেওয়া বেছে নিই - এটি মোটেই ব্যয়বহুল ছিল না

রেজোলিউশন:

আমরা 1 টিবি এসএসডি ড্রাইভ অর্ডার করেছি এবং সরাসরি সার্ভারে ইনস্টল করেছি

যেহেতু আমাদের উপলভ্যতা দলগুলি রয়েছে, গৌণ প্রতিরূপগুলিতে SAN থেকে এসএসডি-তে স্থানান্তরিত ডিবি ডেটা ফাইলগুলি, অতঃপর ব্যর্থ হয় এবং প্রাইমারি প্রাথমিক ফাইলগুলিতে স্থানান্তরিত ফাইলগুলি ন্যূনতম মোট ডাউনটাইমের জন্য অনুমতি দেয় - 1 মিনিটেরও কম নয়

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

আমরা ডিবি ফাইলগুলি এসএসডি-তে স্থানান্তরিত করার পর থেকে আইও লেটেনসের ক্ষেত্রে কতটা পারফরম্যান্স উন্নত হয়েছে?

প্রভাব মূল্যায়নের জন্য, ব্যবহৃত পারফরম্যান্স উইন্ডোজ পারফরম্যান্স মনিটরের মাইগ্রেশনের 2 সপ্তাহ আগে এবং মাইগ্রেশনের 4 সপ্তাহ পরে লগ হয়:

উইন্ডোজ পারফরম্যান্স মনিটর ডিস্ক লেটেন্সি মেট্রিক্স

এছাড়াও নীচে ডিবি স্তরের ল্যাটেন্সি পরিসংখ্যান তুলনা করা হয়েছে (মাইগ্রেশনের আগে এবং পরে এসকিউএল সার্ভারের ক্যাপচার করা ভার্চুয়াল ফাইলের পরিসংখ্যান ব্যবহৃত হয়েছে)

এসকিউএল সার্ভার ভার্চুয়াল ফাইলের পরিসংখ্যান

সারসংক্ষেপ

SAN থেকে সরাসরি সংযুক্ত স্থানীয় এসএসডিগুলিতে স্থানান্তর
এটির পক্ষে মূল্যবান ছিল এটি স্টোরেজটির বিলম্বের উপর দুর্দান্ত প্রভাব ফেলেছিল এবং গড়ে 90% এর বেশি উন্নত হয়েছিল (বিশেষত WRITE অপারেশনস), এবং আমাদের আর আইওতে 20-50 সেকেন্ড স্পাইক নেই do

স্থানীয় এসএসডি-তে সরানো কেবলমাত্র স্টোরেজ কর্মক্ষমতা সম্পর্কিত সমস্যাগুলিই নয় বরং আমি যে ডেটা সুরক্ষার জন্যও উদ্বিগ্ন হয়েছিল তা সমাধান করেছে (যদি SAN ব্যর্থ হয় তবে সমস্ত 3 সার্ভার একই সাথে তাদের ডেটা হারাবে)

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