পৃষ্ঠা জীবন প্রত্যাশা উদাহরণটি সম্পর্কে কী বলে?

Question

আমি পরিবেশের কয়েকটি এসকিউএল সার্ভারের উদাহরণগুলিতে মনিটরিং সফটওয়্যার ইনস্টল করেছি। আমি বাধা আবিষ্কার করার চেষ্টা করছি এবং কিছু কার্য সম্পাদনের সমস্যাগুলি সমাধান করব। কিছু সার্ভারের আরও মেমরি দরকার কিনা তা আমি জানতে চাই।

আমি একটি কাউন্টারে আগ্রহী: পৃষ্ঠার আয়ু। এটি প্রতিটি মেশিনে আলাদা দেখাচ্ছে। কেন এটি কিছু পরিস্থিতিতে প্রায়ই পরিবর্তন হয় এবং এর অর্থ কী?

কয়েক সপ্তাহে কয়েকটি আলাদা মেশিনে জড়িত গত সপ্তাহের ডেটা একবার দেখুন। আপনি প্রতিটি উদাহরণ সম্পর্কে কি বলতে পারেন?

ভারী ব্যবহৃত উত্পাদনের উদাহরণ (1):

পরিমিতরূপে ব্যবহৃত উত্পাদন আইট্যান্স (2)

খুব কম ব্যবহৃত পরীক্ষার উদাহরণ (3)

ভারী ব্যবহৃত উত্পাদনের উদাহরণ (4)

পরিমিতরূপে ব্যবহৃত পরীক্ষার উদাহরণ (5)

ভারী ব্যবহৃত ডেটা গুদাম (6)

সম্পাদনা: আমি এই সমস্ত সার্ভারের জন্য নির্বাচিত @@ ভার্সনের আউটপুট যুক্ত করছি:

Instance 1: Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 
Jun 17 2011 00:54:03 Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 2: Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) 
Oct 19 2012 13:38:57 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 3: Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
May 14 2014 18:34:29 
    Copyright (c) Microsoft Corporation
 Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Instance 4: Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64) Jun 28 2012 08:36:30 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)


Instance 5: Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
May 14 2014 18:34:29 
Copyright (c) Microsoft Corporation
 Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Instance 6: Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 
Apr 2 2010 15:48:46 
Copyright (c) Microsoft Corporation
 Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

আমি মেশিনগুলিতে নিম্নলিখিত জিজ্ঞাসাও চালিয়েছি:

SELECT DISTINCT memory_node_id
FROM sys.dm_os_memory_clerks

এবং এটি প্রতিটি সার্ভারের জন্য 2 বা 3 টি সারি ফিরিয়ে দিয়েছে:

Instance 1: 0; 64; 1
Instance 2: 0; 64
Instance 3: 0; 64
Instance 4: 0; 64
Instance 5: 0; 64
Instance 6: 0; 64; 1

এর মানে কী? এই সার্ভারগুলি কি NUMA চালায়?

Comments

উদাহরণ 2

— টিতে

গ্রাফগুলির স্কেল সত্যিই সহায়তা করে না। দিনের বেলায় ব্যস্ত সার্ভারগুলি শূন্যের কাছাকাছি যাওয়ার বিষয়টি আরও আকর্ষণীয় হবে।

— জেমস জেড

আমি আরও বিস্তারিত ডেটা পেতে পারে আশা করি। আমি সোলারউইন্ডস ডাটাবেস পারফরম্যান্স মনিটর ব্যবহার করেছি এবং কোনও ফাইলে ডেটা রফতানি করার কোনও উপায় নেই। এটি করার একমাত্র উপায় হ'ল এটির ডাটাবেসটি অনুসন্ধান করা তবে কাঠামোটি স্বাভাবিক হয় না এবং ধরা সহজ হয় না।

— বুয়াহাএএক্সডি

