এসকিউএল সার্ভারে উচ্চ সিপিইউ ব্যবহার - ধীর অনুসন্ধানগুলি [বন্ধ]

Question

আমাদের এমএস এসকিউএল সার্ভার CPU- পাওয়ারের প্রায় 95% ব্যবহার করছে using

কোনও সার্ভার (হার্ডওয়্যার) পুনঃসূচনা করার পরে, বা এসকিউএল-পরিষেবা পুনরায় চালু হওয়ার পরে, ব্যবহারটি 0% হয় এবং ধীরে ধীরে 1-3 দিনের মধ্যে ধীরে ধীরে বৃদ্ধি পায়। এটি কতটা ব্যবহৃত হয় তার উপর নির্ভর করে।

এটি যখন ৮০% এর বেশি হয়, তখন প্রতিটি ক্যোয়ারী অত্যন্ত ধীর হয়।

আমাদের ওয়েবসাইট প্রচুর বড় বড় প্রশ্নের সাথে কাজ করছে, তাই তাদের মধ্যে 45-60 সেকেন্ড সময় লাগে। পুনঃসূচনা হওয়ার পরে (সিপিইউ ব্যবহারের 80% এরও কম), একই কোয়েরিতে 11-20 সেকেন্ড সময় লাগে।

---

আমি এটা কিভাবে ঠিক করবো? আমি অনলাইনে পড়েছি যে অ্যাফিনিটি মাস্কগুলি সিপিইউ ব্যবহারটি সামঞ্জস্য করতে পারে তবে অ্যাফিনিটি সেটিংস অক্ষম করা হয়। আমি তাদের পরিবর্তন করতে পারি না। আমার কেবল 1 টি প্রসেসর থাকার কারণে এটি কি?

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

তাদের বেশিরভাগ ইতিমধ্যে বেশ ভালভাবে অনুকূলিত হয়েছে।

---

আমি এসকিউএল-পরিষেবাটি পুনরায় চালু করতে পারি না, যদিও এটি কেবল 2 সেকেন্ড সময় নেয়, কারণ আমাদের কাছে একটি অ্যালার্ম পরিষেবা রয়েছে যা লোককে কল করতে এবং একটি বার্তা রেকর্ড করতে দেয়, একটি নির্বাচিত গোষ্ঠীটি ডেকে রেকর্ড করা বার্তাটি শুনতে পাবে।

এই সিস্টেমটি কয়েক'শ অনুসন্ধান এবং উদ্ধারকারী দল দ্বারা ব্যবহৃত হয় এবং যদি এসকিউএল-পরিষেবাটি একটি অ্যালার্মের সময় পুনরায় চালু হয়, এটি শেষ হয়ে যাবে এবং যে ব্যক্তি এটিতে ফোন করেছে তাকে অবহিত করা হবে না।

---

আমি সমস্ত জায়গা জুড়ে অনুসন্ধান করেছি, তবে "অ্যাফিনিটি মাস্কস" সম্পর্কিত স্টাফ ব্যতীত আর কিছুই পাইনি, যা আমি পরিবর্তন করতে পারি না।

সিপিইউ ক্যাশে সাফ করার একটি উপায় অবশ্যই আছে, বর্তমান প্রশ্নগুলি শেষ না করে ... তাই না?

---

SQL: Microsoft SQL Server 11.0.2100.60
OS: Windows Server 2012 x64
Processor: 2.30 GHz
RAM: 4.00 GB

Comments

মন্তব্যগুলি বর্ধিত আলোচনার জন্য নয়; এই কথোপকথন চ্যাটে সরানো হয়েছে ।

— পল হোয়াইট 9

Answer 1

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

DBCC FREEPROCCACHE

কাজ করা ক্যাশে সাফ করে দিলে বাধ্য প্যারামিট্রাইজেশন সেটিংস কী তা দেখতে আপনি পরীক্ষা করতে পারেন:

SELECT name
     , is_parameterization_forced
  FROM sys.databases;

এটি সম্ভবত 0 এ সেট করা হয়েছে, ডিফল্ট। যদি তারা চান, আপনি এটি করে এটি সত্য করে দিতে পারেন:

ALTER DATABASE [database_name] SET PARAMETERIZATION FORCED;

এটি প্রথমে কোনও পরিবেশ পরিবেশে করা উচিত এবং দেখুন এটি অন্যভাবে ডেটাবেসকে নেতিবাচকভাবে প্রভাবিত করে কিনা। এটি ব্যবহার করে ফেরানো যেতে পারে:

