उदाहरण के बारे में पेज लाइफ एक्सपेक्टेंसी क्या कहती है?

Question

मैंने वातावरण में कुछ SQL सर्वर इंस्टेंस पर निगरानी सॉफ़्टवेयर स्थापित किया है। मैं बाधाओं को खोजने और कुछ प्रदर्शन मुद्दों को ठीक करने की कोशिश कर रहा हूं। मैं यह पता लगाना चाहता हूं कि क्या कुछ सर्वर को अधिक मेमोरी की आवश्यकता है।

मुझे एक काउंटर में रुचि है: पृष्ठ जीवन प्रत्याशा। यह हर मशीन पर अलग दिखता है। यह कुछ उदाहरणों पर अक्सर क्यों बदल जाता है और इसका क्या मतलब है?

कृपया कुछ अलग मशीनों पर एकत्रित पिछले सप्ताह के आंकड़ों पर एक नज़र डालें। आप प्रत्येक उदाहरण के बारे में क्या कह सकते हैं?

भारी इस्तेमाल किया उत्पादन उदाहरण (1):

मध्यम रूप से इस्तेमाल किया जाने वाला उत्पादन आइसटांस (2)

शायद ही कभी परीक्षण उदाहरण (3)

भारी इस्तेमाल किया उत्पादन उदाहरण (4)

सामान्य रूप से इस्तेमाल किया गया परीक्षण उदाहरण (5)

भारी इस्तेमाल किया डेटा गोदाम (6)

संपादित करें: Im इन सभी सर्वरों के लिए SELECT @@ संस्करण का आउटपुट जोड़ रहा है:

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

Instance 2 में SQL Server 2012 है और अन्य SQL Server 2008 R2

— BuahahaDD

रेखांकन का पैमाना वास्तव में मदद नहीं करता है। यह देखना अधिक दिलचस्प होगा कि व्यस्त सर्वर दिन के दौरान शून्य के कितने करीब पहुंचते हैं।

— जेम्स जेड

काश मैं और अधिक विस्तृत डेटा प्राप्त कर सकता। मैंने Solarwinds डेटाबेस प्रदर्शन मॉनिटर का उपयोग किया और फ़ाइल में डेटा निर्यात करने का कोई तरीका नहीं है। ऐसा करने का एकमात्र तरीका अपने डेटाबेस को क्वेरी करना है लेकिन संरचना न तो सामान्य है और न ही आसानी से समझ में आती है।

— BuahahaXD

अचानक आई बूंदों को समझने में आपकी मदद करने के लिए: जब अनकैप्ड डेटा का एक बड़ा स्कैन निष्पादित किया जाता है, तो नए पृष्ठों के लिए जगह बनाने के लिए बहुत सारे पृष्ठों को निकाला जाता है। यह एक संशोधित LRU एल्गोरिथ्म है। नए पन्ने पुराने को गिरा देते हैं।

— usr

उदाहरण 2 और 6 NUMA का उपयोग करते हैं, अन्य नहीं करते हैं।

— BuahahaXD

Answer 1

MSDN से लिया गया: - https://msdn.microsoft.com/en-us/library/ms189628.aspx

पृष्ठ जीवन प्रत्याशा - सेकंड्स की संख्या इंगित करता है कि एक पृष्ठ बिना संदर्भ के बफर पूल में रहेगा।

SQL हमेशा मेमोरी में डेटा पेजों की तलाश करता है। यदि डेटा पृष्ठ मेमोरी में नहीं है, तो SQL को डिस्क पर जाना होगा (एक भौतिक IO ऑपरेशन करना होगा) ताकि उस डेटा को पुनः प्राप्त किया जा सके जिसे उसे अनुरोध को पूरा करने की आवश्यकता है। यदि आपका PLE काउंटर कम है जो इंगित करता है कि मेमोरी में डेटा पृष्ठ नियमित रूप से भौतिक IO परिचालनों से आने वाले नए पृष्ठों से अधिलेखित हैं। भौतिक आईओ संचालन महंगे हैं, जिसका अर्थ है कि आपके SQL इंस्टेंस का प्रदर्शन प्रतिकूल रूप से प्रभावित होगा। इसलिए आप चाहते हैं कि आपका PLE काउंटर यथासंभव अधिक हो।

