অ্যাপ্লিকেশন খালি সারণী জিজ্ঞাসা করছে

Question

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

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

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

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

আমরা অ্যাপ্লিকেশনটির জন্য এসকিউএল সার্ভার 2008 আর 2, ওরাকল ওয়েবলোগিক 11 জি ব্যবহার করি।

@ ফিসবি- দীর্ঘ গল্পের সংক্ষিপ্ত, আমি কোয়েরিেক্সটেক্সটযুক্ত একটি টেবিল তৈরি করেছি যা অ্যাপ্লিকেশনটির ডাটাবেসে খালি টেবিলগুলিতে আঘাত করে, তারপরে এটি আমার জানা সমস্ত টেবিলের নাম খালি রয়েছে এবং এটি একটি দীর্ঘ দীর্ঘ তালিকা পেয়েছে। সর্বোচ্চ হিটটি আপটাইমের 30 দিনের মধ্যে ২. 2. মিলিয়ন মৃত্যুদন্ড কার্যকর করা হয়েছিল, মনে রাখবেন অ্যাপটি সাধারণত সকাল -6-০০ টা থেকে সন্ধ্যা -6- .০ পর্যন্ত ব্যবহার হয় তাই এই সংখ্যাগুলি অপারেটিং সময়গুলিতে আরও বেশি কেন্দ্রীভূত হয়। একাধিক সারণী, একাধিক ক্যোয়ারী, সম্ভবত কিছু সম্পর্কিত সম্পর্কিত যোগ দেয়, কিছু না। শীর্ষ হিট (সেই সময়ে ২.7 মিলিয়ন) একক ফাঁকা টেবিল থেকে একটি সহজ নির্বাচন ছিল যেখানে ক্লজ, কোনও যোগ দেয় না। আমি আশা করব যে খালি টেবিলগুলিতে যোগদানের সাথে আরও বড় প্রশ্নগুলি লিঙ্কযুক্ত টেবিলগুলিতে আপডেটগুলি অন্তর্ভুক্ত করতে পারে তবে আমি এটি যাচাই করব এবং এই প্রশ্নটি ঠিক ততই আপডেট করব।

আপডেট: 1043 - 4622614 (2.5 মাসেরও বেশি) এর মধ্যে একটি নির্বাহের গণনা সহ 1000 টি ক্যোয়ারী রয়েছে। ক্যাশেড পরিকল্পনাটি কখন থেকে উত্পন্ন হয়েছে তা জানতে আমাকে আরও খনন করতে হবে। এটি কেবল আপনাকে প্রশ্নের পরিমাণ সম্পর্কে ধারণা দেওয়ার জন্য। বেশিরভাগই 20 টিরও বেশি যোগদানের সাথে যুক্তিসঙ্গতভাবে জটিল।

@ শ্রুতজকি- হ্যাঁ আমি বিশ্বাস করি যে পরিকল্পনাটি সংকলিত হওয়ার সাথে সাথে সম্পর্কিত একটি তারিখ কলাম রয়েছে যাতে এটি আগ্রহী হবে, তাই আমি এটি পরীক্ষা করে দেখব। আমি ভাবছি যখন এসকিউএল সার্ভার কোনও ভিএমওয়্যার ক্লাস্টারে বসে থাকে তখন থ্রেড সীমাগুলি কি কোনও কারণ হয়ে উঠবে? শীঘ্রই একটি উত্সর্গীকৃত ডেল পিই 730xD কৃতজ্ঞতার সাথে।

