আমরা ব্যবসায়ের কেস সমাধানের জন্য পরিষেবা পরিবেশকে আমাদের পরিবেশে কাজ করার চেষ্টা করছি। আমি জানিনা বার্তার শিরোনামটি ভাল কিনা, তবে আমার প্রশ্নটি নীচে। তবে এটি একটি ভাল প্রশ্ন নাও হতে পারে, সুতরাং এর পরে আমরা কী করছি এবং কেন আমি মনে করি এটি সঠিক প্রশ্ন।
কথোপকথনটি শেষ হওয়ার আগে একটি কথোপকথনে কয়টি বার্তা প্রেরণ করা উচিত?
ফলাফল টেবিলে অবিচ্ছিন্নভাবে আপডেট করার জন্য আমরা পরিষেবা ব্রোকারটি ব্যবহার করতে চাই। ফলাফল সারণী সমতল এবং দ্রুত হয়। আমাদের বেস টেবিলগুলিতে ট্রিগার রয়েছে যা তাদের টেবিল এবং প্রাথমিক কী সহ একটি বার্তা প্রেরণ করে। আমাদের তিনটি সারি রয়েছে:
- নিম্ন দেরীতে - উদ্দেশ্য প্রক্রিয়াটির 15 সেকেন্ড। এটি আইটেমগুলি পরিচালনা করে যা নির্দিষ্ট আইটেমের সাথে সম্পর্কিত।
- বাল্ক সারি - উদ্দেশ্য প্রক্রিয়া করতে 5 মিনিট। যখন এমন কিছু পরিবর্তন হয় যা বহু শতাধিক (বা হাজারো) আইটেমকে প্রভাবিত করে তখন এটি পরিচালনা করে। এটি প্রভাবিত হয়েছিল এমন আইটেমগুলির তালিকা ভেঙে দেয় এবং এগুলি ডিফার্ড লো লেটেন্সি কাতারে ফিড করে
- ডিফার্ড লো লেটেন্সি - উদ্দেশ্য প্রক্রিয়া করতে 30 মিনিট। এটি আইটেমগুলি প্রক্রিয়া করে তবে কেবল বাল্ক সারি থেকে।
মূলত, যদি কোনও ক্লায়েন্টের তথ্য আপডেট হয়; এটি এমন অনেক পণ্যকে প্রভাবিত করে যাতে ধীর প্রক্রিয়াকরণের জন্য বাল্ক কাতারে প্রেরণ হয়। যাইহোক, যদি কোনও পণ্য আপডেট হয়ে যায়, তবে এটি কম বিলম্বিত সারিতে পাঠানো হবে।
আমরা রেমাস রুসানুর ব্লগ http://rusanu.com/2007/04/25/reasing-conversations/ এর অনুরূপ কথোপকথনগুলিকে পুনরায় ব্যবহার করি , ব্যতিক্রম যে আমরা এটি প্রাথমিক কী এর মডিউলাসের উপর ভিত্তি করে করি। প্রাথমিক কী এর ডি-সদৃশকরণে সহায়তা করার পার্শ্ব সুবিধা রয়েছে।
সুতরাং, আমরা কথোপকথনগুলি পুনরায় ব্যবহার করছি এবং আমাদের নির্দেশিকাগুলির মধ্যে আছি। দুটি থ্রেড সহ, আমি 125 বার্তা / সেকেন্ডের মাধ্যমে (বেশ কয়েক হাজার বার্তাগুলির কৃত্রিম ড্রপ) দিয়ে পোড়াতে সক্ষম হয়েছি, যা উত্পাদনের সাথে তাল মিলিয়ে রাখতে সক্ষম (সর্বাধিক 15 বার্তা / সেকেন্ড)।
তবে, আমরা যে সমস্যার মুখোমুখি হচ্ছি তা হ'ল সময়ের পরে, hours 4 ঘন্টা বা 120 কে বার্তা, আমরা সিসডেসেন্ড এবং সারি টেবিলের উপর ব্লক এবং উচ্চ বিতর্ক দেখতে শুরু করি। লকগুলি LCK_M_U এবং কেই লক হয়। কখনও কখনও হোবটটি সিসডেসেন্ডে এবং অন্যান্য সময়ে নির্দিষ্ট সারি টেবিলের (কুই_) সমাধান করে।
আমাদের এমন একটি প্রক্রিয়া রয়েছে যা ইতিমধ্যে 24 ঘন্টা বা 30 মিনিটের নিষ্ক্রিয়তার পরে কথোপকথনটি শেষ করবে, তাই আমরা কথোপকথনটি সাইক্লিংয়ের আগে সময়টি আরও বাড়িয়ে দিতে পারি।
আমরা এসকিউএল 2016 এন্টারপ্রাইজ (13.0.4001.0) ব্যবহার করছি
- ট্রিগার ফায়ারস (কম বিলম্বিত বা বাল্কের কাছে প্রেরণ করুন)
- সন্ধান করুন বা কথোপকথনের হ্যান্ডেল তৈরি করুন।
- বার্তা পাঠান
- সারি সক্রিয় পদ্ধতি
- ফলাফলের সারণী আপডেট করুন
কোনও নিষ্ক্রিয় কথোপকথন আছে কিনা তা দেখার জন্য ক্লিনআপ প্রক্রিয়া প্রতি 10 মিনিটে চলে। যদি এটি পর পর তিনবারের বেশি এগুলিকে খুঁজে পায় তবে এটি এটিকে নিষ্ক্রিয় হিসাবে চিহ্নিত করে এবং কথোপকথনটি শেষ করে।
উপকারজনক হতে পারে এমন কোনও অতিরিক্ত বিশদ থাকলে দয়া করে আমাকে জানান। পরিষেবা ব্রোকারের সাথে আমার খুব বেশি অভিজ্ঞতা নেই তাই আমার বার্তা / সেকেন্ড কম, উচ্চ বা উদাসীন কিনা তা আমি জানি না।
হালনাগাদ
তাই আমরা আজ আবার চেষ্টা করেছি এবং একই সমস্যার মুখোমুখি হয়েছি। আমরা কথোপকথনটির আজীবন 2 ঘণ্টার মধ্যে পরিবর্তন করেছি এবং এর কোনও প্রভাব নেই। সুতরাং আমরা তখন 150 টি কৌশল বাস্তবায়ন করেছি; যা একই সমস্যা ছিল।
ট্রেনগুলি SEND CONVERSATION এ অপেক্ষা করুন, সিডসেন্ডে অপেক্ষা করা। কারও কি আরও কিছু ধারণা আছে?
আপডেট 2
আমরা আজ দীর্ঘকাল পরীক্ষা চালিয়েছি এবং ১ 17 মিনিটের নমুনা সময়ের মধ্যে একটিতে আমরা ৪ টি কথোপকথনের হ্যান্ডেলে 41 কে বার্তা প্রসেস করেছি। সিসডেসেন্ডে এবং কাতার টেবিলের লকগুলি খুব বেশি হয়ে যায় এবং আমরা এটি বন্ধ করার আগে পিছনে পিছনে যেতে শুরু করি, আমরা শেষের দিকে অগ্রাহ্য করতে সক্ষম হয়েছি। আমাদের মনে হয় বার্তাগুলি প্রক্রিয়াকরণে কোনও সমস্যা নেই, কাতারে প্রবেশ না করেই আমরা এগুলি সরাতে পারি এবং কমপক্ষে 5x গতিতে তাদের প্রক্রিয়া করতে পারি। বার্তা যুক্ত করার উপর ভিত্তি করে আমাদের গতি সীমাবদ্ধ বলে মনে হচ্ছে।
পরবর্তী পরীক্ষায়, আমরা এমন একটি ট্রিগার সরিয়ে দিয়েছি যা ম্যাসেজের ৮০% হয়ে থাকে। এমনকি এই অনেক কমানোর বোঝা নিয়েও আমরা একই অপেক্ষারত দেখতে শুরু করেছি।
আপডেট 3
আপনাকে ধন্যবাদ, আপনার পরামর্শের জন্য রেমাস (এবং এই বিষয়ে দুর্দান্ত ব্লগ নিবন্ধগুলি পোস্ট করার জন্য আপনাকে ধন্যবাদ, তারা এই মুহুর্তে পৌঁছাতে সহায়ক ভূমিকা পালন করেছিল)।
আমরা আজ এটি আবার চালিয়েছি এবং আরও ভাল করেছিলাম (যেমন আমরা অপেক্ষাগুলি দেখার আগে এবং এটি আমাদের পঙ্গু করার আগে আরও দীর্ঘ হয়েছিল) longer সুতরাং, বিশদ।
আমরা পরিবর্তন করেছি: * প্রতি থ্রেড বজায় রাখা কথোপকথনের সংখ্যা 1: 1 থেকে 2: 1 এ বাড়িয়েছি। মূলত, আমাদের 4 টি থ্রেডের জন্য 8 টি কথোপকথন হ্যান্ডেল ছিল।
- কম, বৃহত্তর বার্তাগুলিতে একীভূত করতে বাল্ক কাতাকে একীভূত করা হয়েছে (কারণ একটি আগত বার্তাটি কয়েকজন বহির্গামী বার্তাকে বোঝাতে পারে)
এই প্রচেষ্টা সম্পর্কে নোট:
লক্ষ্য সারি অ্যাক্টিভেশন পদ্ধতিটি অক্ষম করা হচ্ছে। অবরুদ্ধকরণে কোনও পরিবর্তন হয়নি (আমরা 5 মিনিট অপেক্ষা করেছি) এবং বার্তাটি sys.transmission_queues এ প্রেরণ করা হবে।
sys.conversation_endpPoint নিরীক্ষণ। এই সংখ্যাটি 0 13 কে থেকে খুব দ্রুত চলে গিয়েছিল এবং তারপরে সারা দিন আরও আস্তে rose 5 ঘন্টা পরে 25K অবধি শেষ হয়। 16K +/- না হওয়া পর্যন্ত অবরুদ্ধ হওয়া শুরু হয়নি
আমি ড্যাকের মধ্যে andুকে গিয়েছিলাম এবং কাতারগুলির জন্য ডিবিআরআইএনডিএক্স কমান্ডগুলি চালিত করেছি, যদিও কোনও প্রশ্ন থেকে, ক্লিনআপটি উপস্থিত হওয়ার আগে এবং ভোজন রেকর্ডটি 200 এ ছাড়েনি got
পরীক্ষা শেষ করার সময় সিডিসেন্ড এবং সিসডেরসিভের 24,932 এর অভিন্ন গণনা ছিল।
আমরা 5 ঘন্টা ~ 310K বার্তা প্রসেস করেছি।
জিনিসগুলি বিচ্ছিন্ন হওয়ার আগে আমরা এতক্ষণ গিয়েছিলাম যে আমি সত্যিই ভেবেছিলাম আমরা এবার এটি তৈরি করব। আগামীকাল আমরা তারের মধ্য দিয়ে বার্তাগুলি জোর করার চেষ্টা করব।
sys.conversation_endpointsপরীক্ষার সময় সারিগুলির সংখ্যা কী (ধ্রুবক বা ক্রমবর্ধমান, এবং যখন ব্লকিং ঘটে তখন এটি কত বড়)। ২) যখন ব্লকিং ঘটে তখন লক্ষ্য কাতটি নিষ্ক্রিয় করা SEND ব্লকিংয়ের ক্ষেত্রে কি কি পার্থক্য সৃষ্টি করে (সারিটি অক্ষম করে SEY.transmission_queue এ SEND রুট করা উচিত)। এবং 3) বার্তাটি তারে যেতে বাধ্য করা, এমনকি স্থানীয়ভাবে (এসএসবি শেষ পয়েন্ট স্থাপন, রুট যুক্ত করা) দীর্ঘকালীন আচরণের পরিবর্তন করে
ALTER QUEUE ... REBUILDএকবারে ব্লকিং শুরু হওয়ার পরে কি দৌড়াদৌড়ি দ্বারা কোনও পার্থক্য আসে?
we started seeing blocks and high contention on sysdesend and the queue table.-> অপেক্ষার প্রকারটি কী -PAGELATCH_EX/SH and WRITELOG? আপনি কি 150 টি ট্রিক ব্যবহার করেছেন ? যদি সিস্টেম সারণীগুলি আপনার যুক্তিযুক্ত বিষয় হয় তবে 150 টি কৌশলটি অত্যন্ত কার্যকর।