यूएटी और पीआरडी सर्वर पर निष्पादन योजनाओं में अंतर


39

मैं समझना चाहता हूं कि यूएटी (3 सेकंड में रन) बनाम पीआरडी (23 सेकंड में रन) पर एक ही क्वेरी के निष्पादन में इतना बड़ा अंतर क्यों होगा।

UAT और PROD दोनों बिल्कुल डेटा और इंडेक्स हैं।

: QUERY

set statistics io on;
set statistics time on;

SELECT CONF_NO,
       'DE',
       'Duplicate Email Address ''' + RTRIM(EMAIL_ADDRESS) + ''' in Maintenance',
       CONF_TARGET_NO
FROM   CONF_TARGET ct
WHERE  CONF_NO = 161
       AND LEFT(INTERNET_USER_ID, 6) != 'ICONF-'
       AND ( ( REGISTRATION_TYPE = 'I'
               AND (SELECT COUNT(1)
                    FROM   PORTFOLIO
                    WHERE  EMAIL_ADDRESS = ct.EMAIL_ADDRESS
                           AND DEACTIVATED_YN = 'N') > 1 )
              OR ( REGISTRATION_TYPE = 'K'
                   AND (SELECT COUNT(1)
                        FROM   CAPITAL_MARKET
                        WHERE  EMAIL_ADDRESS = ct.EMAIL_ADDRESS
                               AND DEACTIVATED_YN = 'N') > 1 ) ) 

UAT पर:

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
   CPU time = 11 ms, elapsed time = 11 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

(3 row(s) affected)
Table 'Worktable'. Scan count 256, logical reads 1304616, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'PORTFOLIO'. Scan count 1, logical reads 84761, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CAPITAL_MARKET'. Scan count 256, logical reads 9472, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CONF_TARGET'. Scan count 1, logical reads 100, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row(s) affected)

 SQL Server Execution Times:
   CPU time = 2418 ms,  elapsed time = 2442 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

यहाँ छवि विवरण दर्ज करें

PROD पर:

SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

(3 row(s) affected)
Table 'PORTFOLIO'. Scan count 256, logical reads 21698816, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CAPITAL_MARKET'. Scan count 256, logical reads 9472, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CONF_TARGET'. Scan count 1, logical reads 100, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row(s) affected)

 SQL Server Execution Times:
   CPU time = 23937 ms,  elapsed time = 23935 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 0 ms.

यहाँ छवि विवरण दर्ज करें

ध्यान दें कि PROD पर क्वेरी एक लापता इंडेक्स का सुझाव देती है और यह मेरे द्वारा परीक्षण किए गए अनुसार लाभदायक है, लेकिन यह चर्चा का विषय नहीं है।

मैं सिर्फ यह समझना चाहता हूं: ON UAT - sql सर्वर वर्कर टेबल क्यों बनाता है और PROD पर यह नहीं होता है? यह UAT पर एक टेबल स्पूल बनाता है न कि PROD पर। इसके अलावा, यूएटी बनाम पीआरडी पर निष्पादन समय इतना अलग क्यों है?

ध्यान दें :

मैं दोनों सर्वरों पर SQL सर्वर 2008 R2 RTM चला रहा हूं (बहुत जल्द नवीनतम SP के साथ पैच करने जा रहा हूं)।

UAT: अधिकतम मेमोरी 8GB। मैक्सडॉप, प्रोसेसर एफिनिटी और मैक्सिमम वर्कर थ्रेड्स 0 है।

Logical to Physical Processor Map:
*-------  Physical Processor 0
-*------  Physical Processor 1
--*-----  Physical Processor 2
---*----  Physical Processor 3
----*---  Physical Processor 4
-----*--  Physical Processor 5
------*-  Physical Processor 6
-------*  Physical Processor 7

Logical Processor to Socket Map:
****----  Socket 0
----****  Socket 1

Logical Processor to NUMA Node Map:
********  NUMA Node 0

PROD: अधिकतम मेमोरी 60GB। मैक्सडॉप, प्रोसेसर एफिनिटी और मैक्सिमम वर्कर थ्रेड्स 0 है।

Logical to Physical Processor Map:
**--------------  Physical Processor 0 (Hyperthreaded)
--**------------  Physical Processor 1 (Hyperthreaded)
----**----------  Physical Processor 2 (Hyperthreaded)
------**--------  Physical Processor 3 (Hyperthreaded)
--------**------  Physical Processor 4 (Hyperthreaded)
----------**----  Physical Processor 5 (Hyperthreaded)
------------**--  Physical Processor 6 (Hyperthreaded)
--------------**  Physical Processor 7 (Hyperthreaded)

Logical Processor to Socket Map:
********--------  Socket 0
--------********  Socket 1

Logical Processor to NUMA Node Map:
********--------  NUMA Node 0
--------********  NUMA Node 1

अद्यतन करें :

UAT निष्पादन योजना XML:

http://pastebin.com/z0PWvw8m

PROD निष्पादन योजना XML:

http://pastebin.com/GWTY16YY

यूएटी निष्पादन योजना एक्सएमएल - प्लान जनित फ्रॉड प्रॉड के साथ:

http://pastebin.com/74u3Ntr0

सर्वर कॉन्फ़िगरेशन:

PROD: पॉवरएडज R720xd - Intel (R) Xeon (R) CPU E5-2637 v2 @ 3.50GHz।

यूएटी: पावरएड 2950 - इंटेल (आर) एक्सॉन (आर) सीपीयू एक्स 5460 @ 3.16GHz

मैंने answer.sqlperformance.com पर पोस्ट किया है


अद्यतन करें :

सुझाव के लिए @swasheck का धन्यवाद

60GB से 7680 MB तक PROD पर अधिकतम मेमोरी को बदलते हुए, मैं PROD में एक ही योजना बनाने में सक्षम हूं। UAT के रूप में क्वेरी उसी समय पूरी होती है।

अब मुझे समझने की जरूरत है - क्यों? इसके अलावा, इसके द्वारा, मैं पुराने सर्वर को बदलने के लिए इस मॉन्स्टर सर्वर को सही ठहराने में सक्षम नहीं होऊंगा!

जवाबों:


43

बफर पूल का संभावित आकार कई तरीकों से क्वेरी ऑप्टिमाइज़र द्वारा योजना चयन को प्रभावित करता है। जहां तक ​​मुझे पता है, हाइपर-थ्रेडिंग प्लान की पसंद को प्रभावित नहीं करती है (हालांकि संभावित उपलब्ध शेड्यूलर्स की संख्या निश्चित रूप से कर सकती है)।

कार्यक्षेत्र मेमोरी

उन योजनाओं के लिए जिनमें मेमोरी-खपत पुनरावृत्तियाँ होती हैं जैसे सॉर्ट और हैश, बफर पूल का आकार (अन्य बातों के साथ) मेमोरी अनुदान की अधिकतम मात्रा निर्धारित करता है जो रनटाइम पर क्वेरी के लिए उपलब्ध हो सकती है।

SQL सर्वर 2012 (सभी संस्करण) में यह संख्या एक क्वेरी योजना के रूट नोड पर, Optimizer Hardware Dependenciesअनुभाग में, के रूप में दर्शाई गई है Estimated Available Memory Grant। 2012 से पहले के संस्करण शो प्लान में इस संख्या की रिपोर्ट नहीं करते हैं।

अनुमानित उपलब्ध स्मृति अनुदान क्वेरी ऑप्टिमाइज़र द्वारा उपयोग किए जाने वाले लागत मॉडल का एक इनपुट है। नतीजतन, एक योजना विकल्प जिसमें एक बड़े छंटाई या हैशिंग ऑपरेशन की आवश्यकता होती है, मशीन पर एक बड़े बफर पूल सेटिंग के साथ मशीन पर कम सेटिंग के साथ चुने जाने की अधिक संभावना है। बहुत बड़ी मात्रा में मेमोरी वाले इंस्टॉलेशन के लिए , लागत मॉडल इस प्रकार की सोच के साथ बहुत दूर तक जा सकता है - बहुत बड़े प्रकार या हैश के साथ योजनाएं चुनना जहां एक वैकल्पिक रणनीति बेहतर होगी ( KB2413549 - बड़ी मात्रा में मेमोरी का उपयोग करने से परिणाम हो सकता है SQL सर्वर में अक्षम योजना - TF2335 )।

कार्यक्षेत्र स्मृति अनुदान आपके मामले में एक कारक नहीं है, लेकिन इसके बारे में जानने लायक कुछ है।

डेटा प्राप्त करना

बफर पूल का संभावित आकार डेटा एक्सेस के लिए ऑप्टिमाइज़र की लागत मॉडल को भी प्रभावित करता है। मॉडल में बनाई गई मान्यताओं में से एक यह है कि प्रत्येक प्रश्न को ठंडे कैश के साथ शुरू होता है - इसलिए एक पृष्ठ की पहली पहुंच एक भौतिक I / O को मानने के लिए होती है। मॉडल उस मौके के लिए हिसाब लगाने का प्रयास करता है जो बार-बार पहुंच कैश से होगा, एक ऐसा कारक जो अन्य चीजों के बीच बफर पूल के संभावित आकार पर निर्भर करता है।

प्रश्न में दिखाए गए क्वेरी प्लान में क्लस्टर किए गए इंडेक्स स्कैन्स दोहराया पहुंच का एक उदाहरण हैं; स्कैन नेस्टेड लूप्स सेमी जॉइन्ट के प्रत्येक पुनरावृत्ति के लिए (कोररेटेड पैरामीटर के बदलाव के बिना, दोहराया गया है)। अर्ध जुड़ने के लिए बाहरी इनपुट 28.7874 पंक्तियों का अनुमान लगाते हैं, और इन स्कैन के लिए क्वेरी प्लान गुण अनुमानित रिवाइंड्स को 27.7874 पर परिणाम के रूप में दिखाता है।

फिर से, केवल SQL Server 2012 में, योजना का रूट पुनरावृत्ति अनुभाग Estimated Pages Cachedमें संख्या दिखाता है Optimizer Hardware Dependencies। यह संख्या कॉस्टिंग एल्गोरिथम में से एक इनपुट की रिपोर्ट करती है जो कैश से आने वाले पेज की पहुंच की संभावना के लिए खाता है।

इसका प्रभाव यह है कि उच्च कॉन्फ़िगर किए गए अधिकतम बफर पूल आकार के साथ एक इंस्टॉलेशन स्कैन की लागत को कम करेगा (या चाहता है) कि एक ही पृष्ठ को एक से अधिक बार पढ़ने से अधिक छोटे अधिकतम बफर पूल आकार के साथ कम हो।

सरल योजनाओं में, एक (estimated number of executions) * (estimated CPU + estimated I/O)अनुमानित स्कैन की लागत में कमी को अनुमानित ऑपरेटर लागत के साथ तुलना करके देखा जा सकता है , जो कम होगा। सेमी जॉइन और यूनियन के प्रभाव के कारण उदाहरण योजनाओं में गणना अधिक जटिल है।

फिर भी, प्रश्न में योजनाएं एक ऐसे मामले को दिखाती हैं जहां स्कैन को दोहराने और अस्थायी सूचकांक बनाने के बीच का विकल्प काफी बारीक संतुलित है। एक बड़े बफर पूल के साथ मशीन पर, स्कैन को दोहराने से इंडेक्स बनाने की तुलना में थोड़ा कम खर्च होता है। एक छोटे बफर पूल के साथ मशीन पर, स्कैन की लागत एक छोटी राशि से कम हो जाती है, जिसका अर्थ है कि इंडेक्स स्पूल प्लान ऑप्टिमाइज़र से थोड़ा सस्ता दिखता है।

योजना विकल्प

ऑप्टिमाइज़र की लागत मॉडल कई मान्यताओं को बनाता है, और इसमें बड़ी संख्या में विस्तृत गणनाएं होती हैं। यह हमेशा (या यहां तक ​​कि आमतौर पर) सभी विवरणों का पालन करना संभव नहीं है, क्योंकि सभी नंबरों की हमें ज़रूरत नहीं है, और एल्गोरिदम रिलीज के बीच बदल सकते हैं। विशेष रूप से, कैश्ड पृष्ठ के सामना करने के अवसर का ध्यान रखने के लिए लागू स्केलिंग फॉर्मूला अच्छी तरह से ज्ञात नहीं है।

इस विशेष मामले में बिंदु पर अधिक, ऑप्टिमाइज़र की योजना के विकल्प वैसे भी गलत संख्या पर आधारित हैं। क्लस्टर इंडेक्स सीक से पंक्तियों की अनुमानित संख्या 28.7874 है, जबकि 256 पंक्तियों को रनटाइम पर सामना किया जाता है - लगभग परिमाण का एक आदेश। हम उन सूचनाओं को प्रत्यक्ष रूप से नहीं देख सकते हैं, जो ऑप्टिमाइज़र के पास उन 28.7874 पंक्तियों के भीतर मूल्यों के अपेक्षित वितरण के बारे में है, लेकिन साथ ही साथ यह बहुत गलत होने की संभावना है।

जब अनुमान गलत होते हैं, तो योजना चयन और रनटाइम प्रदर्शन अनिवार्य रूप से संयोग से बेहतर नहीं होते हैं। सूचकांक स्पूल के साथ योजना स्कैन को दोहराने से बेहतर प्रदर्शन करने के लिए होती है, लेकिन यह सोचना काफी गलत है कि बफर पूल का आकार बढ़ना विसंगति का कारण था।

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

दोनों उदाहरणों ने अपने तरीके से एक लापता सूचकांक का सुझाव दिया। एक ने एक स्पष्ट लापता सूचकांक की सूचना दी, और दूसरे ने एक ही विशेषता के साथ एक सूचकांक स्पूल का उपयोग किया। यदि सूचकांक अच्छा प्रदर्शन और योजना स्थिरता प्रदान करता है, तो यह पर्याप्त हो सकता है। मेरा झुकाव क्वेरी को फिर से लिखना होगा, लेकिन यह शायद एक और कहानी है।


18

पॉल व्हाइट ने एक शानदार आकर्षक तरीके से इसके पीछे का कारण बताया है - अधिक मेमोरी वाले सर्वरों पर चलने पर एसक्यूएल सर्वर व्यवहार।

इसके अलावा, इस मुद्दे को पहली बार पेश करने के लिए @swasheck का बहुत बड़ा धन्यवाद ।

Microsoft के साथ एक मामला खोला और नीचे जो सुझाव दिया गया था।

स्टार्टअप पैरामीटर के रूप में ट्रेस ध्वज T2335 का उपयोग करके समस्या हल हो गई है।

KB2413549 - स्मृति की बड़ी मात्रा का उपयोग करते हुए एक अक्षम योजना में परिणाम कर सकते एसक्यूएल सर्वर में अधिक जानकारी के में यह वर्णन करता है।

यह ट्रेस फ़्लैग SQL सर्वर के कारण क्वेरी को निष्पादित करते समय मेमोरी खपत के संदर्भ में अधिक रूढ़िवादी है कि एक योजना उत्पन्न करेगा। यह सीमित नहीं करता है कि SQL सर्वर कितनी मेमोरी का उपयोग कर सकता है। SQL सर्वर के लिए कॉन्फ़िगर की गई मेमोरी अभी भी डेटा कैश, क्वेरी निष्पादन और अन्य उपभोक्ताओं द्वारा उपयोग की जाएगी। कृपया सुनिश्चित करें कि आप इस विकल्प का पूरी तरह से परीक्षण करते हैं, इसे उत्पादन परिवेश में रोल करने से पहले।


13

अधिकतम मेमोरी सेटिंग्स और हाइपरथ्रेडिंग दोनों ही योजना की पसंद को प्रभावित कर सकते हैं।

इसके अतिरिक्त, मुझे लगता है कि आपके "सेट" विकल्प प्रत्येक वातावरण में भिन्न हैं:

यूएटी पर कथन:

ANSI_NULLS="true" 
ANSI_PADDING="true" 
ANSI_WARNINGS="true" 
ARITHABORT="true" 
CONCAT_NULL_YIELDS_NULL="true" 
NUMERIC_ROUNDABORT="false" 
QUOTED_IDENTIFIER="true" 

उत्पादन पर कथन:

ANSI_NULLS="true" 
ANSI_PADDING="true" 
ANSI_WARNINGS="true" 
ARITHABORT="false" 
CONCAT_NULL_YIELDS_NULL="true"
NUMERIC_ROUNDABORT="false"
QUOTED_IDENTIFIER="true" 

एसईटी विकल्पों के आधार पर एसक्यूएल विभिन्न योजनाएं उत्पन्न कर सकता है। यह अक्सर तब होता है जब आप योजना को विभिन्न SSMS सत्रों से, या ऐप से अलग-अलग निष्पादन से कैप्चर कर रहे होते हैं।

सुनिश्चित करें कि डेवलपर्स लगातार कनेक्शन स्ट्रिंग्स का उपयोग कर रहे हैं।


2
आप यह बताते हुए सही हैं कि मैक्स मेमोरी और हाइपरथ्रेडिंग प्लान कैश को प्रभावित कर सकते हैं, लेकिन मैं विस्तार से जानना चाहता हूं कि यह क्या और क्यों हुआ। आपके उत्तर की सराहना करते हैं।
किन्न शाह

2
जैसा कि अमांडा ने कहा, यदि ARETABORT
ARA
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.