আমি একটি অ্যাপ্লিকেশনে ধীর-ডাউনগুলি নির্ণয়ের চেষ্টা করছি। এর জন্য আমি এসকিউএল সার্ভার বর্ধিত ইভেন্টগুলি লগ করেছি ।
- এই প্রশ্নের জন্য আমি একটি নির্দিষ্ট সঞ্চিত পদ্ধতিটি দেখছি।
- তবে এক ডজন সঞ্চিত প্রক্রিয়াগুলির একটি মূল সেট রয়েছে যা আপেল থেকে আপেল তদন্ত হিসাবে সমানভাবে ব্যবহার করা যেতে পারে
- এবং যখনই আমি ম্যানুয়ালি স্টোর করা পদ্ধতিগুলির একটি চালাই, এটি সর্বদা দ্রুত চলে
- এবং যদি কোনও ব্যবহারকারী আবার চেষ্টা করে: এটি দ্রুত চলবে।
সঞ্চিত পদ্ধতির কার্য সম্পাদনের সময়গুলি বন্যভাবে পরিবর্তিত হয়। এই সঞ্চিত প্রক্রিয়াটির অনেকগুলি মৃত্যুদণ্ড <1 সেকেন্ডে ফিরে আসে:
এবং সেই "দ্রুত" বালতিটির জন্য এটি 1 এস এর চেয়ে অনেক কম। এটি আসলে প্রায় 90 এমএসের কাছাকাছি:
তবে ব্যবহারকারীদের একটি দীর্ঘ লেজ রয়েছে যাদের 2s, 3s, 4s সেকেন্ড অপেক্ষা করতে হবে। কিছু 12s, 13s, 14s অপেক্ষা করতে হবে। তারপরে সত্যিকার অর্থে দরিদ্র আত্মারা আছেন যাদের 22, 23, 24 সেকেন্ড অপেক্ষা করতে হবে।
এবং 30 এর পরে, ক্লায়েন্ট অ্যাপ্লিকেশনটি ছেড়ে দেয়, ক্যোয়ারীটি বাতিল করে দেয় এবং ব্যবহারকারীকে 30 সেকেন্ড অপেক্ষা করতে হয়েছিল ।
কার্যকারণ সন্ধানের সাথে সম্পর্ক
তাই আমি সম্পর্ক স্থাপন করার চেষ্টা করেছি:
- সময়কাল বনাম লজিকাল রিড
- সময়কাল বনাম শারীরিক পড়া
- সময়কাল বনাম সিপিইউ সময়
এবং কেউ কোনও সম্পর্ক বলে মনে হয় না; কারও পক্ষে কারণ মনে হয় না
যৌক্তিক বনাম সময়কাল বনাম : সামান্য, বা অনেকগুলি লজিকাল পঠিত হোক, সময়কালটি এখনও বন্যভাবে ওঠানামা করে :
সময়কাল বনাম শারীরিক পাঠ : এমনকি যদি ক্যোয়ারী থেকে ক্যোয়ারী সরবরাহ করা হয়নি, এবং প্রচুর শারীরিক পাঠের প্রয়োজন ছিল, এটি সময়কালকে প্রভাবিত করে না:
পিরিয়ড বনাম সিপিইউ সময় : ক্যোয়ারিতে সিপিইউ এর 0 সেকেন্ড সময় লেগেছে, বা সিপিইউর পুরো 2.5s সময়সই সময়সীমা একই রকম হয়:
বোনাস : আমি লক্ষ্য করেছি যে সময়কাল বনাম ফিজিকাল রিডস এবং সময়কাল ভি সিপিইউ সময় দেখতে অনেকটা মিল। আমি সিপিইউর সময় শারীরিক পড়ার সাথে পারস্পরিক সম্পর্ক স্থাপন করার চেষ্টা করলে এটি প্রমাণিত হয়:
I / O থেকে প্রচুর সিপিইউ ব্যবহার আসে। কে জানত!
সুতরাং যদি ক্যোয়ারি কার্যকর করার কাজ সম্পর্কে কিছুই না থাকে যা মৃত্যুদণ্ডের সময়গুলির পার্থক্যের জন্য অ্যাকাউন্ট করতে পারে, তার মানে কি এটি সিপিইউ বা হার্ড ড্রাইভের সাথে সম্পর্কযুক্ত কিছু নয়?
সিপিইউ বা হার্ড ড্রাইভ যদি বাধা থাকত; এটা কি বাধা হবে না?
যদি আমরা অনুমান করি যে এটি সিপিইউই ছিল বাধা; এই সার্ভারটির জন্য সিপিইউ আন্ডার পাওয়ারযুক্ত:
- তাহলে আরও সিপিইউ ব্যবহার করে মৃত্যুদণ্ড কার্যকর করতে বেশি সময় লাগবে না?
- ওভারলোডেড সিপিইউ ব্যবহার করে তাদের অন্যদের সাথে শেষ করতে হবে?
একইভাবে হার্ড-ড্রাইভগুলির জন্য। যদি আমরা অনুমান করি যে হার্ড-ড্রাইভটি একটি বাধা ছিল; হার্ড-ড্রাইভগুলির মধ্যে এই সার্ভারটির জন্য পর্যাপ্ত এলোমেলো পরিমাণ নেই:
- তাহলে আরও শারীরিক পাঠ ব্যবহার করে মৃত্যুদণ্ড কার্যকর করতে বেশি সময় লাগবে না?
- যেহেতু তাদের অতিরিক্ত লোড হার্ড-ড্রাইভ I / O ব্যবহার করে অন্যের সাথে সম্পূর্ণ করতে হবে?
সঞ্চিত পদ্ধতি নিজেই কোনও লিখিত করে না, প্রয়োজন হয় না।
- সাধারণত এটি 0 টি সারি (90%) দেয়।
- কখনও কখনও এটি 1 সারি (7%) ফিরে আসবে।
- কদাচিৎ এটি 2 টি সারি (1.4%) ফিরে আসবে।
- এবং সবচেয়ে খারাপ ক্ষেত্রে এটি 2 টিরও বেশি সারি ফিরেছে (এক বার 12 সারি ফেরত)
সুতরাং এটি ডেটার একটি উন্মাদ ভলিউম ফিরে আসার মতো নয়।
সার্ভার সিপিইউ ব্যবহার
সার্ভারের প্রসেসরের ব্যবহারের গড় পরিমাণ প্রায় 1.8%, মাঝে মাঝে স্পাইক 18% অবধি থাকে - সুতরাং এটি মনে হয় না যে সিপিইউ লোড একটি সমস্যা:
সুতরাং সার্ভার সিপিইউ ওভারলোডেড বলে মনে হচ্ছে না।
কিন্তু সার্ভার হল ভার্চুয়াল ...
মহাবিশ্বের বাইরের কিছু?
কেবলমাত্র আমি যা কল্পনা করতে পারি তা হ'ল এমন কিছু যা সার্ভারের মহাবিশ্বের বাইরে বিদ্যমান।
- যদি এটি যৌক্তিক না হয়
- এবং এটি শারীরিক পড়া না
- এবং এটি সিপিইউ ব্যবহার নয়
- এবং এটি সিপিইউ লোড নয়
এবং এটি সঞ্চিত পদ্ধতির পরামিতিগুলির মতো নয় (কারণ একই প্রশ্নটি নিজেই জারি করা হচ্ছে এবং এটি 27 সেকেন্ড নেয় না - এটি ~ 0 সেকেন্ড সময় নেয়)।
একই সংকলিত সঞ্চিত প্রক্রিয়াটি চালানোর জন্য সার্ভারের জন্য 0 সেকেন্ডের চেয়ে 30 সেকেন্ডের চেয়ে 30 সেকেন্ড সময় নেওয়ার জন্য আর কী হতে পারে?
- চেকপয়েন্ট?
এটি ভার্চুয়াল সার্ভার
- হোস্ট ওভারলোডড?
- একই হোস্টে অন্য ভিএম?
সার্ভারের বর্ধিত ইভেন্টগুলির মধ্য দিয়ে যাচ্ছেন; হঠাৎ করে 20 সেকেন্ডের সময় যখন কোনও ক্যোয়ারী লাগে তখন আর কিছুই হয় না। এটি সূক্ষ্মভাবে চলে, তারপর জরিমানা না চালানোর সিদ্ধান্ত নেয়:
- ২ সেকেন্ড
- 1 সেকেন্ড
- 30 সেকেন্ড
- 3 সেকেন্ড
- ২ সেকেন্ড
এবং আমি খুঁজে পেতে পারে এমন নির্দিষ্ট কোন কঠোর আইটেম নেই। এটি প্রতি 2-ঘন্টা লেনদেন লগ ব্যাকআপের সময় নয়।
এটা আর কি হতে পারে?
"সার্ভার" ছাড়াও আমি কি আরও কিছু বলতে পারি ?
সম্পাদনা করুন : দিনের সাথে সাথে সম্পর্কযুক্ত
আমি বুঝতে পেরেছি যে আমি সমস্ত কিছুর সাথে সময়সীমাগুলি সংযুক্ত করেছি:
- যৌক্তিক পড়া
- শারীরিক পড়া
- CPU 'র ব্যবহার
তবে যে জিনিসটির সাথে আমি এর সাথে সম্পর্কযুক্ত তা হ'ল দিনের সময় । সম্ভবত যে-2 ঘণ্টার লেনদেনের লগ ব্যাকআপ হয় একটি সমস্যা।
অথবা সম্ভবত মন্থরতার না চেকপয়েন্ট সময় Chucks ঘটে?
নাঃ:
ইন্টেল জিওন গোল্ড কোয়াড-কোর 6142।
সম্পাদনা করুন - লোকেরা ক্যোয়ারি এক্সিকিউশন প্ল্যানটিকে হাইপোথাইজ করছে
লোকেরা ক্যোয়ারি এক্সিকিউশন পরিকল্পনা অনুমান করছে "দ্রুত" এবং "ধীর" এর মধ্যে অবশ্যই আলাদা হওয়া উচিত। তারা না.
এবং আমরা অবিলম্বে পরিদর্শন থেকে এটি দেখতে পারি।
আমরা জানি দীর্ঘতর প্রশ্নের সময়কাল "দুর্বল" কার্যকরকরণ পরিকল্পনার কারণে নয়:
- যে আরও যুক্তিযুক্ত পড়া গ্রহণ করেছে
- এক যে আরও বেশি যোগ দেয় এবং কী দেখার জন্য আরও সিপিইউ গ্রহণ করেছিল
কারণ যদি পাঠাগুলিতে বৃদ্ধি, বা সিপিইউতে বৃদ্ধি, কোয়েরি সময়কাল বাড়ানোর কারণ ছিল, তবে আমরা ইতিমধ্যে এটি উপরে দেখেছি। কোনও সম্পর্ক নেই।
তবে সিপিইউ-রিডস এরিয়া পণ্য মেট্রিকের সাথে সময়কাল সম্পর্কযুক্ত করার চেষ্টা করতে দিন:
একটি পারস্পরিক সম্পর্ক এমনকি কম হয় - যা একটি প্যারাডক্স।
সম্পাদনা : স্কেলার ডায়াগ্রামগুলি আপডেট করে এক্সেল স্ক্যাটার প্লটগুলিতে একটি বিশাল সংখ্যক মান সহ একটি বাগ সমাধান করতে পারেন।
পরবর্তী পদক্ষেপ
আমার পরবর্তী পদক্ষেপগুলি হ'ল 5 সেকেন্ডের পরে - কাউকে অবরুদ্ধ প্রশ্নের জন্য ইভেন্টগুলি উত্পন্ন করার জন্য সার্ভারকে পেতে হবে :
EXEC sp_configure 'blocked process threshold', '5';
RECONFIGURE
প্রশ্নগুলি 4 সেকেন্ডের জন্য অবরুদ্ধ করা হয়েছে কিনা তা এটি ব্যাখ্যা করবে না । তবে সম্ভবত এমন কোনও কিছু যা 5 সেকেন্ডের জন্য কোনও ক্যোয়ারিকে ব্লক করে দেয় কিছু 4 সেকেন্ডের জন্যও অবরুদ্ধ করে।
স্লো প্ল্যানস
দুটি সঞ্চিত প্রক্রিয়াটির স্লোপ্ল্যান এখানে কার্যকর করা হচ্ছে:
- Find ফাইন্ডফ্রোব @ কাস্টোমারআইডি = 7383, @ স্টার্টডেট = '20190725 04: 00: 00.000', @ শেষ তারিখ = '20190726 04: 00: 00.000'
- Find ফাইন্ডফ্রোব @ কাস্টোমারআইডি = 7383, @ স্টার্টডেট = '20190725 04: 00: 00.000', @ শেষ তারিখ = '20190726 04: 00: 00.000'
একই প্যারামিটার সহ একই সঞ্চিত পদ্ধতিটি পিছনে পিছনে চালান:
| Duration (us) | CPU time (us) | Logical reads | Physical reads |
|---------------|---------------|---------------|----------------|
| 13,984,446 | 47,000 | 5,110 | 771 |
| 4,603,566 | 47,000 | 5,126 | 740 |
কল করুন 1:
|--Nested Loops(Left Semi Join, OUTER REFERENCES:([Contoso2].[dbo].[Frobs].[FrobGUID]) OPTIMIZED)
|--Nested Loops(Inner Join, OUTER REFERENCES:([Contoso2].[dbo].[FrobTransactions].[OnFrobGUID]))
| |--Nested Loops(Inner Join, OUTER REFERENCES:([Contoso2].[dbo].[FrobTransactions].[RowNumber]) OPTIMIZED)
| | |--Nested Loops(Inner Join, OUTER REFERENCES:([tpi].[TransactionGUID]) OPTIMIZED)
| | | |--Nested Loops(Inner Join, OUTER REFERENCES:([tpi].[TransactionGUID]) OPTIMIZED)
| | | | |--Index Seek(OBJECT:([Contoso2].[dbo].[TransactionPatronInfo].[IX_TransactionPatronInfo_CustomerID_TransactionGUID] AS [tpi]), SEEK:([tpi].[CustomerID]=[@CustomerID]) ORDERED FORWARD)
| | | | |--Index Seek(OBJECT:([Contoso2].[dbo].[Transactions].[IX_Transactions_TransactionGUIDTransactionDate]), SEEK:([Contoso2].[dbo].[Transactions].[TransactionGUID]=[Contoso2].[dbo
| | | |--Index Seek(OBJECT:([Contoso2].[dbo].[FrobTransactions].[IX_FrobTransactions2_MoneyAppearsOncePerTransaction]), SEEK:([Contoso2].[dbo].[FrobTransactions].[TransactionGUID]=[Contos
| | |--Clustered Index Seek(OBJECT:([Contoso2].[dbo].[FrobTransactions].[IX_FrobTransactions_RowNumber]), SEEK:([Contoso2].[dbo].[FrobTransactions].[RowNumber]=[Contoso2].[dbo].[Fin
| |--Clustered Index Seek(OBJECT:([Contoso2].[dbo].[Frobs].[PK_Frobs_FrobGUID]), SEEK:([Contoso2].[dbo].[Frobs].[FrobGUID]=[Contoso2].[dbo].[FrobTransactions].[OnFrobGUID]), WHERE:([Contos
|--Filter(WHERE:([Expr1009]>(1)))
|--Compute Scalar(DEFINE:([Expr1009]=CONVERT_IMPLICIT(int,[Expr1012],0)))
|--Stream Aggregate(DEFINE:([Expr1012]=Count(*)))
|--Index Seek(OBJECT:([Contoso2].[dbo].[FrobTransactions].[IX_FrobTransactins_OnFrobGUID]), SEEK:([Contoso2].[dbo].[FrobTransactions].[OnFrobGUID]=[Contoso2].[dbo].[Frobs].[LC
কল 2
|--Nested Loops(Left Semi Join, OUTER REFERENCES:([Contoso2].[dbo].[Frobs].[FrobGUID]) OPTIMIZED)
|--Nested Loops(Inner Join, OUTER REFERENCES:([Contoso2].[dbo].[FrobTransactions].[OnFrobGUID]))
| |--Nested Loops(Inner Join, OUTER REFERENCES:([Contoso2].[dbo].[FrobTransactions].[RowNumber]) OPTIMIZED)
| | |--Nested Loops(Inner Join, OUTER REFERENCES:([tpi].[TransactionGUID]) OPTIMIZED)
| | | |--Nested Loops(Inner Join, OUTER REFERENCES:([tpi].[TransactionGUID]) OPTIMIZED)
| | | | |--Index Seek(OBJECT:([Contoso2].[dbo].[TransactionPatronInfo].[IX_TransactionPatronInfo_CustomerID_TransactionGUID] AS [tpi]), SEEK:([tpi].[CustomerID]=[@CustomerID]) ORDERED FORWARD)
| | | | |--Index Seek(OBJECT:([Contoso2].[dbo].[Transactions].[IX_Transactions_TransactionGUIDTransactionDate]), SEEK:([Contoso2].[dbo].[Transactions].[TransactionGUID]=[Contoso2].[dbo
| | | |--Index Seek(OBJECT:([Contoso2].[dbo].[FrobTransactions].[IX_FrobTransactions2_MoneyAppearsOncePerTransaction]), SEEK:([Contoso2].[dbo].[FrobTransactions].[TransactionGUID]=[Contos
| | |--Clustered Index Seek(OBJECT:([Contoso2].[dbo].[FrobTransactions].[IX_FrobTransactions_RowNumber]), SEEK:([Contoso2].[dbo].[FrobTransactions].[RowNumber]=[Contoso2].[dbo].[Fin
| |--Clustered Index Seek(OBJECT:([Contoso2].[dbo].[Frobs].[PK_Frobs_FrobGUID]), SEEK:([Contoso2].[dbo].[Frobs].[FrobGUID]=[Contoso2].[dbo].[FrobTransactions].[OnFrobGUID]), WHERE:([Contos
|--Filter(WHERE:([Expr1009]>(1)))
|--Compute Scalar(DEFINE:([Expr1009]=CONVERT_IMPLICIT(int,[Expr1012],0)))
|--Stream Aggregate(DEFINE:([Expr1012]=Count(*)))
|--Index Seek(OBJECT:([Contoso2].[dbo].[FrobTransactions].[IX_FrobTransactins_OnFrobGUID]), SEEK:([Contoso2].[dbo].[FrobTransactions].[OnFrobGUID]=[Contoso2].[dbo].[Frobs].[LC
পরিকল্পনাগুলি অভিন্ন হওয়ার জন্য এটি অর্থবোধ করে; এটি একই প্যারামিটারগুলির সাথে একই সঞ্চিত পদ্ধতিটি কার্যকর করছে।