@ ফ্রিসবি - দেরিতে সাড়া পাওয়ার জন্য দুঃখিত। আপনার প্রস্তাব অনুসারে, আমি এসকিউএলকিউরিস্ট্রেস (তাই প্রকৃতপক্ষে ২৪০,০০০ পুনরাবৃত্তি) ব্যবহার করে ২৪ টি থ্রেডের উপরে খালি টেবিল থেকে 10,000 বার একটি নির্বাচন চালিয়েছি এবং তাত্ক্ষণিকভাবে 10,000 ব্যাচের অনুরোধ / সেকেন্ডকে হিট করেছি। তারপরে আমি 24 থ্রেডের চেয়ে 1000 গুণ কমে এসেছি এবং কেবল 4,000 ব্যাচের অনুরোধ / সেকেন্ডের নিচে হিট করেছি। আমি কেবল মাত্র 12 টি থ্রেডের (10,000 টি মোট পুনরাবৃত্তির জন্য) 10,000 বারবার চেষ্টা করেছি এবং এটি একটি টেকসই 6,505 ব্যাচ / সেকেন্ড উত্পাদন করেছে produced সিপিইউতে প্রভাবটি লক্ষণীয় ছিল, প্রতিটি পরীক্ষার সময় মোট সিপিইউ ব্যবহারের প্রায় 5-10% ছিল। নেটওয়ার্কের অপেক্ষাগুলি ছিল নগণ্য (আমার ওয়ার্কস্টেশনে ক্লায়েন্টের সাথে 3 মিমের মতো) তবে সিপিইউয়ের প্রভাবটি নিশ্চিতভাবেই ছিল, যা আমি উদ্বিগ্ন, বেশ নির্ধারিত। এটি সিপিইউর ব্যবহার এবং অযথা ডাটাবেস ফাইল আইও-তে কিছুটা ফুটে উঠেছে বলে মনে হচ্ছে। মোট ফাঁসি / দ্বিতীয়টি কেবলমাত্র 3000 এর নিচে কাজ করে, যা উত্পাদনের চেয়ে বেশি, তবে আমি এই জাতীয় কয়েক ডজন প্রশ্নের মধ্যে কেবল একটির পরীক্ষা করছি। খালি টেবিলগুলিতে প্রতি মিনিটে 300-4000 বারের হারে শত শত ক্যোয়ারির নিখুঁত প্রভাব অতএব সিপিইউয়ের সময় আসার সময় তা উপেক্ষণীয় হবে না। ডুয়াল ফ্ল্যাশ অ্যারে এবং 256 জিবি র‌্যাম, 12 টি আধুনিক কোর সহ অলস PE 730xD এর বিপরীতে সমস্ত পরীক্ষা করা হয়েছে।

@ শ্রুতজকি- ভাল চিন্তাভাবনা। এসকিউএলকিউরিস্ট্রেস ডিফল্টরূপে সংযোগ পুলিং ব্যবহার করে বলে মনে হচ্ছে তবে যাইহোক, আমার একটি চেহারা ছিল এবং হ্যাঁ, সংযোগ পুলিংয়ের জন্য বাক্সটি চেক করা আছে বলে মনে হয়েছে। আপডেট অনুসরণ করুন

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

পুনরায়: সংযোগ পুলিং- ওয়েবলোগিকগুলি পরীক্ষা করে এবং সংযোগ পুলিং সক্ষম করে। লাইভের বিরুদ্ধে আরও ট্রেস দৌড়ান এবং পুলিংয়ের চিহ্নগুলি সঠিকভাবে / মোটেও ঘটে না:

জনবহুল টেবিলের সাথে আমি যুক্ত না হয়ে একটি একক ক্যোয়ারী চালানোর সময় এখানে দেখতে দেখতে কেমন লাগে; ব্যতিক্রমগুলি পড়েছে "এসকিউএল সার্ভারের সাথে সংযোগ স্থাপনের সময় একটি নেটওয়ার্ক-সম্পর্কিত বা উদাহরণ-নির্দিষ্ট ত্রুটি ঘটেছে The সার্ভারটি পাওয়া যায় নি বা অ্যাক্সেসযোগ্য ছিল না। যাচাইকরণের নামটি সঠিক কিনা তা যাচাই করুন এবং দূরবর্তী সংযোগের অনুমতি দেওয়ার জন্য এসকিউএল সার্ভারটি কনফিগার করা হয়েছে। (সরবরাহকারী: নামযুক্ত পাইপ সরবরাহকারী, ত্রুটি: 40 - এসকিউএল সার্ভারের সাথে কোনও সংযোগ খুলতে পারেনি) "ব্যাচের অনুরোধের কাউন্টারটি নোট করুন। ব্যতিক্রমগুলি সফল পিংয়ের প্রতিক্রিয়ায় ফলাফল উত্পন্ন করার সময় সার্ভারকে পিং করা।

