sự khác biệt trong kế hoạch thực hiện trên máy chủ UAT và PROD


39

Tôi muốn hiểu tại sao sẽ có sự khác biệt lớn như vậy khi thực hiện cùng một truy vấn trên UAT (chạy trong 3 giây) so với PROD (chạy trong 23 giây).

Cả UAT và PROD đều có dữ liệu và chỉ mục chính xác.

TRUY VẤN:

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 ) ) 

TRÊN 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.

nhập mô tả hình ảnh ở đây

Về sản xuất:

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.

nhập mô tả hình ảnh ở đây

Lưu ý rằng trên SẢN PHẨM truy vấn cho thấy một chỉ mục bị thiếu và điều đó có lợi như tôi đã kiểm tra, nhưng đó không phải là điểm thảo luận.

Tôi chỉ muốn hiểu rằng: TRÊN UAT - tại sao máy chủ sql tạo bảng worker và trên SẢN PHẨM thì không? Nó tạo ra một bộ đệm bảng trên UAT chứ không phải trên SẢN PHẨM. Ngoài ra, tại sao thời gian thực hiện lại khác nhau trên UAT so với SẢN PHẨM?

Chú thích :

Tôi đang chạy máy chủ sql 2008 R2 RTM trên cả hai máy chủ (sắp có bản vá với SP mới nhất).

UAT: Bộ nhớ tối đa 8GB. MaxDop, ái lực của bộ xử lý và các luồng công nhân tối đa là 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

SẢN XUẤT: bộ nhớ tối đa 60GB. MaxDop, ái lực của bộ xử lý và các luồng công nhân tối đa là 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

CẬP NHẬT:

Kế hoạch thực hiện UAT XML:

http://pastebin.com/z0PWvw8m

Kế hoạch thực hiện sản xuất XML:

http://pastebin.com/GWTY16YY

XML Kế hoạch thực hiện UAT - với Kế hoạch được tạo ra fro SẢN PHẨM:

http://pastebin.com/74u3Ntr0

Cấu hình máy chủ:

SẢN XUẤT: PowerEdge R720xd - CPU Intel (R) Xeon (R) E5-2637 v2 @ 3.50GHz.

UAT: PowerEdge 2950 - CPU Xeon (R) Intel X5460 @ 3.16GHz

Tôi đã đăng tại answer.sqlperformance.com


CẬP NHẬT:

Cảm ơn @swasheck đã gợi ý

Thay đổi bộ nhớ tối đa trên SẢN PHẨM từ 60 GB thành 7680 MB, tôi có thể tạo cùng một gói trong SẢN PHẨM. Truy vấn hoàn thành cùng lúc với UAT.

Bây giờ tôi cần hiểu - TẠI SAO? Ngoài ra, bằng cách này, tôi sẽ không thể biện minh cho máy chủ quái vật này để thay thế máy chủ cũ!

Câu trả lời:


43

Kích thước tiềm năng của nhóm bộ đệm ảnh hưởng đến việc lựa chọn gói bởi trình tối ưu hóa truy vấn theo một số cách. Theo như tôi biết, siêu phân luồng không ảnh hưởng đến sự lựa chọn kế hoạch (mặc dù số lượng người lập lịch có khả năng chắc chắn có thể).

Bộ nhớ không gian làm việc

Đối với các gói chứa bộ lặp tiêu thụ bộ nhớ như sắp xếp và băm, kích thước của vùng đệm (trong số các thứ khác) xác định mức cấp bộ nhớ tối đa có thể có sẵn cho truy vấn khi chạy.

Trong SQL Server 2012 (tất cả các phiên bản) con số này được báo cáo trên nút gốc của một kế hoạch truy vấn, trong Optimizer Hardware Dependenciesphần, hiển thị như Estimated Available Memory Grant. Các phiên bản trước năm 2012 không báo cáo con số này trong kế hoạch hiển thị.

