SQL Server 2012 chậm hơn 2008


15

Tôi đã di chuyển một trang web và cơ sở dữ liệu lớn từ một máy chủ cũ hơn (Windows 2008 / SQL Server 2008/16 GB RAM / 2 x 2,5 GHz Quad Core / SAS) sang một máy chủ mới hơn, tốt hơn nhiều (Windows 2008 R2 / SQL Server 2012 SP1 / RAM 64 GB / 2 x 2.1 GHz Bộ xử lý 16 nhân / ổ SSD).

Tôi tách các tệp cơ sở dữ liệu trên máy chủ cũ, sao chép và đính kèm chúng trên máy chủ mới. Mọi thứ diễn ra rất tốt.

Sau đó, tôi đổi sang cấp độ tương thích thành 110, thống kê cập nhật, xây dựng lại các chỉ mục.

Với sự thất vọng to lớn của tôi, tôi nhận thấy rằng hầu hết các truy vấn sql chậm hơn nhiều (chậm hơn 2-3 lần) trên máy chủ SQL 2012 mới so với máy chủ SQL 2008 cũ.

Ví dụ: trên một bảng có khoảng 700k bản ghi, trên máy chủ cũ, một truy vấn về chỉ mục mất khoảng 100ms. Trên máy chủ mới, cùng một truy vấn mất khoảng 350 ms.

Điều tương tự xảy ra cho tất cả các truy vấn.

Tôi sẽ đánh giá cao một số trợ giúp ở đây. Hãy cho tôi biết những gì để kiểm tra / xác minh. Bởi vì tôi thấy rất khó tin rằng trên một máy chủ tốt hơn với SQL Server mới hơn, hiệu suất sẽ kém hơn.

Thêm chi tiết:

Bộ nhớ được đặt thành tối đa.

Tôi có bảng và chỉ mục này:

CREATE TABLE [dbo].[Answer_Details_23](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [UserID] [int] NOT NULL,
    [SurveyID] [int] NOT NULL,
    [CustomerID] [int] NOT NULL default 0,
    [SummaryID] [int] NOT NULL,
    [QuestionID] [int] NOT NULL,
    [RowID] [int] NOT NULL default 0,
    [OptionID] [int] NOT NULL default 0,
    [EnteredText] [ntext] NULL,
 CONSTRAINT [Answer_Details_23_PK] PRIMARY KEY NONCLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

CREATE NONCLUSTERED INDEX [IDX_Answer_Details_23_SummaryID_QuestionID] ON [dbo].[Answer_Details_23]
(
    [SummaryID] ASC,
    [QuestionID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

Tôi đã thực hiện truy vấn này:

set statistics time on;
select summaryid, count(summaryid) from Answer_Details_23 group by summaryid order by count(summaryid) desc;
set statistics time off;

OLD SERVER - Thời gian thực thi máy chủ SQL: Thời gian CPU = 419 ms, thời gian trôi qua = 695 ms.

MÁY CHỦ MỚI - Thời gian thực thi máy chủ SQL: Thời gian CPU = 1340 ms, thời gian trôi qua = 1636 ms.

KẾ HOẠCH THỰC HIỆN được tải lên tại đây: http://we.tl/ARbPuvf9t8

Cập nhật sau:

  • Bộ xử lý Opteron 16 nhân AMD 2.1GHz trông tệ hơn nhiều so với bộ xử lý lõi tứ Intel 2.5GHz
  • Cải thiện tuyệt vời thay đổi tùy chọn sức mạnh cửa sổ từ bóng sang công suất cao
  • Cải thiện hơn nữa thay đổi mức độ song song tối đa thành 8 và ngưỡng chi phí thành 4

Bây giờ, Thời gian thực thi của SQL Server: Thời gian CPU = 550 ms, thời gian đã trôi qua = 828 ms.

Nó vẫn tệ hơn máy chủ cũ, nhưng không tệ lắm. Nếu bạn có bất kỳ đề xuất nào khác (ngoài tối ưu hóa truy vấn cục bộ), vui lòng bình luận.


Bình luận không dành cho thảo luận mở rộng; cuộc trò chuyện này đã được chuyển sang trò chuyện .
Paul White phục hồi Monica

Câu trả lời:


8

Tôi đã gặp vấn đề tương tự với SQL Server, có thể máy chủ của bạn không được cấu hình tối ưu. Xeons mới hơn đi kèm với TurboBoost, HT, vv có thể ảnh hưởng đáng kể đến hiệu suất máy chủ.

Ví dụ, chúng tôi đã có thành công với; Cấu hình độ trễ thấp cho máy chủ Dell

Các cài đặt sẽ được áp dụng cho các máy chủ không phải của Dell, chúng chỉ có thể có các tên khác nhau.

Chúng tôi cũng cải thiện hiệu suất bằng cách đặt cấu hình quản lý nguồn của windows thành hiệu suất cao, từ Cân bằng. Một điều cuối cùng là khuyến nghị nên dự trữ tối đa 8GB bộ nhớ cho HĐH trên các máy chủ x64, cài đặt SQL mặc định sẽ chiếm toàn bộ bộ nhớ. Bạn có thể muốn thử đặt trước 4 / 8GB bằng cách đặt cấu hình bộ nhớ Máy chủ SQL tối đa của bạn thành 4 / 8GB so với tổng bộ nhớ.

Đề nghị của tôi sẽ trở lại máy chủ cũ nếu có thể. Nếu bạn không có sẵn các kịch bản hồi quy / tự động hóa / tải, thì cách tốt nhất bạn có thể làm là ghi lại hoạt động hệ thống của mình trong 1-4 giờ trong thời gian hoạt động cao. Sau đó thiết lập một máy chủ web giống như sản xuất và máy khách để chạy tập lệnh. Chạy cùng một hoạt động với máy chủ mới, làm cho cấu hình thay đổi và chạy lại hoạt động tương tự. Thực sự bạn sẽ muốn làm nhiều hơn nữa, nhưng có vẻ như nó sẽ không khả thi và nằm ngoài phạm vi của câu hỏi này.


Tải không cao trên máy chủ. SQL Server thường nằm trong bộ nhớ 20-35 GB. Bất cứ lúc nào chúng tôi cũng có hơn 16 GB bộ nhớ miễn phí. Ngoài ra, bộ xử lý không vượt quá mức sử dụng 10-15%.
prog_sr08

2
Cải tiến lớn nhất cho đến nay đạt được bằng cách thiết lập quản lý năng lượng cửa sổ từ cân bằng đến công suất cao. Vì vậy, nó thực sự trông giống như một vấn đề bộ xử lý. Thời gian thực thi máy chủ SQL: Thời gian CPU = 892 ms, thời gian trôi qua = 874 ms.
prog_sr08

8

Hãy cho tôi biết những gì cần kiểm tra / xác minh

Bạn có một vấn đề hiệu suất. Thực hiện theo một phương pháp khắc phục sự cố hiệu suất như Chờ đợi và Hàng đợi để xác định nút cổ chai. Phương pháp liên kết cho bạn thấy những gì cần đo và làm thế nào. Đăng ở đây những phát hiện và chúng tôi có thể giúp với lời khuyên cụ thể dựa trên số đo thực tế của bạn. Vì nó quá mở và là dự đoán của bất kỳ ai. Thu hẹp nó xuống một vấn đề cụ thể sẽ loại bỏ phỏng đoán.

Sau khi cập nhật

Các kế hoạch khá khác nhau. Kế hoạch cũ có tổng số luồng thấp trên ngăn xếp thực sự có ước tính số lượng thẻ kém (141k so với 108k) và toán học băm tiếp tục đánh giá sai, theo cách khác (35k so với 108k). Kế hoạch mới không có tổng hợp luồng và có ước tính chính xác cho đến đỉnh. Tất nhiên, điều này không giải thích tại sao kế hoạch cũ được thực hiện nhanh hơn .

Các bản quét dưới cùng có số hàng hơi khác nhau (không đáng kể) nhưng chi phí khá khác nhau: cũ là 2.49884 (IO 2.28979 CPU 0.20905) so với 1.59109 mới (CPU IO 1.53868 0.0524084). Một lần nữa sẽ hướng đến một thực thi năm 2012 tốt hơn (việc xây dựng lại chỉ mục có lẽ đã làm giảm sự phân mảnh?).

Điều rất khác nhau là số lượng chủ đề: 32 trong hàng mới (mỗi hàng nhận ~ 23k) so với 8 trong số cũ (mỗi hàng nhận ~ 95k hàng). Cái bàn khá hẹp. Có thể là số lượng lớn các luồng thực sự gây tổn hại đến hiệu năng do mất hiệu lực bộ đệm thường xuyên hơn nhiều . Tôi sẽ thử:

  1. loại bỏ HyperThreading trong cấu hình máy chủ mới (nếu có) và / hoặc
  2. thử truy vấn với DOP 8.

Nhận thấy bình luận của bạn:

Đã thêm kế hoạch thực hiện với maxdop 8 Truy vấn thực sự nhanh hơn theo cách này

Có lẽ nó chỉ là CPU dẫm lên nhau. Với ổ SSD sẵn có, IO có lẽ không có gì khác và bảng này quá nhỏ để đảm bảo 32 máy quét. Trao đổi trao đổi đó có thể làm mất hiệu lực L1 / L2 liên tục.


1
Mọi thứ chậm hơn nhiều vào năm 2012 so với năm 2008. Tôi không cố gắng tối ưu hóa các truy vấn ở đây. Tôi sẽ rất vui khi có ít nhất hiệu suất tương tự với cùng một cơ sở dữ liệu trên máy chủ mới này.
prog_sr08

1
Chờ đợi và xếp hàng không phải là về tối ưu hóa các truy vấn. Là về việc xác định tắc nghẽn.
Remus Rusanu

Tôi đã tải tài liệu. Trông rất thú vị. Tôi đang ở trên đó ngay bây giờ, nhưng có vẻ như nó sẽ khiến tôi mất một lúc. Bạn có thể đề nghị nơi để tìm đầu tiên?
prog_sr08

1
thống kê chờ . đặt lại chúng trên cả hai năm 2008 và 2012, chạy tải trong 5-10 phút cho cả hai, sau đó so sánh sự khác biệt giữa năm 2008 và 2012.
Remus Rusanu

Tôi e rằng tôi không thể so sánh số liệu thống kê giữa 2 máy chủ bây giờ, vì máy chủ mới lưu trữ một trang web / cơ sở dữ liệu trực tiếp. Trên máy chủ cũ vẫn là cơ sở dữ liệu không tải nữa.
prog_sr08

3

Đối với hầu hết các hệ thống đa lõi hiện đại và đặc biệt là các hệ thống đa lõi, kiến ​​trúc phần cứng sao cho một số phần bộ nhớ nhất định nằm cách xa các lõi / bộ xử lý nhất định và một số bộ nhớ nhất định gần với một số bộ xử lý / bộ xử lý nhất định. Điều này được gọi là Kiến trúc bộ nhớ không đồng nhất hoặc viết tắt là NUMA. Bạn muốn cài đặt MAXDOP của mình khớp với số lõi trên mỗi nút NUMA để giảm thiểu số lần một nút số đã cho cần đi ra ngoài bộ nhớ của chính nó để lấy dữ liệu.

Bạn có thể sử dụng cách sau để kiểm tra cấu hình của máy mới và đảm bảo MAXDOP được đặt ở cài đặt tốt nhất, phần cứng :

DECLARE @CPUs int;
DECLARE @NumaNodes int;
DECLARE @ServerRAMInMB int;

SET @ServerRAMinMB = (SELECT (i.physical_memory_kb / 1024) AS ServerMemory 
    FROM sys.dm_os_sys_info i);
SET @CPUs = (SELECT i.cpu_count from sys.dm_os_sys_info i);
SET @NumaNodes = (SELECT MAX(c.memory_node_id) + 1 FROM sys.dm_os_memory_clerks c 
    WHERE memory_node_id < 64);

SELECT @ServerRamInMB, @CPUs, @NumaNodes;

IF @CPUs > 4 /* this would be 4 cores, not 4 CPUs */
BEGIN
    DECLARE @MaxDOP int;
    SET @MaxDOP = @CPUs * 0.75;
    IF @MaxDOP > (@CPUs / @NumaNodes) SET @MaxDOP = (@CPUs / @NumaNodes);
    EXEC sp_configure 'max degree of parallelism', @MaxDOP;
    EXEC sp_configure 'cost threshold for parallelism', 4; 
END

Tôi đã bao gồm @ServerRamInMBtham số ở đây vì tôi sử dụng nó để thiết lập các tùy chọn Max Server MemoryMin Server Memorycấu hình cho các giá trị phù hợp với máy chủ đã cho.


1
Tôi có RAM 64 GB, lõi xử lý 32, 4 nút numa. Tôi đặt mức độ song song tối đa là 8 và ngưỡng chi phí là 4. Với cài đặt này và với tùy chọn công suất được đặt thành công suất cao, Thời gian thực thi của SQL Server: Thời gian CPU = 550 ms, thời gian trôi qua = 828 ms.
prog_sr08

Vì vậy, đó là một chiến thắng, sau đó? Vui mừng khi thấy rằng làm việc cho bạn!
Max Vernon

0

Phiên bản và chế độ cấp phép nào bạn đang ở? Bạn có thể không sử dụng tất cả các lõi. Xem ghi chú trên trang này - http://msdn.microsoft.com/en-us/l Library / ms143760.aspx

"Phiên bản doanh nghiệp với giấy phép dựa trên Máy chủ + Giấy phép truy cập máy khách (CAL) bị giới hạn tối đa 20 lõi cho mỗi phiên bản SQL Server."


2
Điều này sẽ chỉ áp dụng nếu anh ta có CAL trước đó và được tổ chức. Tuy nhiên, dù chỉ có 20 lõi, hiệu năng không được giảm đáng kể so với hệ thống cũ (chỉ có 8).
Aaron Bertrand

Tôi có Phiên bản Web (Giới hạn ở mức thấp hơn 4 Ổ cắm hoặc 16 lõi). Trên máy chủ cũ tôi chỉ có 8 lõi.
prog_sr08

0

Tôi gặp vấn đề tương tự như được mô tả trong trang này: chuyển đổi cài đặt nguồn điện từ "cân bằng" sang "hiệu suất cao" đã tạo ra sự khác biệt lớn - nhiều hơn gấp đôi thời gian phản hồi. Bây giờ chúng tôi đang sử dụng SSD Tôi không nghĩ tiêu thụ năng lượng là vấn đề có thể xảy ra.


-2

Tôi cũng đã giải quyết vấn đề này trong ít nhất 2 tuần mà không có bất kỳ giải pháp mạnh mẽ nào thay vì nhầm lẫn một vấn đề với vấn đề kia.

Cuối cùng giải quyết như sau: -

  1. Tôi đã đặt lại khả năng tương thích từ 010 đến 011

  2. Đặt lại khả năng tương thích của cơ sở dữ liệu chủ. Theo mặc định sql sẽ giữ lại cài đặt tương thích cũ. Rằng chúng ta cần thay đổi bằng tay.

Tất cả tốt nhất

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.