হঠাৎ ড্রপগুলি বোঝার জন্য আপনাকে সাহায্য করার জন্য: যখন আনকচড ডেটার একটি বড় স্ক্যান কার্যকর করা হয় তখন নতুন পৃষ্ঠাগুলির জন্য জায়গা তৈরি করতে প্রচুর পৃষ্ঠাগুলি উচ্ছেদ করা হচ্ছে। এটি একটি পরিবর্তিত এলআরইউ অ্যালগরিদম। নতুন পৃষ্ঠাগুলি পুরানোগুলি ফেলে দেয়।

— usr

উদাহরণ 2 এবং 6 টি NUMA ব্যবহার করে, অন্যরা তা ব্যবহার করে না।

— বুয়াহাএক্সএক্সডি

Answer 1

এমএসডিএন থেকে নেওয়া: - https://msdn.microsoft.com/en-us/library/ms189628.aspx

পৃষ্ঠার আয়ু - কোনও পৃষ্ঠা উল্লেখ ছাড়াই বাফার পুলে কত সেকেন্ড থাকবে তা নির্দেশ করে।

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

আপনি অনলাইনে দেখে এমন কোনও পরামর্শ উপেক্ষা করুন যা এই কাউন্টারটির জন্য 300 হিসাবে একটি ভাল প্রান্তিক হিসাবে উল্লেখ করেছে

এই প্রান্তিকতা সেই দিন থেকে আসে যখন মেমরিটি সীমিত ছিল (32-বিট সিস্টেমগুলি ভাবেন)। এখন আমাদের কাছে 64৪-বিট সিস্টেম রয়েছে যার টিবি র‌্যাম থাকতে পারে তাই এই পরামর্শটি খুব পুরানো।

প্রথম জিনিস, আপনি কি এসকিউএল এর স্মৃতি সীমাবদ্ধ করেছেন? যদি তাই হয়, কত উপলব্ধ মেমরি বাকি? সীমা কি বাড়ানো যায়?

দ্বিতীয় জিনিসটি আমি আপনার সার্ভারগুলিতে সন্ধান করব, এটি কি কোনও রক্ষণাবেক্ষণ কাজ চলছে? সূচী পুনর্নির্মাণগুলি, আপডেটের পরিসংখ্যানগুলি বা ডিবিসিসি CHECKDB ক্রিয়াকলাপ সম্পাদন করে এমন কাজের জন্য পরীক্ষা করুন। এগুলি প্রচুর পরিমাণে পাঠ সম্পাদন করে এবং আপনার পিএলই ফ্ল্যাট আস্তরণের কারণ হতে পারে,

এরপরে, আপনি এসকিউএল সার্ভার ২০০৮-এর ব্যবহার হিসাবে, আপনি প্রচুর পরিমাণে পাঠ্যক্রমগুলি দেখছে এমন প্রশ্নগুলি ক্যাপচার করতে আপনি একটি বর্ধিত ইভেন্ট সেশন সেটআপ করতে পারেন। এটি করার কোডটি এখানে:

CREATE EVENT SESSION [QueriesWithHighLogicalReads] ON SERVER 
ADD EVENT sqlserver.sql_batch_completed(
   ACTION(sqlserver.client_hostname,sqlserver.database_name,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_stack,sqlserver.username)
     WHERE ([logical_reads]>200000))
ADD TARGET package0.event_file(SET filename=N'C:\SQLServer\XEvents\QueriesWithHighLogicalReads.xel')
GO

এটি আপনার সার্ভারে 200000 এরও বেশি যৌক্তিক পাঠ সম্পাদন করে এমন সমস্ত ক্যোয়ারিকে ক্যাপচার করবে। আমি জানি না প্রতিটি সার্ভারে আপনার কত স্মৃতি রয়েছে তাই আপনি এই চিত্রটি টুইঙ্ক করতে চাইতে পারেন। এটি তৈরি হয়ে গেলে আপনি অধিবেশনটি চালিয়ে শুরু করতে পারেন: -

ALTER EVENT SESSION [QueriesWithHighLogicalReads]
ON SERVER
STATE = START;
GO

এবং তারপরে অধিবেশনটি চালিয়ে জিজ্ঞাসা করুন: -