Cấp bộ nhớ khả dụng ước tính là một đầu vào cho mô hình chi phí được sử dụng bởi trình tối ưu hóa truy vấn. Do đó, phương án thay thế kế hoạch yêu cầu thao tác sắp xếp hoặc băm lớn có nhiều khả năng được chọn trên máy có cài đặt vùng đệm lớn hơn so với trên máy có cài đặt thấp hơn. Đối với các cài đặt có số lượng bộ nhớ rất lớn, mô hình chi phí có thể đi quá xa với kiểu suy nghĩ này - chọn các kế hoạch với các loại hoặc băm rất lớn trong đó chiến lược thay thế sẽ được ưu tiên hơn ( KB2413549 - Sử dụng số lượng lớn bộ nhớ có thể dẫn đến kế hoạch không hiệu quả trong SQL Server - TF2335 ).

Cấp bộ nhớ không gian làm việc không phải là một yếu tố trong trường hợp của bạn, nhưng nó là điều đáng để biết.

Truy cập dữ liệu

Kích thước tiềm năng của nhóm bộ đệm cũng ảnh hưởng đến mô hình chi phí của trình tối ưu hóa để truy cập dữ liệu. Một trong những giả định được đưa ra trong mô hình là mọi truy vấn đều bắt đầu bằng bộ đệm lạnh - vì vậy lần truy cập đầu tiên vào một trang được giả sử là phải chịu I / O vật lý. Mô hình không cố gắng tính đến khả năng truy cập lặp lại sẽ đến từ bộ đệm, một yếu tố phụ thuộc vào kích thước tiềm năng của vùng đệm trong số những thứ khác.

Quét chỉ mục cụm trong các kế hoạch truy vấn được hiển thị trong câu hỏi là một ví dụ về truy cập lặp lại; các lần quét được lặp lại (lặp đi lặp lại, không thay đổi tham số tương quan) cho mỗi lần lặp của các vòng lặp lồng nhau bán tham gia. Đầu vào bên ngoài cho ước tính bán tham gia 28.7874 hàng và kết quả là các thuộc tính kế hoạch truy vấn cho các lần quét này cho thấy tua lại ước tính ở 27.7874.

Một lần nữa, chỉ trong SQL Server 2012, trình lặp gốc của kế hoạch hiển thị số lượng Estimated Pages Cachedtrong Optimizer Hardware Dependenciesphần. Con số này báo cáo một trong những yếu tố đầu vào cho thuật toán chi phí có vẻ như sẽ giải thích cho cơ hội truy cập trang lặp lại đến từ bộ đệm.

Hiệu quả là việc cài đặt với kích thước nhóm bộ đệm tối đa được cấu hình cao hơn sẽ có xu hướng giảm chi phí quét (hoặc tìm kiếm) đọc cùng một trang nhiều hơn một lần so với cài đặt có kích thước nhóm bộ đệm tối đa nhỏ hơn.

Trong các kế hoạch đơn giản, có thể thấy giảm chi phí khi quét lại bằng cách so sánh (estimated number of executions) * (estimated CPU + estimated I/O)với chi phí vận hành ước tính, sẽ thấp hơn. Việc tính toán phức tạp hơn trong các kế hoạch ví dụ do ảnh hưởng của liên kết và liên kết.

Tuy nhiên, các kế hoạch trong câu hỏi dường như cho thấy một trường hợp trong đó sự lựa chọn giữa việc lặp lại các lần quét và tạo một chỉ mục tạm thời khá cân bằng. Trên máy có nhóm bộ đệm lớn hơn, việc lặp lại các lần quét được chi phí thấp hơn một chút so với việc tạo chỉ mục. Trên máy có nhóm bộ đệm nhỏ hơn, chi phí quét giảm đi một lượng nhỏ hơn, có nghĩa là gói bộ đệm chỉ mục trông rẻ hơn một chút so với trình tối ưu hóa.

Lựa chọn kế hoạch

Mô hình chi phí của trình tối ưu hóa đưa ra một số giả định và chứa một số lượng lớn các tính toán chi tiết. Không phải lúc nào cũng có thể (hoặc thậm chí thường là) có thể theo dõi tất cả các chi tiết vì không phải tất cả các số chúng tôi cần đều được đưa ra và các thuật toán có thể thay đổi giữa các bản phát hành. Cụ thể, công thức chia tỷ lệ được áp dụng để tính đến cơ hội gặp phải một trang được lưu trong bộ nhớ cache không được biết rõ.