আপডেট - টানা দুটি পরীক্ষামূলক রান, একই ওয়ার্কলোড (এমপিটিবেল থেকে * নির্বাচন করুন), পুলিং সক্ষম / সক্ষম নয়। কিছুটা বেশি সিপিইউ ব্যবহার এবং প্রচুর ব্যর্থতা এবং 500 ব্যাচের অনুরোধ / সেকেন্ডের বেশি হয় না। পরীক্ষাগুলিতে 10,000 টি ব্যাচ / সেকেন্ড এবং পুলিং অন নিয়ে কোনও ব্যর্থতা দেখা যায় এবং প্রায় 400 ব্যাচ / সেকেন্ডের পরে পুলিং অক্ষম হওয়ার কারণে প্রচুর ব্যর্থতা হয়। আমি ভাবছি যদি এই ব্যর্থতা সংযোগ প্রাপ্যতার অভাবের সাথে সম্পর্কিত হয়?

@ শ্রুতজকি- sys.dm_exec_connifications থেকে গণনা (*) নির্বাচন করুন;

• পুলিং সক্ষম হয়েছে: লোড পরীক্ষা বন্ধ হওয়ার পরেও ধারাবাহিকভাবে 37

• পুলিং অক্ষম করা হয়েছে: এসকিউএলকিউরি স্ট্রেসে ব্যতিক্রম
  ঘটছে কিনা তার উপর নির্ভর করে ১১-৩7 অর্থাত্: যখন সেই
  ব্যাটগুলি ব্যাচ / সেকেন্ড গ্রাফে উপস্থিত হয় , তখন ব্যতিক্রমগুলি এসকিউএলকিউ স্ট্রেসে ঘটে এবং
  সংযোগের সংখ্যা ১১ এ চলে যায়, তারপরে ধীরে ধীরে ৩ 37 এ ফিরে আসে যখন ব্যাচগুলি শীর্ষে শুরু হয় এবং ব্যতিক্রমগুলি ঘটে না। খুব, খুব আকর্ষণীয়।

পরীক্ষার / লাইভ উভয় ক্ষেত্রেই সর্বোচ্চ সংযোগ 0 এর ডিফল্ট সেট করা থাকে।

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

@ শ্রুতজকি- আপনাকে ধন্যবাদ আমি আগামীকাল ওয়েবলোগিক কনফিগারেশনে যাব এবং আপডেট করব। আমি নিছক 37 সংযোগ সম্পর্কে ভাবছিলাম - যদি এসকিউএলকিউ স্ট্রেস 10,000 টি পুনরাবৃত্তিতে 120 টি থ্রেড করছে = 120,000 সিলেক্ট স্টেটমেন্টগুলি নন-পুলেড করে না, তবে এর অর্থ এই নয় যে প্রতিটি নির্বাচিত স্কয়ার উদাহরণের সাথে একটি স্বতন্ত্র সংযোগ তৈরি করবে?

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

• প্রাথমিক ক্ষমতা: 10
• সর্বোচ্চ ক্ষমতা: 50
• সর্বনিম্ন ক্ষমতা: 5

