এসকিউএল সার্ভার - যে কেউ সুমা, ট্রেস পতাকা 8048, বা ট্রেস পতাকা 8015 ব্যবহার করছেন?

Question

একটি এসকিউএল সার্ভার ২০০৮ আর 2 সিস্টেমে একটি গুরুতর স্পিনলক কনটেন্টেশন সমস্যা সমাধানের জন্য সম্প্রতি এসকিউএল সার্ভার স্টার্টআপ ট্রেস পতাকা 8048 অন্তর্ভুক্ত করা হয়েছে।

অন্যদের কাছ থেকে শুনতে আগ্রহী যারা ব্যবহারের ক্ষেত্রে সন্ধান পেয়েছেন যেখানে ট্রেস পতাকা 8048 দ্বারা পারফরম্যান্স মান প্রদান করা হয়েছে (প্রতি-NUMA নোড থেকে প্রতি-কোর পর্যন্ত ক্যোয়ারী মেমরি অনুদান কৌশল প্রচার করুন), পতাকা 8015 (এসকিউএল সার্ভার শারীরিক NUMA উপেক্ষা করে), বা সুমা ( আন্তঃবাহিত পর্যাপ্ত অভিন্ন মেমরি অ্যাক্সেস, কিছু NUMA মেশিনে একটি BIOS বিকল্প)।

ট্রেস পতাকা 8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -presented প্রতি NUMA-নোড-মে এর প্রয়োজনীয়তা কি ট্রেস-ফ্ল্যাগ-8048.aspx

ট্রেস পতাকা 8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io- সংকলন- thread- lazy-writer- ওয়ার্কারস- এবং- মেমরি -nodes.aspx

সিস্টেম ওয়ার্কলোডের বিশদ বিবরণ, ঝামেলা হওয়া সিস্টেম থেকে মেট্রিক সংগ্রহ করা এবং হস্তক্ষেপ অনুসরণের পরে সিস্টেম থেকে মেট্রিক সংগ্রহ করা।

ট্রেস পতাকা 8048 একটি 'ফিক্স' ছিল, তবে এটি কি সেরা ফিক্স ছিল? 8015 ট্রেস ফ্ল্যাগের কারণে কি এসকিউএল সার্ভার শারীরিক NUMA উপেক্ষা করে একই কাজটি সম্পাদন করতে পারে? BIOS কে ইন্টারলিভ মেমোরিতে সেট করার বিষয়ে, সার্ভারকে এসএমপি-অনুকরণকারী সুমা আচরণের সাথে NUMA আচরণের পরিবর্তে রেখে যাবে?

সালাম টুই: @ এসকিএল_হ্যান্ডল

---

সিস্টেম সম্পর্কে: - 4 হেক্সস কোর জিয়ন ই 7540 @ 2.00GHz, হাইপারথ্রেড - 128 জিবি র‌্যাম - ডাব্লুএস 2008 আর 2 - এমএসএসকিউএল 2008 আর 2 এসপি 2 - ম্যাক্সডপ 6

---

কাজের চাপ সম্পর্কে: - 2 টি প্রতিবেদনের অ্যাপ্লিকেশন সার্ভার থেকে চালিত বাচের নির্ধারিত / সারিবদ্ধ রিপোর্টের সংখ্যা। - তিনটি ব্যাচের স্বাদ: দৈনিক, সাপ্তাহিক, মাসিক - এসকিউএল সার্ভারের সমস্ত রিপোর্ট অ্যাপ্লিকেশন সার্ভারের সংযোগগুলি একটি একক পরিষেবা অ্যাকাউন্ট হিসাবে তৈরি করা হয় - সর্বাধিক রিপোর্ট সম্মতি = 90

---

অস্থির সিস্টেমে মূল অনুসন্ধানগুলি: - পারফমন থেকে, 15 দ্বিতীয় বিরতি - - সিস্টেমটি 95% -100% সিপিইউতে ব্যস্ত থাকে - - এসকিউএল সার্ভার বাফার পৃষ্ঠাগুলি <10000 প্রতি সেকেন্ডে

• অপেক্ষা এবং স্পিনলক ডিএমভিগুলি থেকে, 5 মিনিটের বিরতি
• • হাই সিএমএমটিআরএইডি ওয়েটার এবং অপেক্ষা করার সময়
• • উচ্চ SOS_SUSPEND_QUEUE স্পিন এবং ব্যাকঅফস

ট্রেস ফ্ল্যাগ ৮০৪৮-তে বব ডরসের সিএসএস ইঞ্জিনিয়ার ব্লগ পোস্টটি ইঙ্গিত দেয় যে NUMA নোডের প্রতি 8 টিরও বেশি কোর সমেত সিস্টেমগুলি ক্যোয়ারী মেমোরি অনুদানের ক্ষেত্রে বাধার কারণে একই ধরণের লক্ষণগুলির মধ্যে চলে যেতে পারে। ট্রেস পতাকা 8048 কৌশলটি প্রতি-NUMA নোডের পরিবর্তে প্রতি-কোরে পরিবর্তন করবে।

---

হস্তক্ষেপ