ALTER DATABASE [database_name] SET PARAMETERIZATION SIMPLE;

Comments

নোট করুন যে পদ্ধতি ক্যাশে মুক্ত করা আসলে সিপিইউতে একটি বিশাল স্পাইকের কারণ হতে পারে - যেহেতু সমস্ত প্রশ্নের এখনই তাদের কার্যকর করার পরিকল্পনাগুলি পুনরায় সংকলন করতে হবে।

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

Answer 2

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

সিপিইউ ক্যাশে এছাড়াও একটি খরগোশের গর্ত যা আপনার নীচে নামার দরকার নেই। আপনার সিপিইউ ক্যাশে নিয়ে সমস্যার কারণে আপনার সিপিইউ 95% এ ছোঁড়াচ্ছে বলে আমি অত্যন্ত সন্দেহ করি।

সিপিইউ চাপের উত্সকে সংকুচিত করতে এবং আপনি সঞ্চিত প্রক্রিয়া ব্যবহার করছেন তা ধরে নেওয়ার জন্য, আপনি গ্লেন বেরি ( এখান থেকে উত্সাহিত ) থেকে এই ডায়াগোনস্টিক কোয়েরিটি একবার দেখে নিতে পারেন - নিশ্চিত করুন যে আপনি এটি সঠিক ডাটাবেসের প্রসঙ্গে চালাচ্ছেন:

-- Top Cached SPs By Total Worker time (SQL Server 2012). 
-- Worker time relates to CPU cost  (Query 44) (SP Worker Time)

SELECT TOP (25) 
  p.name AS [SP Name], 
  qs.total_worker_time AS [TotalWorkerTime], 
  qs.total_worker_time/qs.execution_count AS [AvgWorkerTime], 
  qs.execution_count, 
  ISNULL(qs.execution_count/DATEDIFF(Second, qs.cached_time, GETDATE()), 0) 
    AS [Calls/Second],
  qs.total_elapsed_time, 
  qs.total_elapsed_time/qs.execution_count AS [avg_elapsed_time], 
  qs.cached_time
FROM sys.procedures AS p WITH (NOLOCK)
INNER JOIN sys.dm_exec_procedure_stats AS qs WITH (NOLOCK)
ON p.[object_id] = qs.[object_id]
WHERE qs.database_id = DB_ID()
ORDER BY qs.total_worker_time DESC OPTION (RECOMPILE);

-- This helps you find the most expensive cached stored procedures from a CPU perspective
-- You should look at this if you see signs of CPU pressure

আপনি যদি সঞ্চিত পদ্ধতি ব্যবহার না করে থাকেন তবে জন স্যামসনের এই উদাহরণটি অ্যাডহক কোয়েরিগুলিকে আলাদা করতে সহায়তা করতে পারে ( এখান থেকে উত্সাহিত ):

SELECT TOP (25)
    qs.sql_handle,
    qs.execution_count,
    qs.total_worker_time AS Total_CPU,
    total_CPU_inSeconds = --Converted from microseconds
    qs.total_worker_time/1000000,
    average_CPU_inSeconds = --Converted from microseconds
    (qs.total_worker_time/1000000) / qs.execution_count,
    qs.total_elapsed_time,
    total_elapsed_time_inSeconds = --Converted from microseconds
    qs.total_elapsed_time/1000000,
    st.text,
    qp.query_plan
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS apply sys.dm_exec_query_plan (qs.plan_handle) AS qp
ORDER BY qs.total_worker_time DESC OPTION (RECOMPILE);

আপনি অ্যাডাম মাচানিকের sp_WhoIsAtive , একটি সঞ্চিত পদ্ধতি যা বর্তমানে চলমান সমস্ত প্রশ্নের দ্রুত বিশ্লেষণ করতে পারে এবং আপনি চান (তবে আপনার ক্ষেত্রে যেমন @sort_order = '[CPU] DESC') এটি সাজানোর অনুমতি দিতে পারেন এমন একটি সঞ্চিত পদ্ধতিও একবার দেখতে পারেন ।

আমি প্রথমে যা করব, যদিও - বিশেষত যদি এটি অনুসন্ধান এবং উদ্ধারকারী দলগুলির জন্য সত্যই মিশন সমালোচনা হয় - তবে আরও ভাল হার্ডওয়্যার কেনা উচিত। আপনার অ্যাপ্লিকেশনটি পরিষেবা দেওয়ার জন্য আপনার আরও সিপিইউ এবং আরও বেশি র‌্যাম থাকা উচিত। আপনার একেবারে আরও ভাল উচ্চ প্রাপ্যতা প্রয়োজন (যেমন ক্লাস্টারিং, মিররিং বা উপলভ্যতা গোষ্ঠী)। কোনও কারণ নেই যে কোনও শারীরিক মেশিনের পুনরায় বুট করা আপনার অ্যাপ্লিকেশনটিকে পুরোপুরি অফলাইনে নেবে - আমাদের সেই সমস্যার জন্য আরও ভাল সমাধান রয়েছে। এবং পরিশেষে, আমি অনুমান করি যে এই "সার্ভার" -এর মধ্যে কেবল একটি স্পিনি ডিস্ক ড্রাইভ রয়েছে। এর অর্থ হ'ল সমস্ত আই / ও - ওএস থেকে, এসকিউএল সার্ভার ডেটা ফাইলগুলি, লগ ফাইলগুলি, টেম্পডিবি ইত্যাদি etc. সমস্তই একটি একক নিয়ামকের মধ্য দিয়ে যায় এবং একক ড্রাইভে পড়ুন / লেখার ক্রিয়াকলাপ ভাগ করে দেয়। আরও ডিস্ক পান। আপনি যেখানে পারেন সেখানে এসএসডি পান। RAID ব্যবহার করুন এবং I / O যতটা সম্ভব ছড়িয়ে দেওয়ার চেষ্টা করুন।

এই সমস্ত বলেছে যে সমস্যার সময়ে হার্ডওয়্যার নিক্ষেপ করা কেবলমাত্র ফিক্সের অংশ হবে না। অতিরিক্ত সিপিইউ ব্যবহারের কারণ হ'ল আপনাকে একেবারে আলাদা করতে হবে এবং তারপরে আপনি যে কোনও হার্ডওয়্যারই থাকুন না কেন সমস্যা সমাধান করুন attack

আরও কিছু ধারণার জন্য এই স্ট্যাকওভারফ্লো প্রশ্নটি দেখুন:

/programming/945063/how-do-i-find-out-what-is-hammering-my-sql-server

Answer 3

নিম্নলিখিত পরামর্শগুলি হ'ল 'অন্ধকারের শট' কারণ আমি প্রকৃত কোড দেখতে পাচ্ছি না।

প্রথমটি হ'ল কোনও এসপি হতে পারে কার্সারগুলি খোলার এবং সেগুলি খোলা রেখে। কার্সারগুলি পড়ুন, বিশেষত ক্লোজ এবং ডিওলোকট। কেউ হয়ত বন্ধ করে দিচ্ছেন, তবে কার্সারকে বিচ্ছিন্ন করবেন না। আচরণটি আপগ্রেডের কারণে পরিবর্তিত হতে পারে, ২০১২ ২০০২ আর -২ থেকে বামে থাকা কার্সারের সাথে আলাদা আচরণ করতে পারে।

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

আপনি কি কোনও সুযোগেই উইনলিঙ্ক ব্যবহার করছেন? এই সম্পর্কে কিছু শব্দ অস্পষ্টভাবে পরিচিত।

Answer 4

পারফরম্যান্সটি উন্নত করতে আপনার ম্যাকচেডের মতো জায়গায় ক্যাচিং ব্যবস্থা থাকা উচিত

Comments

তবে এটি এসকিউএল-সার্ভারে সিপিইউ-ব্যবহার পরিবর্তন করবে না, তাই না? এটি কেবল ওয়েবসাইটগুলিতে কোয়েরিগুলিকে দ্রুত করে তুলবে, এবং সমস্যা হতে পারে যে কোনও টেবিলে কিছু পরিবর্তন করা হয়েছে যখন অন্য কেউ একই টেবিল থেকে ম্যাকচেড ফলাফল ব্যবহার করছে, তাই না?

— লেভি জোহেনসেন

@ লেভী যদি আপনি কোয়েরির ফলাফলগুলি মাঝারি স্তরের কোথাও ক্যাশে করেন তবে কোয়েরিগুলি ডাটাবেসটিকে হিট করবে না (কেবল যখন আপনাকে ক্যাশে রিফ্রেশ করার দরকার হবে তা বাদে)।

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

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

— টমটম