আমাদের কাছে ভিএমওয়্যার ভার্চুয়াল মেশিনে এসকিউএল সার্ভার 2016 এসপি 1 চলমান রয়েছে single এটিতে আলাদা আলাদা অ্যাপ্লিকেশনের জন্য 4 টি ডাটাবেস রয়েছে। এই অ্যাপ্লিকেশনগুলি সমস্ত পৃথক ভার্চুয়াল সার্ভারে রয়েছে। এগুলির কোনওটিই এখনও ব্যবহারের জন্য নেই। অ্যাপ্লিকেশনগুলির পরীক্ষা করা লোকেরা কর্মক্ষমতা সম্পর্কিত সমস্যাগুলি প্রতিবেদন করছে।
এগুলি সার্ভারের পরিসংখ্যান:
- 128 জিবি র্যাম (এসকিউএল সার্ভারের জন্য 110 গিগাবাইট সর্বোচ্চ মেমরি)
- 4 কোর @ 4.6 গিগাহার্টজ
- 10 জিবিআইটি নেটওয়ার্ক সংযোগ
- সমস্ত স্টোরেজ এসএসডি ভিত্তিক
- প্রোগ্রাম ফাইল, লগ ফাইল, ডাটাবেস ফাইল এবং টেম্পডিবি সার্ভারের পৃথক পার্টিশনে রয়েছে
- ASD
ব্যবহারকারীরা সি ++ ভিত্তিক ইআরপি অ্যাপ্লিকেশনটির মাধ্যমে একক স্ক্রিন অ্যাক্সেস সম্পাদন করছেন।
যখন আমি মাইক্রোসফ্টের ostressঅনেকগুলি ছোট প্রশ্ন বা একটি বড় কোয়েরি ব্যবহার করে এসকিউএল সার্ভারকে পরীক্ষা করি তখন আমি সর্বোচ্চ কর্মক্ষমতা পাই। থ্রোটলিংয়ের বিষয়টি কেবল ক্লায়েন্ট, কারণ তিনি দ্রুত উত্তর দিতে পারবেন না।
সবেমাত্র যখন কোনও ব্যবহারকারীর উপস্থিতি থাকে তখন এসকিউএল সার্ভার সবেমাত্র কিছু করে। তবুও লোকেরা চিরকাল অপেক্ষা করতে হবে কেবলমাত্র অ্যাপ্লিকেশনটিতে কিছু সংরক্ষণ করতে।
পল রান্ডালের " আমাকে কোথায় এটি ব্যাথা দেয় " জিজ্ঞাসা অনুসারে, সমস্ত অপেক্ষার ইভেন্টের 50% ASYNC_NETWORK_IO।
এর অর্থ হয় কোনও নেটওয়ার্ক সমস্যা, বা অ্যাপ্লিকেশন সার্ভার বা ক্লায়েন্টের সাথে পারফরম্যান্স সমস্যা issue এগুলির কেউই সর্বাধিক ক্ষমতার সাথে তাদের সংস্থানগুলি দূর থেকেও ব্যবহার করছে না। বেশিরভাগ সময় সিপিইউ প্রায় 26% সমস্ত মেশিনে থাকে (ক্লায়েন্ট, অ্যাপসভার, ডিবি সার্ভার)।
নেটওয়ার্ক সংযোগের দেরিটি প্রায় 1-3 মিমি। অ্যাপ্লিকেশনটির সাথে সাধারণ ব্যবহারের সময় ডিবি সার্ভারের আইও সর্বোচ্চ 20MB / গুলি লেখার গতিতে থাকে (গড় 7-9MB / s হয়)। আমি যখন পরীক্ষার উপর চাপ দিই, তখন আমি সর্বোচ্চ 5 গিগাবাইট / সেকেন্ড পাই।
আমাদের ইআরপি সিস্টেমের ডিবি-র জন্য বাফার ক্যাশে আকারটি 60 গিগাবাইট, আমাদের অর্থায়ন সফটওয়্যারটির জন্য 20 গিগাবাইট, মানের নিশ্চয়তা সফটওয়্যারটির জন্য 1 জিবি, নথি সংরক্ষণাগার সিস্টেমের জন্য 3 জিবি।
আমি SQL সার্ভার অ্যাকাউন্ট ব্যবহার করার অধিকার দিয়েছে তাত্ক্ষনিক ফাইল সূচনা । এতে সামান্যতম পারফরম্যান্সও বাড়েনি।
পৃষ্ঠা ব্যবহারের সময়কাল সাধারণ ব্যবহারের সময় প্রায় 15 কে + হয়। ভারী স্ট্রেস টেস্টিংয়ের শেষে .05k এর কাছাকাছি নেমে আসে, যা আশা করা যায়। ব্যাচ / সেকেন্ডটি কাজের চাপের উপর নির্ভর করে প্রায় 2-8k এর কাছাকাছি হয়।
আমি বলব যে ইআরপি অ্যাপ্লিকেশনটি কেবল খারাপভাবে লেখা হয়েছে, তবে সমস্ত অ্যাপ্লিকেশন প্রভাবিত হওয়ার কারণে আমি পারছি না। এমনকি ন্যূনতম কাজের চাপেও।
তবুও আমি কি করতে পারি না কারণ এটি কী কারণে ঘটছে। এই সমস্যা সম্পর্কিত কোনও টিপস, ইঙ্গিত টিউটোরিয়াল, অ্যাপ্লিকেশন, সেরা / সবচেয়ে খারাপ অভ্যাসের নথি বা অন্য যে কোনও জিনিস আপনার মনে আছে?
এগুলি থেকে প্রাপ্ত ফলাফলগুলি sp_BlitzFirst:
আমি এটি 600 সেকেন্ড দৌড়েছি। আমি অ্যাপ্লিকেশনটির একটি উচ্চ কাজের চাপের সময় এটি শুরু করেছি। এটি 1/3 সময় ASYNC_NETWORK_IO। আমিও সঙ্গে নেটওয়ার্ক সংযোগ পরীক্ষা করা NTttcp, PsPing, ipferf3, এবং pathping। অস্বাভাবিক কিছু নয়। প্রতিক্রিয়া সময় সর্বোচ্চ 3 মিমি, গড় 0.3 মিমি। থ্রুপুট প্রায় 1000 এমবি / সেকেন্ডে।
আমার তদন্তের ফলাফল সর্বদা ASYNC_NETWORK_IOএক নম্বর ওয়েস্টস্টটে পরিণত হয়।
আমরা Large-Receive-Offloadভিএমওয়্যারটিতে বৈশিষ্ট্যটি অক্ষম করার ফলাফলটি অনুসন্ধান করেছি । আমরা এখনও পরীক্ষা করছি, তবে ফলাফলগুলি অসঙ্গত বলে মনে হচ্ছে। আমাদের প্রথম 'বেঞ্চমার্ক' এর ফলাফল 19 মিনিটের সময়কালে হয়েছিল (শীর্ষ ফলাফলটি 13 মিনিট যা কেবলমাত্র যখন এসকিউএল সার্ভারের সাথে অ্যাপ্লিকেশনটি ভিএম-তে চলছে তখনই অর্জন করা হয়)। দ্বিতীয় ফলাফলটি 28 মিনিট, যা সত্যিই খারাপ।
আমাদের 'বেঞ্চমার্ক' এর প্রথম ফলাফলটি ছিল 19 মিনিট। যা ভাল. কারণ শীর্ষ ফলাফলটি ছিল 13 মিনিট (যা কেবলমাত্র তখনই অর্জনযোগ্য যখন এসকিউএল সার্ভার নিজেই ভিএম-তে অ্যাপ্লিকেশন বেঞ্চমার্ক হয়)। এটি নেটওয়ার্ক সম্পর্কিত কিছু বিষয়ে দৃ strongly়তার সাথে ইঙ্গিত দেয়। অথবা ভিএমওয়্যার কনফিগারেশন নিয়ে একটি সমস্যা।
আমি বর্তমানে কোন পদ্ধতি ব্যবহার করতে হবে তা নষ্ট করতে ব্যর্থ হয়েছি।
অ্যাপ্লিকেশনটি সর্বাধিক সম্পাদন কেবল তখনই অর্জনযোগ্য যখন অ্যাপ্লিকেশনটি নিজেই এসকিউএল সার্ভারের সাথে ভিএম এ চলছে। যদি অ্যাপ্লিকেশনটি অন্য কোনও ভিএম বা ভার্চুয়াল ডেস্কটপে কার্যকর করা হয় তবে আমাদের বেঞ্চমার্কের সময়কাল তিনগুণ হয়ে যায় (13 মিনিটের সময়কাল থেকে 40 মিনিট বা তার বেশি)। সমস্ত শেষ পয়েন্ট (এসকিউএল সার্ভারের ভিএম, অ্যাপ সার্ভারের ভিএম এবং ভার্চুয়াল ডেস্কটপ) একই শারীরিক হার্ডওয়্যার ব্যবহার করছে। আমরা অন্যান্য সমস্ত শেষ পয়েন্টগুলি অন্য হার্ডওয়্যারে সরিয়ে নিয়েছি।
সম্পাদনা: মনে হচ্ছে সমস্যাটি আবার ফিরে এসেছে। ভারসাম্য থেকে উচ্চ কার্যকারিতা থেকে শক্তি সঞ্চয় মোড সেট করার পরে, আমরা প্রকৃতপক্ষে প্রতিক্রিয়ার সময়গুলি dramtically উন্নত করেছি। তবে আজ আমি 300 সেকেন্ডের নমুনা নিয়ে আবার স্পি_ব্লিটজ ফার্স্ট দৌড়েছি। এটি ফলাফল:
এটি ASYNC_NETWORK_IO এর অপেক্ষার সময়ের দ্বিতীয় সেকেন্ড দেখায় যা sp_blitzfirst চালিত সেকেন্ডের চেয়ে বেশি।