किसी भी सलाह को नजरअंदाज करें जो आप ऑनलाइन देखते हैं कि इस काउंटर के लिए एक अच्छी सीमा के रूप में 300 का उल्लेख है

यह सीमा उन दिनों से आती है जब मेमोरी सीमित थी (32-बिट सिस्टम लगता है)। अब हमारे पास 64-बिट सिस्टम हैं जिसमें टीबी की रैम हो सकती है इसलिए यह सलाह बहुत पुरानी है।

पहली बात, क्या आपने SQL की मेमोरी को सीमित कर दिया है? यदि हां, तो उपलब्ध स्मृति कितनी शेष है? क्या सीमा बढ़ाई जा सकती है?

दूसरी बात जो मैं आपके सर्वर पर देख रहा हूं, क्या कोई रखरखाव कार्य चल रहा है? इंडेक्स रियॉड्स, अपडेट स्टैटस या DBCC CHECKDB ऑपरेशंस पर काम करने वाले जॉब्स की जाँच करें। ये बड़ी मात्रा में रीड करते हैं और आपके PLE फ्लैट लाइनिंग का कारण हो सकते हैं,

अगला, जैसा कि आप SQL सर्वर 2008 + का उपयोग कर रहे हैं, आप इसमें आने वाले प्रश्नों को पकड़ने के लिए एक विस्तारित ईवेंट सत्र सेटअप कर सकते हैं जो बड़ी मात्रा में रीड्स का प्रदर्शन कर रहे हैं। यहाँ ऐसा करने के लिए कोड है: -

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

इसे चलाते समय सावधान रहें! फ़ाइल आकार में काफी बड़ी हो सकती है, इसलिए इसे पहले एक विकास उदाहरण पर परखें। आप अधिकतम सेट कर सकते हैं। फ़ाइल का आकार लेकिन मैंने इसमें शामिल नहीं किया है। विस्तारित घटनाओं के लिए यहाँ MSDN लिंक दिया गया है: - https://msdn.microsoft.com/en-us/library/hh213147.aspx

इस सत्र को नियमित रूप से मॉनिटर करें और उम्मीद है कि इसमें आने वाले किसी भी प्रश्न को उठाना चाहिए जो आपके PLE को फ्लैट कर रहे हैं।

आगे की पढाई -

PLE पर MSDN ब्लॉग - http://blogs.msdn.com/b/mcsukbi/archive/2013/04/12/sql-server-page-life-expectancy.aspx

विस्तारित घटनाओं की स्थापना पर वीडियो - https://dbafromthecold.wordpress.com/2014/12/05/video-identifying-large-queries-use-extended-events/ (यह मेरे अपने ब्लॉग से है तो बेशर्म प्रचार के बारे में खेद है )

Answer 2

पृष्ठ जीवन प्रत्याशा एक माप है कि आप कितने समय तक एक ऐसे पृष्ठ की अपेक्षा कर सकते हैं जिसे स्मृति से लटकने के लिए डिस्क से केवल पढ़ने के लिए पढ़ा जाता है, इससे पहले कि इसे किसी और चीज़ से बाहर धकेल दिया जाए या नष्ट कर दिया जाए (अर्थात उस पृष्ठ को डिस्क पर हटा दिया जाए, इसकी कोई आवश्यकता नहीं है रैम में कैश्ड कॉपी रखने के लिए)।

एक सामान्य उपाय के रूप में, यह जितना अधिक तेज़ होगा आपके लोड पैटर्न को संसाधित किया जाएगा, क्योंकि चीजों को स्मृति में रखा जा रहा है। यदि यह बहुत कम है तो यह मेमोरी भुखमरी के कारण एक प्रदर्शन समस्या का संकेत दे सकता है।

कम होने का मतलब हमेशा पढ़ना नहीं होता है, हालांकि एक समस्या होती है: उदाहरण के लिए, यह प्रक्रियाओं के एक बड़े पैमाने पर एक बार बंद होने के बाद कम हो सकता है जो बहुत सारे पृष्ठों का उपयोग करते थे इसलिए उन्हें अंदर लाया गया और वे अधिक के लिए जगह बनाने के लिए गिरा दिए गए। आपका ग्राफ जो उदाहरण के लिए प्रत्येक दिन के अंत में गिरता है, रात की प्रशासनिक नौकरियों (बैकअप, डेटा संग्रह, अन्य रातोंरात प्रसंस्करण) के कारण हो सकता है।