HADR_SYNC_COMMIT এর কৌতূহলের ক্ষেত্রে অপেক্ষা

Question

আমরা HADR_SYNC_COMMITআমাদের পরিবেশে অপেক্ষা করার জন্য একটি আকর্ষণীয় প্যাটার্নটি লক্ষ্য করছি । আমাদের তিনটি প্রতিরূপ আছে; একটি প্রাথমিক, একটি সিঙ্ক মাধ্যমিক এবং একটি অ্যাসিঙ্ক মাধ্যমিক একটি ডেটাসেন্টারে এবং আমরা সবেমাত্র অন্য একটি ডাটাসেন্টারে (~ 2400 মাইল দূরে) আরও তিনটি এএসআইএনসি রেপ্লিকা যুক্ত করেছি ।

সেই থেকে আমরা HADR_SYNC_COMMITপ্রতীক্ষায় এক বিরাট বৃদ্ধি লক্ষ্য করতে শুরু করেছি । যখন আমরা সক্রিয় অধিবেশনগুলিতে লক্ষ্য করি, আমরা দেখতে পাই COMMIT TRANSACTIONSYNC প্রতিরূপে অপেক্ষা করানো বেশ কয়েকটি কোয়েরি

স্ক্রিনশট থেকে, আমরা পরিষ্কারভাবে দেখতে পাচ্ছি যে HADR_SYNC_COMMIT২৯ শে জুন অপেক্ষার ঝাঁপ রয়েছে , এবং শেষ পর্যন্ত আমরা ১ লা জুলাই দুপুরে রিমোট ডেটাসেন্টারে তিনটি অ্যাসিঙ্ক প্রতিরূপের দুটি 'নামিয়ে ফেলেছিলাম। এটি অপেক্ষার সময়টিকে পাশাপাশি রেখেছিল dropped

আমরা এখন অবধি যা যাচাই করেছি - দূরবর্তী প্রতিরূপে লগ প্রেরণ সারি, পুনরায় সারি, শেষ কঠোর সময় এবং শেষ প্রতিশ্রুতি সময় প্রেরণ করুন। আমাদের ব্যবসায়ের সময় অবিচ্ছিন্নভাবে ছোট ছোট লেনদেন হয় এবং তাই নির্দিষ্ট সময় স্ট্যাম্পে (60KB এবং 1MB এর মধ্যে যে কোনও জায়গায়) প্রেরণের সারিগুলি খুব ছোট।
দূরবর্তী প্রতিলিপিগুলি প্রায় সিঙ্কে রয়েছে, প্রতিলিপিগুলিতে কোনও স্বতন্ত্র lsn এর জন্য শেষ প্রতিশ্রুতি সময় এবং শেষ কঠোর সময়ের মধ্যে খুব কম পার্থক্য রয়েছে।

নেটওয়ার্ক পাইপটি 10 ​​জি এবং আমরা 256 মেগ থেকে 2 জিগের মধ্যে প্রেরণকারী বাফার আকারটি পরিবর্তন করেছি, এটি এই ধারণার অধীনে তৈরি হয়েছিল যে নেটওয়ার্কটি প্যাকেটগুলি ফেলে দিচ্ছে এবং সেগুলি পুনরায় সংক্রমণ করছে; যে কোনও উপায়েই তেমন কোনও সহায়ক বলে মনে হচ্ছে না।

সুতরাং, আমি ভাবছি যে এএসআইএনসি প্রতিরূপ অপেক্ষার সাথে HADR_SYNC_COMMITকী করবে? না করা উচিত সিঙ্ক এই অপেক্ষার ধরনের উপর একা নির্ভর প্রতিরূপ, আমি এখানে কি অনুপস্থিত করছি?

Comments

তাহলে আসলেই কি সমস্যা আছে? অনেক লোক কেবল তাদের অপেক্ষার দিকে তাকিয়ে বলে, আরে, এটিই তার সর্বোচ্চ অপেক্ষা, এটি অবশ্যই সমস্যা হতে পারে! একটি অপেক্ষা কেবল একটি সংখ্যা এবং সর্বদা সর্বোচ্চ সংখ্যার সাথে এক হতে চলেছে - এর অর্থ এই নয় যে সমাধান করার জন্য কোনও পারফরম্যান্স সমস্যা আছে problem এই অপেক্ষাটির জন্য বিশেষত মনে হচ্ছে আপনি সর্বাধিক সাধারণ কারণটিকে অস্বীকার করেছেন , এবং যেহেতু আপনার সেকেন্ডারিরা পিছিয়ে নেই, আমি এই "সমস্যা" পর্যন্ত খুব বেশি শক্তি ব্যয় করব না

— অ্যারন বার্ট্র্যান্ড

ওয়েট কাউন্টারে একটি উচ্চ সংখ্যার সাথে আপনি আরও কিছু লক্ষণ পেয়েছেন এবং উচ্চ প্রতিক্ষের কাউন্টারটির সাথে আপনি সম্পর্ক স্থাপন করতে পারেন।

— অ্যারন বার্ট্র্যান্ড

@ অ্যারনবার্ট্র্যান্ড হ্যাঁ, আছে। প্রাথমিক প্রতিরূপে সক্রিয় স্পিডগুলি সিঙ্ক মাধ্যমিকের লগ ব্লকগুলিকে শক্ত করার জন্য অপেক্ষা করে, ফলস্বরূপ এই বিলম্ব / অপেক্ষার ফলে অ্যাপ্লিকেশনটি খুব দ্রুত ধীর হয়ে যায় to 9 জুলাই পেজল্যাচটি অপেক্ষায় রয়েছে আপনি স্ক্রিনশটটিতে দেখতে পেয়েছিলেন টেম্পডিবি কনটেন্টের কারণে (পিএফএস পৃষ্ঠার অপেক্ষায়), আমরা ডিবিএ পক্ষ থেকে আরও ফাইল যুক্ত করেছি এবং অ্যাপলিকেশন লোকেরা এই সমস্যাটি প্রশমিত করার জন্য টেম্পটিডিবিটিকে আঘাত করার জন্য সঞ্চিত পদ্ধতিগুলি সুরক্ষিত করেছিল। Hadr_sync_waits- এ ফিরে আসুন, কেন async কমিট প্রথম স্থানটিতে হ্যাডার_সায়েন্স_কমিটকে প্রভাবিত করে? ধন্যবাদ।

— অরুণ গোপীনাথ

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

— অ্যারন বারট্র্যান্ড

Answer 1

প্রথমে আপনার প্রশ্ন সম্পর্কিত যে অপেক্ষার ইভেন্টটির বিবরণ তা হ'ল:

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

https://msdn.microsoft.com/en-us/library/ms179984.aspx

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

সূত্র: http://blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

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

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

CREATE EVENT SESSION [HADR_SYNC_COMMIT-Monitor] ON SERVER  -- Run this on the primary replica 
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden(
    WHERE ([delay]>(10))) -- I strongly encourage you to use the delay filter to avoid getting too many events back, this is measured in milliseconds
ADD TARGET package0.event_file(SET filename=N'<YourFilePathHere>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO