আমাদের গ্রাহকদের একজন, আমাদের অ্যাপ্লিকেশনটিতে কিছু পারফরম্যান্স সমস্যা রয়েছে। এটি একটি .NET 3.5 ওয়েব অ্যাপ্লিকেশন যা এসকিউএল সার্ভার ডাটাবেসে ডেটা গ্রহণ এবং আপডেট করে। বর্তমানে আমাদের উত্পাদন পরিবেশে উইন্ডোজ 2008 আর 2 মেশিনটিকে সামনের প্রান্ত হিসাবে এবং পিছনের প্রান্তে একটি এসকিউএল সার্ভার 2008 আর 2 ক্লাস্টার নিয়ে গঠিত। আমাদের অ্যাপ্লিকেশনটি ডাটাবেসের সাথে সংযোগ করতে COM + এবং MSDTC ব্যবহার করে।
এখানে যা ঘটছে তা এখানে রয়েছে: আমাদের শেষ ব্যবহারকারীরা মাঝে মধ্যে অ্যাপ্লিকেশনটিতে স্বল্পতার অভিযোগ করেন। কিছু পৃষ্ঠাগুলি প্রত্যাশার চেয়ে লোড হতে আরও কিছুটা সময় নেয়। কী ঘটছে তা জানার চেষ্টা করার সময়, আমি ডাটাবেস সাইডে কিছু অদ্ভুত আচরণ সন্ধান করলাম যা পারফরম্যান্স অবক্ষয়ের কারণ হতে পারে। আমি লক্ষ্য করেছি যে কখনও কখনও কিছু এসকিউএল স্টেটমেন্ট থাকে যা চালানোর জন্য অনেক বেশি সময় নেয় যা প্রত্যাশিত হবে। দীর্ঘ চলমান অনুসন্ধানগুলি সনাক্ত করতে আমি প্রোফাইলার ট্রেস (টিএসকিউএল_ডোরেশন টেমপ্লেট সহ) ব্যবহার করে এই বিবৃতিগুলির কয়েকটি (মূলত এটি আমাদের অ্যাপ্লিকেশনটির কিছু সঞ্চিত পদ্ধতির অনুরোধ) সনাক্ত করতে সক্ষম হয়েছি।
সমস্যাটি হ'ল আমি যখন এসকিউএল ম্যানেজমেন্ট স্টুডিওতে সরাসরি ডাটাবেসে এই স্টোরেজ পদ্ধতিগুলি চালিত করি তখন কখনও কখনও তারা দীর্ঘ সময় নেয় (প্রায় 7/8 সেকেন্ড), অন্য সময় তারা দ্রুত হয় (1 সেকেন্ডের নীচে)। আমি জানি না কেন এটি হয় এবং এটি আমাকে বাদাম চালায়, কারণ এসকিউএল মেশিন (4 কোর, 32 জিবি) অন্য কোনও অ্যাপ্লিকেশন ব্যবহার করছে না, এবং এই অনুসন্ধানগুলি চালাতে বেশি সময় নেওয়া উচিত নয়।
ডিবিএ বা এসকিউএল সার্ভার গুরু না হয়ে আমি এমন কিছু জিনিস দেখার চেষ্টা করছিলাম যা আমাকে সমস্যা বুঝতে সাহায্য করতে পারে। সমস্যাটি সমাধান এবং সমাধান করার জন্য আমি যে পদক্ষেপ নিয়েছি তা এখানে এবং আমি এখন পর্যন্ত কী খুঁজে পেয়েছি:
- অ্যাপ্লিকেশন দ্বারা ডাকা সমস্ত টিএসকিউএল কোড সঞ্চিত পদ্ধতিতে লিখিত।
- আমি এসকিউএল সার্ভার প্রোফাইলে লম্বা চলমান কিছু কোয়েরি সনাক্ত করেছি, তবে আমি ম্যানেজমেন্ট স্টুডিওতে চালানোর সময় এগুলি চালাতে দীর্ঘ সময় নেয় (4 থেকে 10 সেকেন্ড থেকে)) বা দ্রুত চালিত হয় (1 সেকেন্ডের নীচে)। আমি প্যারামিটারগুলিতে পাস করা একই ডেটা দিয়ে ঠিক একই ক্যোয়ারী চালাচ্ছি। এই ক্যোয়ারীগুলি প্রধানত সেগুলির মধ্যে নির্বাচিত বিবৃতি সহ প্রক্রিয়া সঞ্চিত থাকে।
- আমি চেষ্টা করেছি অপেক্ষাগুলি এবং সারিগুলির পরিসংখ্যানগুলি চেষ্টা করে দেখার জন্য এবং যদি কিছু সংস্থার জন্য অপেক্ষার প্রসেস রয়েছে কিনা। আমি নিম্নলিখিত কোয়েরি চালিয়েছি:
WITH Waits AS
(SELECT
wait_type,
wait_time_ms / 1000.0 AS WaitS,
(wait_time_ms - signal_wait_time_ms) / 1000.0 AS ResourceS,
signal_wait_time_ms / 1000.0 AS SignalS,
waiting_tasks_count AS WaitCount,
100.0 * wait_time_ms / SUM (wait_time_ms) OVER() AS Percentage,
ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS RowNum
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN (
'CLR_SEMAPHORE', 'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE', 'SLEEP_TASK',
'SLEEP_SYSTEMTASK', 'SQLTRACE_BUFFER_FLUSH', 'WAITFOR', 'LOGMGR_QUEUE',
'CHECKPOINT_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BROKER_TO_FLUSH',
'BROKER_TASK_STOP', 'CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE',
'FT_IFTS_SCHEDULER_IDLE_WAIT', 'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'BROKER_EVENTHANDLER',
'TRACEWRITE', 'FT_IFTSHC_MUTEX', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
'BROKER_RECEIVE_WAITFOR', 'ONDEMAND_TASK_QUEUE', 'DBMIRROR_EVENTS_QUEUE',
'DBMIRRORING_CMD', 'BROKER_TRANSMITTER', 'SQLTRACE_WAIT_ENTRIES',
'SLEEP_BPOOL_FLUSH', 'SQLTRACE_LOCK')
)
SELECT
W1.wait_type AS WaitType,
CAST (W1.WaitS AS DECIMAL(14, 2)) AS Wait_S,
CAST (W1.ResourceS AS DECIMAL(14, 2)) AS Resource_S,
CAST (W1.SignalS AS DECIMAL(14, 2)) AS Signal_S,
W1.WaitCount AS WaitCount,
CAST (W1.Percentage AS DECIMAL(4, 2)) AS Percentage,
CAST ((W1.WaitS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgWait_S,
CAST ((W1.ResourceS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgRes_S,
CAST ((W1.SignalS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgSig_S
FROM Waits AS W1
INNER JOIN Waits AS W2 ON W2.RowNum <= W1.RowNum
GROUP BY W1.RowNum, W1.wait_type, W1.WaitS, W1.ResourceS, W1.SignalS, W1.WaitCount, W1.Percentage
HAVING SUM (W2.Percentage) - W1.Percentage < 95; -- percentage threshold
GO
আমি যা জানতে পেরেছি তা এখানে:
- আমি ডিবিসিসি এসকিউএলপিআরএফ (প্রায় 1 বা 2 ঘন্টা পরে) ব্যবহার করে পরিসংখ্যানগুলি পুনরায় সেট করার পরে, আমার সবচেয়ে বেশি অপেক্ষা করার ধরণগুলি হ'ল SOS_SCHEDULER_YIELD এবং WRITELOG
- সময়ের সাথে সাথে (প্রায় 1 দিনের মৃত্যুদন্ড কার্যকর হওয়ার পরে), ডাটাবেসে সর্বাধিক ঘটে যাওয়া ওয়েটের ধরণগুলি হ'ল সিএক্সপ্যাকেট (% 67%) এবং ওএইলডিবি (১%%), যদিও প্রত্যেকটির জন্য অপেক্ষা করার গড় সময় দীর্ঘ হয় না। আমি আরও লক্ষ্য করেছি যে এসকিউএল প্রোফাইলারে চিহ্নিত হওয়া দীর্ঘ চলমান বিবৃতিগুলি সঞ্চিত প্রক্রিয়াগুলিতে কল যা একাধিক রেজাল্ট (প্রায়ই 3) ফেরত দেয়। এখানে কি প্যারালাইলেজমের সমস্যা হতে পারে? এই সমস্যাটির কারণ কিনা তা চিহ্নিত করার চেষ্টা করার কোন উপায় আছে কি?
- আমি কোথাও পড়েছি যে লিখিত সার্ভারের মতো OLEDB সংস্থানগুলিতে কল করার কারণে OLEDB অপেক্ষা করতে পারে। ইনডেক্সিং সার্ভিস মেশিন (এমএসআইডিএক্সএস) এর সাথে সংযোগ স্থাপনের জন্য আমাদের একটি লিঙ্কযুক্ত সার্ভার রয়েছে তবে দীর্ঘকাল চলমান হিসাবে চিহ্নিত কোনও বিবৃতি সেই লিঙ্কযুক্ত সার্ভারটি ব্যবহার করে না।
- আমার কাছে উচ্চতর গড় অপেক্ষা সময়টি এলসিকে_এম_এক্স টাইপের অপেক্ষা (প্রায় 1.5 সেকেন্ড গড়) এর জন্য, তবে এই অপেক্ষার প্রকারগুলি অন্যান্য ধরণের তুলনায় খুব ঘন ঘন ঘটে না (উদাহরণস্বরূপ, 64 এলসিকে_এম_এক্স 10,823 সিক্সপ্যাক্যাট অপেক্ষা একই সময়ের জন্য অপেক্ষা করে) )।
- একটি জিনিস আমি লক্ষ্য করেছি যে এমএসডিটিসি পরিষেবা ক্লাস্টার নয়। এসকিউএল সার্ভার পরিষেবা ক্লাস্টার্ড তবে এমএসডিটিসি নয়। এর কারণে কোনও পারফরম্যান্স হিট হতে পারে? আমরা এমএসডিটিসি ব্যবহার করছি কারণ আমাদের অ্যাপ্লিকেশনটি ডেটাবেস অ্যাক্সেস করতে এন্টারপ্রাইজ পরিষেবাদি (ডিসিওএম) ব্যবহার করে তবে সার্ভারগুলি আমাদের দ্বারা ইনস্টল করা হয়নি এবং আমাদের ক্লায়েন্টের দ্বারা কনফিগার করা হয়নি।
কেউ কি আমাকে এই ডেটাটি আরও কিছু বোঝার জন্য সহায়তা করতে পারে? কি ঘটতে পারে তা বুঝতে কেউ আমাকে সাহায্য করতে পারেন? চেষ্টা করার এবং জিনিসগুলি বের করার জন্য আমি সার্ভারে কিছু করতে পারি? আমার কি অ্যাপ্লিকেশন ডেভলপমেন্ট টিমের সাথে কথা বলা উচিত?
exec()ফাংশন ব্যবহার করা পর্যবেক্ষণ আচরণ ব্যাখ্যা করবে। এই ক্ষেত্রে ব্যবহার করেsp_executesqlস্বাভাবিকভাবে গতিশীল এসকিউএল স্টেটমেন্ট সমস্যা সমাধান করা হয়েছে।