Hơn nữa, trong trường hợp cụ thể này, các lựa chọn kế hoạch của trình tối ưu hóa vẫn dựa trên các số không chính xác. Số lượng hàng ước tính từ Tìm kiếm chỉ mục cụm là 28.7874, trong khi 256 hàng gặp phải trong thời gian chạy - gần như là một thứ tự cường độ. Chúng ta không thể trực tiếp nhìn thấy thông tin mà trình tối ưu hóa có về phân phối giá trị dự kiến ​​trong 28.7874 hàng đó, nhưng nó cũng rất có thể bị sai một cách khủng khiếp.

Khi ước tính sai, lựa chọn kế hoạch và hiệu suất thời gian chạy về cơ bản không tốt hơn cơ hội. Kế hoạch với bộ đệm chỉ mục xảy ra để thực hiện tốt hơn so với việc lặp lại quá trình quét, nhưng thật sai lầm khi nghĩ rằng việc tăng kích thước của vùng đệm là nguyên nhân của sự bất thường.

Trường hợp trình tối ưu hóa có thông tin chính xác, cơ hội tốt hơn sẽ tạo ra một kế hoạch thực hiện tốt. Một cá thể có nhiều bộ nhớ thường sẽ hoạt động tốt hơn trên một khối lượng công việc so với một cá thể khác có ít bộ nhớ hơn, nhưng không có gì đảm bảo, đặc biệt là khi lựa chọn gói dựa trên dữ liệu không chính xác.

Cả hai trường hợp đề xuất một chỉ mục bị thiếu theo cách riêng của họ. Một báo cáo một chỉ mục bị thiếu rõ ràng và cái còn lại sử dụng một bộ đệm chỉ mục có cùng đặc điểm. Nếu chỉ số cung cấp hiệu suất tốt và ổn định kế hoạch, điều đó có thể là đủ. Xu hướng của tôi sẽ là viết lại truy vấn, nhưng đó có lẽ là một câu chuyện khác.


18

Paul White đã giải thích một cách sáng suốt tuyệt vời lý do đằng sau - hành vi máy chủ sql khi chạy trên các máy chủ có nhiều bộ nhớ hơn.

Ngoài ra, rất cảm ơn @swasheck vì đã phát hiện ra vấn đề này.

Đã mở một trường hợp với microsoft và dưới đây là những gì đã được đề xuất.

Vấn đề được giải quyết bằng cách sử dụng cờ theo dõi T2335 làm tham số khởi động.

Các KB2413549 - Sử dụng một lượng lớn bộ nhớ có thể dẫn đến một kế hoạch không hiệu quả trong SQL Server mô tả nó trong biết thêm chi tiết.

Cờ theo dõi này sẽ khiến SQL Server tạo ra một kế hoạch bảo thủ hơn về mặt tiêu thụ bộ nhớ khi thực hiện truy vấn. Nó không giới hạn số lượng bộ nhớ SQL Server có thể sử dụng. Bộ nhớ được cấu hình cho SQL Server vẫn sẽ được sử dụng bởi bộ đệm dữ liệu, thực thi truy vấn và người tiêu dùng khác. Hãy đảm bảo rằng bạn kiểm tra kỹ lưỡng tùy chọn này, trước khi đưa nó vào môi trường sản xuất.


13

Cài đặt bộ nhớ tối đa và siêu phân luồng đều có thể ảnh hưởng đến lựa chọn gói.

Ngoài ra, tôi nhận thấy các tùy chọn "thiết lập" của bạn khác nhau ở mỗi môi trường:

StatementSetOptions trên UAT:

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

StatementSetOptions trên Prod:

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

SQL có thể tạo các gói khác nhau dựa trên các tùy chọn SET. Điều này thường xảy ra nếu bạn đang nắm bắt kế hoạch từ các phiên SSMS khác nhau hoặc từ các lần thực hiện khác nhau từ ứng dụng.

Hãy chắc chắn rằng các nhà phát triển đang sử dụng các chuỗi kết nối nhất quán.


2
Bạn đã đúng khi tuyên bố rằng Max Memory và Hyperthreading có thể ảnh hưởng đến bộ nhớ cache của gói, nhưng tôi muốn biết chi tiết về điều gì và tại sao điều này xảy ra. Đánh giá cao câu trả lời của bạn.
Kin Shah

2
Như Amanda đã nói, nếu các tùy chọn SET khác nhau trong ARITHABORT, có thể bạn nên xem dba.stackexchange.com/questions/9840/ trên
ARA
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.