ความแตกต่างในแผนการดำเนินการบนเซิร์ฟเวอร์ UAT และ PROD


39

ฉันต้องการที่จะเข้าใจว่าทำไมมันถึงมีความแตกต่างอย่างมากในการดำเนินการกับเคียวรีเดียวกันบน UAT (ทำงานใน 3 วินาที) เทียบกับ PROD (ทำงานใน 23 วินาที)

ทั้ง UAT และ PROD มีข้อมูลและดัชนีอย่างแน่นอน

ค้นหา:

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.

ป้อนคำอธิบายรูปภาพที่นี่

บนแยง:

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 นอกจากนี้ทำไมเวลาการดำเนินการจึงแตกต่างกันสำหรับ UAT และ PROD

บันทึก :

ฉันกำลังเรียกใช้ sql server 2008 R2 RTM บนเซิร์ฟเวอร์ทั้งสอง (ค่อนข้างเร็วจะไปแก้ไขด้วย SP ล่าสุด)

เอือด: หน่วยความจำสูงสุด 8GB MaxDop ความเกี่ยวข้องของตัวประมวลผลและเธรดตัวทำงานสูงสุดคือ 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

แยง: หน่วยความจำสูงสุด 60GB MaxDop ความเกี่ยวข้องของตัวประมวลผลและเธรดตัวทำงานสูงสุดคือ 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 Execution Plan XML:

http://pastebin.com/z0PWvw8m

PROD Execution Plan XML:

http://pastebin.com/GWTY16YY

UAT Execution Plan XML - ด้วยการสร้างแผนจาก PROD:

http://pastebin.com/74u3Ntr0

การกำหนดค่าเซิร์ฟเวอร์:

แยง: PowerEdge R720xd - ซีพียู Intel (R) Xeon (R) E5-2637 v2 @ 3.50GHz

เอือด: PowerEdge 2950 - Intel (R) Xeon (R) CPU X5460 @ 3.16GHz

ฉันโพสต์แล้วที่answers.sqlperformance.com


อัปเดต:

ขอบคุณ @swasheck สำหรับคำแนะนำ

การเปลี่ยนหน่วยความจำสูงสุดใน PROD จาก 60GB เป็น 7680 MB ฉันสามารถสร้างแผนเดียวกันใน PROD ได้ แบบสอบถามเสร็จสมบูรณ์ในเวลาเดียวกับ UAT

ตอนนี้ฉันต้องเข้าใจ - ทำไมล่ะ ยิ่งไปกว่านั้นฉันจะไม่สามารถพิสูจน์เซิร์ฟเวอร์มอนสเตอร์นี้ให้เปลี่ยนเซิร์ฟเวอร์เก่าได้!

คำตอบ:


43

ขนาดที่เป็นไปได้ของบัฟเฟอร์พูลส่งผลกระทบต่อการเลือกแผนโดยเครื่องมือเพิ่มประสิทธิภาพคิวรีในหลายวิธี เท่าที่ฉันทราบแล้วการทำไฮเปอร์เธรดไม่ได้ส่งผลกระทบต่อตัวเลือกแผน

หน่วยความจำพื้นที่ทำงาน

สำหรับแผนที่มีตัววนซ้ำที่ใช้หน่วยความจำเช่นการเรียงลำดับและแฮชขนาดของบัฟเฟอร์พูล (จากสิ่งอื่น ๆ ) กำหนดจำนวนหน่วยความจำสูงสุดที่หน่วยความจำอนุญาตที่อาจพร้อมใช้งานสำหรับแบบสอบถามในขณะใช้งานจริง

ใน SQL Server 2012 (ทุกรุ่น) ตัวเลขนี้มีรายงานบนโหนดรากของแผนการสอบถามในส่วนแสดงให้เห็นว่าOptimizer Hardware Dependencies Estimated Available Memory Grantรุ่นก่อนปี 2012 จะไม่รายงานหมายเลขนี้ในแผนการแสดง