এমএসএসকিউএল -T8048 জায়গায় পুনরায় আরম্ভ হয়েছিল। তফাতটি তত্ক্ষণাত স্পষ্ট হয়েছিল: বাফার পৃষ্ঠাগুলি দেখার হার 1 মিলিয়নেরও বেশি বেড়েছে এবং প্রতি সেকেন্ডে 8 মিলিয়নে পৌঁছেছে। অস্থির ব্যাচের কাজের চাপ, যা আগে ২৪ ঘন্টার মধ্যে শেষ করতে পারেনি, ৪ ঘন্টারও কম সময়ে সম্পন্ন হয়েছিল। আর একটি ব্যাচের কাজের চাপ যা তদন্ত বা হস্তক্ষেপের কেন্দ্রবিন্দু ছিল না এটি ট্রেস পতাকা 8048 এর সংশোধনমূলক মানকে বৈধতা দেওয়ার অংশ হিসাবে জমা দেওয়া হয়েছিল (এবং এটির অনাকাঙ্ক্ষিত পার্শ্ব প্রতিক্রিয়াগুলি সর্বনিম্ন ছিল তা নিশ্চিত করার জন্য)। এই প্রতিবেদনের ব্যাচটি 2 ঘন্টা আগে শেষ হয়েছিল; ট্রেস পতাকা সহ 8048 জায়গায় রিপোর্ট ব্যাচটি প্রায় 20 মিনিটের মধ্যে শেষ হয়।

নাইট ইটিএলও একটি সুবিধার মুখোমুখি হয়েছিল। ETL সময়টি প্রায় 60 মিনিট থেকে 40 মিনিটে নেমে গেছে।

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

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

Answer 1

এটি একটি ভয়ঙ্কর পোস্ট।

আপনার চূড়ান্ত প্রশ্নের উত্তর দিতে, আমি অনুমান করতে পারি যে আপনার উত্তরটি "হ্যাঁ"।

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

একটি পৃথক চিন্তার উপর, আমি জোর করে প্যারামিটারাইজেশন দেখব - আপনার বোঝাটি আপনার সিপিইউকে এত বেশি চালাচ্ছে এটি খুব আকর্ষণীয় এবং এটি সন্ধান করার পক্ষে এটি মূল্যবানও হতে পারে।

সবশেষে, মাল্টি-নুমা নোড সিস্টেমে, আমি সাধারণত নিম্নলিখিত এনক্রিস্টেরগুলি প্রতি এন সেকেন্ডে একটি টেবিলে ডাম্প করে থাকি। কাজের চাপ পরিবর্তন বা ট্রেস পতাকা প্রয়োগ করা হয় তখন কিছু আকর্ষণীয় বিশ্লেষণের জন্য তোলে:

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

এবং

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC

Comments

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

— sql_handle

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

— জেরেমি লোয়েল

ভাল দিক. আমি বাফার নোড মেট্রিকগুলি দেখছি। সবচেয়ে কৌতূহলটি ছিল প্রথমদিকে, নোডের কোনও বিদেশী পৃষ্ঠা ছিল না, অন্য নোডে প্রচুর সংখ্যা ছিল। আমি মনে করি যে এটি আমাদের ইটিএল বাফার ন্যাম্প / NUMA নোড 00 এ পুরোপুরি ফিট করার জন্য একটি কম পর্যাপ্ত থ্রেড গণনা সহ বাফার র‌্যাম্পটি করছিল due আমাদের কাছে ট্রেস পতাকা 834 সক্ষম নেই, তবে শীঘ্রই এটির সাথে পরীক্ষা শুরু করব। লিনাক্স ওরাকল 11 জিআর 2 এ আমাদের কাজের চাপ পরীক্ষা করে বড় পৃষ্ঠাগুলি স্মরণে দারুণ উপকার পেয়েছিল, আমি মনে করি এসকিউএল সার্ভারের সাথে আমরা উইন্ডোজেও লাভ দেখতে পাব।

— স্ক্যাল_হ্যান্ডল

@ মাইক সফট NUMA বনাম টিএফ 8048. আমি মনে করি যে নরম NUMA আমাকে NUMA নোডের মধ্যে 'মেমরি নোড' তৈরি করতে দেয়। সুতরাং আমি যদি প্রতিটি কোরের জন্য নরম NUMA তৈরি করি, তবে কোয়েরি মেমরি অনুদানের অনুরোধগুলির জন্য (সম্ভবত) 24 টি লেন থাকবে। তবে সম্ভবত 24 মেমোরি নোড? প্রতিটি কোর তৈরির জন্য 'বিদেশী' পৃষ্ঠা রেফারেন্সের সাথে 24 টি মেমরি নোড পরিচালনার ক্ষেত্রে আমি ওভারহেড সম্পর্কে কিছুটা চিন্তিত হব এবং যখন এটি কোনও পৃষ্ঠার রেফারেন্সের জন্য একটি সীমানা অতিক্রম করে তখন সত্যিই বিদেশী রেফারেন্স হয় both নরম NUMA এবং হার্ড NUMA। আমি টিঙ্কার করব এবং দেখি আমি কিছু বুঝতে পারি কিনা।

— sql_handle