আমি যখন খালি টেবিল ক্যোয়ারী থেকে নির্বাচনকে সম্পাদনকারী থ্রেডের সংখ্যা বাড়িয়ে তুলি, তখন সংযোগের সংখ্যা 47 এর আশেপাশে থাকে connection সংযোগ পুলিং নিষ্ক্রিয় হওয়ার সাথে সাথে আমি ধারাবাহিকভাবে একটি নিম্নতর সর্বোচ্চ ব্যাচের অনুরোধ / সেকেন্ড দেখতে পাই (10,000 থেকে প্রায় 400 অবধি)। প্রতিবার যা ঘটবে তা হ'ল এসকিউএলকিউয়ারি স্ট্রেসে 'ব্যতিক্রমগুলি' ব্যাচ / সেকেন্ডের গর্তে যাওয়ার খুব শীঘ্রই ঘটে। এটি সংযোগের সাথে সম্পর্কিত তবে আমি কেন বুঝতে পারছি না কেন এটি ঘটছে। যখন কোনও পরীক্ষা চলছে না, # সংযোগগুলি প্রায় 12-এ চলে যায়।

সংযোগ পুলিং নিষ্ক্রিয় হওয়ার সাথে, ব্যতিক্রমগুলি কেন ঘটে তা বুঝতে আমার সমস্যা হচ্ছে, তবে সম্ভবত এটি অ্যাডাম মাচানিকের জন্য সম্পূর্ণ অন্যান্য স্ট্যাক এক্সচেঞ্জ প্রশ্ন / প্রশ্ন?

@ শ্রুতজকি আমি অবাক হয়েছি যে এসকিউএল সার্ভারের সংযোগ শেষ না হওয়া সত্ত্বেও পুলিং সক্ষম ছাড়া ব্যতিক্রমগুলি কেন ঘটবে?

Comments

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

— সলোমন রুটজকি

পিটার, আপনি কি সার্ভারের জন্য সংখ্যার সর্বাধিক সংখ্যক সেট করেছেন? আমি অনুমান করছি যে পুলিং ছাড়াই আপনি খুব বেশি সংযোগের সমস্যায় চলেছেন। আমি ভাবছি যদি আপনার অ্যাপ্লিকেশনটি কখনও ত্রুটি পায়। এছাড়াও, যদি শেষের পরীক্ষাটি আরও একবার চালানো সম্ভব হয় (পুলিং সক্ষম থাকা এবং না ছাড়াই উভয়ই), যখন পরীক্ষাটি এই দুটি কনফিগারেশনের প্রত্যেকটির জন্য চলছে, তখন পুলিং সক্ষম SELECT COUNT(*) FROM sys.dm_exec_connections;করার মধ্যে মানটি খুব বেশি আলাদা কিনা তা দেখার জন্য একটি চালান বা চালান possible না. এই ত্রুটিগুলির ভিত্তিতে, আমি মনে করি পুলিং অক্ষম করা হলে আরও অনেক সংযোগ থাকবে।

— সলোমন রুটজ্কি

পিটার, ৩ connections টি সংযোগ একটি অত্যন্ত কম সর্বাধিক বলে মনে হচ্ছে। প্রদত্ত সংযোগ সীমাটি 0 (অর্থাৎ সীমাহীন) এ সেট করা আছে, সিস্টেমের মেমরিটি কি সীমাবদ্ধ? এছাড়াও, সংযোগ পুলিং ডিফল্টরূপে চালু থাকা উচিত তবে এটি ক্লায়েন্ট দ্বারা নিয়ন্ত্রিত হয়। অ্যাপটি কি একটি নেট অ্যাপ? সংযোগ পুলিং ব্যবহার করার প্রয়োজন হওয়ার দরকার নেই তবে এটির কারণ অনুসন্ধান করার জন্য এটি জানার ক্ষেত্রে সহায়তা করবে। এবং আপনি কি সংযোগ স্ট্রিং ব্যবহার করা হচ্ছে তা দেখতে পাচ্ছেন? এটি নির্দিষ্ট করে Pooling=falseনাকি Max Pool Size?

— সলোমন রুটজকি