WITH CTE_ExecutedSQLStatements AS
(SELECT
[XML Data],
[XML Data].value('(/event[@name=''sql_statement_completed'']/@timestamp)[1]','DATETIME')    AS [Time],
[XML Data].value('(/event/data[@name=''duration'']/value)[1]','int')                        AS [Duration],
[XML Data].value('(/event/data[@name=''cpu_time'']/value)[1]','int')                        AS [CPU],
[XML Data].value('(/event/data[@name=''logical_reads'']/value)[1]','int')                   AS [logical_reads],
[XML Data].value('(/event/data[@name=''physical_reads'']/value)[1]','int')                  AS [physical_reads],
[XML Data].value('(/event/action[@name=''sql_text'']/value)[1]','varchar(max)')             AS [SQL Statement]
FROM
    (SELECT 
    OBJECT_NAME              AS [Event], 
    CONVERT(XML, event_data) AS [XML Data]
FROM 
    sys.fn_xe_file_target_read_file
('C:\SQLServer\XEvents\QueriesWithHighLogicalReads*.xel',NULL,NULL,NULL)) as v)

SELECT
[SQL Statement]     AS [SQL Statement],
SUM(Duration)       AS [Total Duration],
SUM(CPU)            AS [Total CPU],
SUM(Logical_Reads)  AS [Total Logical Reads],
SUM(Physical_Reads) AS [Total Physical Reads]
FROM
CTE_ExecutedSQLStatements
GROUP BY
[SQL Statement]
ORDER BY
[Total Logical Reads] DESC
GO

এটি চালানোর সময় সাবধান! ফাইলটি আকারে বেশ বড় হতে পারে তাই প্রথমে এটি একটি বিকাশের উদাহরণে পরীক্ষা করে দেখুন। আপনি সর্বোচ্চ সেট করতে পারেন। ফাইলের আকার কিন্তু আমি এটি এখানে অন্তর্ভুক্ত করি নি। বর্ধিত ইভেন্টগুলির জন্য এখানে এমএসডিএন লিঙ্কটি রয়েছে: - https://msdn.microsoft.com/en-us/library/hh213147.aspx

এই অধিবেশনটিকে নিয়মিত পর্যবেক্ষণ করুন এবং আশা করা যায় এটি আপনার পিএলইতে আস্তরণের আস্তরণের যে কোনও প্রশ্ন আসবে।

আরও পড়া -

পিএলই তে এমএসডিএন ব্লগ - http://blogs.msdn.com/b/mcsukbi/archive/2013/04/12/sql-server-page-Live-expectancy.aspx

বর্ধিত ইভেন্টগুলি সেট আপ করার ভিডিও - https://dbafromthecold.wordpress.com/2014/12/05/video-phanfying-large-queries-used-extended-events/ (এটি আমার নিজের ব্লগ থেকে তাই নির্লজ্জ আত্ম প্রচারের জন্য দুঃখিত )

Answer 2

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

একটি সাধারণ পরিমাপ হিসাবে, এটি যত বেশি তত দ্রুত আপনার লোড প্যাটার্নটি প্রক্রিয়া করা হবে কারণ জিনিসগুলিকে স্মরণে রাখা হচ্ছে। যদি এটি খুব কম হয় তবে এটি মেমরি অনাহারজনিত কোনও পারফরম্যান্স সমস্যা নির্দেশ করতে পারে।

পড়া কম থাকায় সবসময় সমস্যা হওয়ার অর্থ এই নয় যে: উদাহরণস্বরূপ এটি প্রচুর পৃষ্ঠাগুলি ব্যবহার করার ফলে প্রচুর এক-অফ-ফাঁক প্রক্রিয়া করার পরে এটি কম হতে পারে যাতে সেগুলি এনেছে এবং সেগুলি আরও বেশি জায়গা তৈরিতে নামিয়ে দেয়। আপনার গ্রাফ যা প্রতিটি দিনের শেষে নেমে আসে বলে মনে হয় উদাহরণস্বরূপ, রাতের প্রশাসনিক কাজগুলি (ব্যাকআপ, ডেটা সংরক্ষণাগার, রাতারাতি অন্যান্য প্রক্রিয়াজাতকরণ) এর কারণ হতে পারে।