การให้สิทธิ์หน่วยความจำที่มีอยู่โดยประมาณคืออินพุตสำหรับโมเดลต้นทุนที่ใช้โดยเครื่องมือเพิ่มประสิทธิภาพคิวรี ดังนั้นทางเลือกแผนที่ต้องใช้การเรียงลำดับขนาดใหญ่หรือการดำเนินการแปลงข้อมูลมีแนวโน้มที่จะถูกเลือกบนเครื่องที่มีการตั้งค่าบัฟเฟอร์พูลขนาดใหญ่กว่าบนเครื่องที่มีการตั้งค่าที่ต่ำกว่า สำหรับการติดตั้งที่มีมากจำนวนมากของหน่วยความจำรุ่นค่าใช้จ่ายสามารถไปไกลเกินไปกับการเรียงลำดับของความคิดนี้ - เลือกแผนกับทุกประเภทมีขนาดใหญ่มากหรือแฮชที่กลยุทธ์ทางเลือกจะดีกว่า ( KB2413549 - การใช้จำนวนมากของหน่วยความจำที่สามารถส่งผลในการ แผนไม่มีประสิทธิภาพใน SQL Server - 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

Paul Whiteได้อธิบายอย่างชัดเจนถึงเหตุผลเบื้องหลังพฤติกรรมเซิร์ฟเวอร์ sql เมื่อทำงานบนเซิร์ฟเวอร์ที่มีหน่วยความจำมากขึ้น

นอกจากนี้ขอขอบคุณ@swasheckอย่างมากสำหรับการพบปัญหาครั้งแรก

เปิดเคสด้วย microsoft และด้านล่างเป็นสิ่งที่แนะนำ

ปัญหาได้รับการแก้ไขโดยใช้การตั้งค่าสถานะการสืบค้นกลับ T2335 เป็นพารามิเตอร์เริ่มต้น

KB2413549 - การใช้จำนวนมากของหน่วยความจำที่สามารถส่งผลในแผนไม่มีประสิทธิภาพใน SQL Serverอธิบายในรายละเอียดเพิ่มเติม

การตั้งค่าสถานะการสืบค้นกลับนี้จะทำให้ SQL Server เพื่อสร้างแผนการที่อนุรักษ์มากขึ้นในแง่ของปริมาณการใช้หน่วยความจำเมื่อดำเนินการแบบสอบถาม ไม่ จำกัด จำนวนหน่วยความจำที่ SQL Server สามารถใช้ได้ หน่วยความจำที่กำหนดค่าสำหรับ SQL Server จะยังคงถูกใช้งานอยู่โดยแคชข้อมูลการดำเนินการแบบสอบถามและผู้บริโภครายอื่น โปรดตรวจสอบให้แน่ใจว่าคุณได้ทดสอบตัวเลือกนี้อย่างละเอียดก่อนนำไปใช้ในสภาพแวดล้อมการผลิต


13

การตั้งค่าหน่วยความจำสูงสุดและการไฮเปอร์เธรดอาจส่งผลต่อตัวเลือกแผน

นอกจากนี้ฉันสังเกตเห็นตัวเลือก "ชุด" ของคุณแตกต่างกันในแต่ละสภาพแวดล้อม:

StatementSetOptions บน UAT:

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

StatementSetOptions บน Prod:

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

SQL สามารถสร้างแผนต่าง ๆ ตามตัวเลือกชุด สิ่งนี้มักจะเกิดขึ้นหากคุณจับภาพแผนจากเซสชัน SSMS ที่แตกต่างกันหรือจากการประมวลผลที่แตกต่างจากแอป

ตรวจสอบให้แน่ใจว่าผู้พัฒนาใช้สายเชื่อมต่อที่สอดคล้องกัน


2
คุณถูกต้องในการระบุว่า Max Memory และ Hyperthreading สามารถส่งผลกระทบต่อแผนแคช แต่ฉันต้องการทราบรายละเอียดเกี่ยวกับสิ่งที่และสาเหตุที่เกิดขึ้น ขอบคุณคำตอบของคุณ
Kin Shah

2
ดังที่อแมนดากล่าวว่าหากตัวเลือกของตลาดหลักทรัพย์แตกต่างกันใน ARITHABORT คุณอาจดูdba.stackexchange.com/questions/9840/…
ARA
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.