পিটার, 12 টি থ্রেডের প্রত্যেকটি ক্রম অনুসারে 10 কে পুনরাবৃত্তির জন্য নিজস্ব সংযোগ তৈরি করছে। সুতরাং পুলিং ছাড়াই কোডটি সংযোগটি বন্ধ হওয়ার সাথে সাথেই সংযোগটি ধ্বংস হয়ে যেতে পারে। পুলিং পুনরায় ব্যবহারের জন্য সংযোগটি প্রায় রাখবে। সুতরাং এটি উপলব্ধি করে যে পুলিং ব্যবহার করার সময় সংযোগগুলির সংখ্যাটি সামঞ্জস্যপূর্ণ ছিল। কেন আরও তথ্য ছাড়া 37 সম্পর্কে নিশ্চিত নন। কোনও পরীক্ষা চলছে না তখন কত সংযোগ আছে? এই সংখ্যাটি ব্যাকআপ করা পরীক্ষার মাধ্যমে কতজন তৈরি হয়েছে তার একটি আরও ভাল ইঙ্গিত দেবে।

— সলোমন রুটজকি

সংযোগ পুলিং প্রতি ক্লায়েন্ট বজায় রাখা হয়, সার্ভার নয়। সুতরাং ওয়েবলজিক্স এবং এসকিউএলকিউরিস্ট্রেসের প্রত্যেকের নিজস্ব সংযোগ পুল থাকা উচিত (মিনি_পুল এবং সর্বোচ্চ_পুল আকারের ক্ষেত্রে, ইত্যাদি)। "সংযোগ পুলিং অক্ষম করার সাথে সাথে, আমি একটি নিম্নতম ব্যাচের অনুরোধগুলি / সেকেন্ড দেখতে পাই": এটি অ্যাপ্লিকেশন থেকে প্রতিটি সংযোগের জন্য অধিবেশনটির সত্যতা এবং প্রারম্ভিককরণের জন্য আরও বেশি সময় নেয় বলে মনে হয় This )।

— সলোমন রুটজকি

Answer 1

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

হ্যাঁ, এবং আরও কিছু অতিরিক্ত কারণ রয়েছে, তবে এগুলির মধ্যে কোনটি আসলে আপনার সিস্টেমে প্রভাব ফেলছে তা সিস্টেম বিশ্লেষণ না করে বলা অসম্ভব।

এটি বলা হচ্ছে, আপনি কোন সমস্যা হতে পারে তা জিজ্ঞাসা করছেন এবং উল্লেখ করার মতো কিছু বিষয় রয়েছে, যদিও এর মধ্যে কিছু বর্তমানে আপনার নির্দিষ্ট পরিস্থিতির কারণ নয়। তুমি বলেছো এটা:

আমাদের প্রায় 300 টি খালি টেবিল রয়েছে এবং এর মধ্যে কয়েকটি টেবিল প্রতি মিনিটে 100-200 বার অনুসন্ধান করা হয়।

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

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

সুতরাং, এমনকি 1 মিলিয়ন অকেজো, 0 টি সারিতে ক্যোয়ারী, এটির পরিমাণ:

• অতিরিক্ত 2 মিলিয়ন লক অপারেশন (প্রতিটি লক আনলক করা আবশ্যক, তাই না?) এটি বেশিরভাগ সময় একটি কার্যকর অপারেশনের পরিবর্তে অকেজো অপারেশনে ব্যয় করা সময় ব্যয়।
• আরও নেটওয়ার্ক ট্র্যাফিক যা আপনাকে স্যাচুরেশনের কাছাকাছি পৌঁছে দিতে পারে (এটি কতটা সম্ভবত সম্ভব তা নিশ্চিত নয় তবে এখনও)

• আরও সংযোগ বজায় রাখা হচ্ছে যা আরও স্মৃতি গ্রহণ করে। আপনার কত অব্যবহৃত শারীরিক র‌্যাম রয়েছে? ক্যোরি এবং / অথবা ক্যোয়ারী প্ল্যান ক্যাশে চালানোর জন্য সেই মেমরিটি আরও ভাল ব্যবহার করা যেতে পারে। সবচেয়ে খারাপ পরিস্থিতিটি হ'ল আপনি শারীরিক স্মৃতি থেকে বেরিয়ে এসেছেন এবং এসকিউএল সার্ভারকে ভার্চুয়াল মেমোরি (অদলবদল) ব্যবহার করা শুরু করতে হবে, কারণ এটি জিনিসগুলিকে ধীর করে দেয় (মেমরিটি পেজড হওয়ার বিষয়ে বার্তা পাচ্ছেন কিনা তা দেখতে আপনার এসকিউএল সার্ভার ত্রুটি লগটি পরীক্ষা করুন)।

  এবং কেবলমাত্র কেউ উল্লেখ করলে, "ভাল, সংযোগ পুলিং রয়েছে"। হ্যাঁ, এটি অবশ্যই প্রয়োজনীয় সংযোগের সংখ্যা হ্রাস করতে সহায়তা করে। তবে প্রতি মিনিটে 200 বার পর্যন্ত ক্যোয়ারী আসার পরেও এটি প্রচুর সাম্প্রতিক ক্রিয়াকলাপ এবং বৈধ অনুরোধগুলির জন্য এখনও সংযোগগুলির উপস্থিতি থাকা দরকার। আপনি SELECT * FROM sys.dm_exec_connections;কতগুলি সক্রিয় সংযোগ বজায় রেখেছেন তা দেখতে একটি করুন ।

• অন্য যে কোনও বিষয় নির্বিশেষে, এটি প্রতিদিন অন্তত কমপক্ষে 1 মিলিয়ন বার হয়েছে যে কোনও থ্রেড যা কার্যকর কিছু করতে পারত তা উপলভ্য ছিল না।

আমি এখানে যা বলেছি তা সম্পর্কে যদি আমি ভুল না হয়ে থাকি তবে এটি আমার কাছে মনে হয়, এমনকি যদি ছোট স্কেল করেও এটি আপনার সিস্টেমে এক ধরণের DDoS আক্রমণ কারণ এটি নেটওয়ার্ক এবং আপনার এসকিউএল সার্ভারটি বগাস অনুরোধের সাথে প্লাবিত হচ্ছে since , এসকিউএল সার্ভারে যাওয়া বা এসকিউএল সার্ভার দ্বারা প্রক্রিয়াজাতকরণ থেকে সত্যিকারের অনুরোধগুলি প্রতিরোধ করা।

Answer 2

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

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

আমি একটি খালি টেবিলে 100,000 নির্বাচন গণনা (*) এ একটি পরীক্ষা চালিয়েছি এবং এটি 32 সেকেন্ডের মধ্যে চলেছে এবং অনুসন্ধানগুলি একটি নেটওয়ার্কের ওপরে চলে গেছে। সুতরাং 1/3 মিলিসেকেন্ড। আপনার নেটওয়ার্ক ওভারলোড না হওয়া পর্যন্ত এটি ক্লায়েন্টকে প্রভাবিত করবে না। আপনার যদি বড় পারফরম্যান্সের সমস্যা হয় তবে এই 1/3 মিলিসেকেন্ড ফাঁকা অনুসন্ধানগুলি অ্যাপ্লিকেশনটিকে হত্যা করছে না।

এবং এগুলি কোনও স্থির প্রকারের ডেটা হ'ল বাম অংশের অংশ হতে পারে যা বর্তমান অ্যাপ্লিকেশনের অংশ নয়। এটি অন্যান্য প্রশ্নের সাথে শৃঙ্খলাবদ্ধ হতে পারে সুতরাং এটি কোনও অতিরিক্ত রাউন্ড ট্রিপ নয়। যদি হ্যাঁ হয় তবে এটি ঝাপটে তবে এটি বেশি ট্র্যাফিকের কারণও নয়।

সুতরাং ফিরে আসল বিবৃতি তাকান। আপনি কি এই টেবিলগুলিতে কোনও আপডেট, সংযোজন বা মুছতে দেখছেন?

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

Comments

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

— সলোমন রুটজকি

এবং আমি আপনাকে ভুল বলছি না। অন্যান্য ব্যবহারকারীগণ বা না এটি এখনও কতক্ষণ লেগেছিল তার একটি বৈধ পরিমাপ এবং সংস্থানগুলির এক পরিমাপ বর্ণিত লোড প্রতি মিনিটে 100-200। 30 সেকেন্ডের মধ্যে একটি ক্লায়েন্টের কাছ থেকে 100,000 লোডকে 200 থেকে 400 এর ফ্যাক্টারে ছাড়িয়ে যায় no যদি কোনও আপডেট লক না থাকে তবে তা যদি কোনও ক্লায়েন্টের কাছ থেকে আসে বা 100 এর কোনও তফাত হয় না। আপনার উত্তরটি ধরে নিয়েছে যে কোনও ওভারলোডেড নেটওয়ার্ক বা এসকিউএল সার্ভার রয়েছে এবং যে প্রশ্নটি আপনি জানেন না তার উপর ভিত্তি করে। এটি যদি ডিডিওএস আক্রমণ হয় তবে এটি 100 / সেকেন্ডের মতো (মিনিট নয়) হতে পারে এবং এটি খালি টেবিলের বিপরীতে না।

— পাপারাজ্জো

সঠিক, প্রশ্নের ভিত্তিতে আমরা এটিকে সঙ্কুচিত করতে পর্যাপ্ত পরিমাণে জানি না, এ কারণেই আমি বলছিলাম যে পরিস্থিতিগুলির উপর নির্ভর করে এই জিনিসগুলি একটি সমস্যা হতে পারে। এবং ডিডোস জিনিসটি কেবল একটি সাদৃশ্য ছিল, মূলত মূল প্রশ্নের শব্দের উপর ভিত্তি করে যা বোঝায় যে এটি বেশিরভাগ হারে হিট হয়েছিল এবং আরও অনেকেই ঠিক কম ঘন ঘন হিট হচ্ছিল।

— সলোমন রুটজকি

আমি এই বিবেচনায় এটি একটি মূল্যবান উত্তর হিসাবে বিবেচনা করি যে প্রথম অনুচ্ছেদে এটি খুব ভালভাবে অঙ্ক করে: "যদি আপনার ডাটাবেস সার্ভারে উচ্চ সিপিইউ বা মেমরি না থাকে তবে এটি সম্ভবত একটি নন-ইস্যু।" আমাদের ক্ষেত্রে, আমরা দিনের নির্দিষ্ট সময়ে উচ্চ সিপিইউ ব্যবহার করি এবং তাই অতিরিক্ত সিপিইউ চাপটি আমার পরীক্ষার উপর ভিত্তি করে ফ্যাক্টর বলে মনে হচ্ছে।

— পিটার

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

— পিটার

Answer 3

প্রতিটি প্রশ্নের উপরে সাধারণভাবে নিম্নলিখিত পদক্ষেপগুলি সম্পন্ন হয়:

1. আবেদন থেকে অনুরোধ।
2. ডাটাবেস কোয়েরি পার্স।
3. এই কোয়েরিটি ইতিমধ্যে র্যামে সঞ্চিত আছে কিনা তা ডাটাবেস ইঞ্জিন পরীক্ষা করে। মেমোরিতে উপস্থিত থাকলে কার্যকরকরণ পরিকল্পনা ব্যবহার করুন।
4. র‌্যামে বিদ্যমান না থাকলে, ডাটাবেস ইঞ্জিন ক্যোয়ারীতে থাকা অবজেক্টগুলির বিদ্যমান উপস্থিত পরিসংখ্যানগুলির জন্য পরীক্ষা করে এবং কার্যকরকরণ পরিকল্পনা নির্ধারণ করে।
5. এক্সিকিউশন প্ল্যান চালান, ডিস্ক থেকে ডেটা পেতে i / o ব্যবহার করুন।
6. আবেদনের সাড়া।

আপনি উল্লেখ করেছেন এমন অনেকগুলি প্রশ্নের ফলে ইতিমধ্যে ভারী এমন কোনও সিস্টেমে অতিরিক্ত চাপ পড়তে পারে - সংযোগগুলিতে অতিরিক্ত চাপ, সিপিইউ, র‍্যাম এবং আই / ও।