Hiệu suất máy chủ SQL chậm hơn sau khi phân bổ thêm CPU và RAM

Chúng tôi có SQL Server 2008 R2 (10.50.1600) đang chạy trên máy chủ Windows 2008 R2 ảo. Sau khi nâng cấp CPU từ 1 lõi lên 4 và RAM từ 4 gb lên 10 gb, chúng tôi nhận thấy hiệu suất kém hơn.

Một số quan sát tôi thấy:

1. Một truy vấn mất <5 giây để chạy hiện mất> 200 giây.
2. CPU được chốt ở mức 100 với sqlservr.exe là thủ phạm.
3. Số lượng chọn (*) trên một bảng có 4,6 triệu hàng mất hơn 90 giây.
4. Các quy trình đang chạy trên máy chủ không thay đổi. Thay đổi duy nhất là tăng cpu và ram.
5. Các máy chủ sql khác có một tệp hoán trang tĩnh nơi máy chủ này được thiết lập để tự quản lý nó.

Có ai gặp phải vấn đề này trước đây chưa?

Mỗi sp_BlitzErik, tôi đã chạy

EXEC dbo.sp_BlitzFirst @SinceStartup = 1;

Cho tôi những kết quả này.

Có rất nhiều thứ đang diễn ra ở đây, và hầu hết nó khá rộng và mơ hồ.

1. 2008R2 RTM ra mắt vào ngày 21 tháng 4 năm 2010. Nó hoàn toàn không hỗ trợ. Bạn sẽ muốn ưu tiên nhận Gói dịch vụ mới nhất, được phát hành chỉ khoảng 3 năm trước cho đến ngày. Bằng cách đó, bạn sẽ được bảo vệ nếu bạn gặp phải một lỗi lạ hoặc thứ gì đó. Đi qua đây để tìm ra những gì bạn cần tải về.

2. Vì bạn đã thêm vCPUs (từ 1 đến 4) và không thay đổi bất kỳ cài đặt nào, giờ đây các truy vấn của bạn có thể đi song song. Tôi biết điều này có vẻ như tất cả chúng sẽ nhanh hơn, nhưng hãy kiên nhẫn!

3. Bạn có thể đã thêm RAM, nhưng bạn có thể không thay đổi Bộ nhớ máy chủ tối đa để máy chủ của bạn có thể tận dụng lợi thế của nó.

4. Tìm hiểu những gì máy chủ của bạn đang chờ đợi. Một dự án nguồn mở mà tôi làm việc cung cấp các tập lệnh miễn phí để giúp bạn đo SQL Server của mình. Đi về phía trên nếu bạn muốn cho họ một thử.

Bạn sẽ muốn lấy sp_BlitzFirst để kiểm tra số liệu thống kê chờ của máy chủ của bạn. Bạn có thể chạy nó một vài cách.

Điều này sẽ cho bạn thấy những gì máy chủ của bạn đã chờ đợi kể từ khi nó khởi động.

EXEC dbo.sp_BlitzFirst @SinceStartup = 1;

Điều này sẽ cho bạn thấy những truy vấn nào đang chờ đợi bây giờ, trong một cửa sổ 30 giây.

EXEC dbo.sp_BlitzFirst @Seconds = 30, @ExpertMode = 1;

Khi bạn tìm ra những truy vấn nào đang chờ đợi (có rất nhiều nội dung được viết về số liệu thống kê chờ đợi ngoài kia), bạn có thể bắt đầu thực hiện các thay đổi để kiểm soát mọi thứ.

Nếu bạn thấy họ chờ đợi CXPACKET, điều đó có nghĩa là các truy vấn của bạn sẽ diễn ra song song và có thể chà đạp lên nhau. Nếu bạn đạt được điều này, có lẽ bạn sẽ muốn xem xét Ngưỡng chi phí cho tính song song lên tới 50 và có thể giảm MAXDOP xuống còn 2.

Sau bước này là khi bạn muốn sử dụng một cái gì đó như sp_WhoIsActive hoặc sp_BlitzWho (cái sau nằm trong repo GitHub từ trước đó) để bắt đầu nắm bắt các kế hoạch truy vấn. Ngoài số liệu thống kê chờ đợi, chúng là một trong những điều quan trọng nhất bạn có thể xem xét để tìm ra điều gì sai.

Bạn cũng có thể muốn xem bài viết này của Jonathan Kehayias về Bộ đếm VMWare để kiểm tra liên quan đến SQL Server.

Cập nhật

Xem lại các số liệu thống kê chờ đợi và cậu bé là lạ. Chắc chắn có điều gì đó xảy ra với CPU. Máy chủ của bạn chủ yếu ngồi xung quanh buồn chán, nhưng khi mọi thứ nóng lên, mọi thứ trở nên tồi tệ. Tôi sẽ cố gắng phá vỡ điều này một cách dễ dàng.

1. Bạn đang chờ đợi một chất độc được gọi là THREADPOOL. Bạn không có quá nhiều thứ, nhưng điều đó có ý nghĩa vì máy chủ của bạn không hoạt động khủng khiếp. Tôi sẽ giải thích tại sao trong một phút nữa.

2. Bạn đã thực sự chờ đợi trung bình dài SOS_SCHEDULER_YIELDvà CXPACKET. Bạn đang sử dụng máy ảo, vì vậy bạn sẽ chắc chắn rằng Máy chủ SQL có đặt chỗ hoặc hộp không bị đăng ký quá khủng khiếp. Một người hàng xóm ồn ào thực sự có thể làm hỏng ngày của bạn ở đây. Bạn cũng sẽ muốn đảm bảo rằng máy chủ / máy khách VM / máy chủ VM không chạy ở chế độ Cân bằng. Điều này làm cho CPU của bạn quay xuống tốc độ thấp không cần thiết và chúng không ngay lập tức quay trở lại tốc độ tối đa.

3. Làm thế nào để họ buộc trong? Với 4 CPU bạn có 512 luồng công nhân. Hãy nhớ rằng, bạn có cùng số tiền với một CPU, nhưng bây giờ các truy vấn của bạn có thể đi song song, chúng có thể tiêu thụ nhiều luồng công nhân hơn. Trong trường hợp của bạn, 4 luồng trên mỗi nhánh song song của một truy vấn song song.

Điều gì đang xảy ra song song? Nhiều khả năng là tất cả mọi thứ. Ngưỡng chi phí mặc định cho tính song song là 5. Con số đó được làm mặc định vào cuối những năm 90 làm việc trên máy tính để bàn trông như thế này .

Cấp, phần cứng của bạn nhỏ hơn hầu hết các máy tính xách tay, nhưng bạn vẫn đi trước một chút về điều đó.

Khi có nhiều truy vấn song song, bạn sẽ hết các luồng công nhân đó. Khi điều đó xảy ra, các truy vấn chỉ cần ngồi chờ đợi các chủ đề được thực hiện. Đó cũng là nơi SOS_SCHEDULER_YIELDxuất hiện. Các truy vấn đang loại bỏ CPU và không hoạt động trở lại trong một thời gian dài. Tôi không thấy bất kỳ sự chờ đợi chặn nào, vì vậy rất có thể bạn chỉ bị nhồi nhét vào sự chờ đợi song song truy vấn nội bộ.

Bạn có thể làm gì?

1. Đảm bảo không có gì ở chế độ Cân bằng điện
2. Thay đổi MAXDOP thành 2
3. Thay đổi ngưỡng chi phí cho song song thành 50
4. Thực hiện theo bài viết Jon K. ở trên để xác thực sức khỏe VM
5. Sử dụng tập lệnh được gọi sp_BlitzIndexđể tìm kiếm bất kỳ yêu cầu chỉ mục bị thiếu.

Để khắc phục sự cố kỹ lưỡng hơn, hãy xem whitepaper tôi đã viết cho Google về kích thước phần cứng trong đám mây.

Hi vọng điêu nay co ich!

Vâng! Tôi đã trải nghiệm loại tình huống này trên SQL Server vms trong cụm máy chủ của chúng tôi. Nhìn vào thời gian sẵn sàng CPU của máy chủ vm và bộ đếm trình điều khiển bóng nhớ. CPU SYN SÀNG THỜI GIAN - BLOG PHẦN I và Tìm hiểu về Balloon Ballooning Làm việc với sysadmin của tôi là chìa khóa, nhưng không dễ ...

Một điều tôi không thấy chỉ ra, đó là việc thêm vCPU vào máy ảo có thể rất thường xuyên làm chậm nó do lập lịch.

Ý tưởng cơ bản là nếu một VM có 4 vCPU, thì trình ảo hóa phải chờ 4 lõi vật lý có sẵn để có thể lên lịch cho tất cả các vCPU, ngay cả khi 3 trong số chúng không hoạt động.

Nếu bạn không có nhiều lõi trong máy chủ của mình và khối lượng công việc khác của bạn đang bận, điều này có thể dẫn đến sự chờ đợi thêm và hiệu suất giảm đáng kể.

Trong VMware ESXi, bạn có thể thấy nó trong các biểu đồ nâng cao thông qua CPU Ready.

Đây là một trong nhiều bài viết với một ví dụ thực tế về điều này xảy ra và cách nó được chẩn đoán .

Thêm nhiều RAM hơn cũng có thể làm giảm hiệu suất đột ngột nếu phân bổ RAM của VM lớn hơn nút NUMA.

Ngoài ra, cấu hình của vCPUs (vSockets so với vCores) thực sự có thể ảnh hưởng đến một số ứng dụng như máy chủ SQL. Điều này là do máy chủ SQL tự nhận biết NUMA (để tránh cùng loại giảm hiệu suất kéo dài NUMA) và vì VMware có thể trình bày các nút NUMA ảo khác nhau.

Điều này được đề cập trong một bài đăng trên blog của trang web riêng của VMware .

Điều này được nói, tôi rất vui vì bạn đã giải quyết các vấn đề với sự giúp đỡ của Erik, nhưng bạn có thể muốn xem xét và xem xét những điều này.

Chỉ cần một chút trợ giúp (không thể đăng bài này dưới dạng nhận xét) tiếp tục câu trả lời của @ sp_BlitzErik, tôi đã nhận được một số truy vấn với Pinal và Max Vernon (không thể nhớ ở đâu) cho biết bạn nên sử dụng MAXDOP bao nhiêu:

/*************************************************************************
Author          :   Kin Shah
Purpose         :   Recommend MaxDop settings for the server instance
Tested RDBMS    :   SQL Server 2008R2

**************************************************************************/
declare @hyperthreadingRatio bit
declare @logicalCPUs int
declare @HTEnabled int
declare @physicalCPU int
declare @SOCKET int
declare @logicalCPUPerNuma int
declare @NoOfNUMA int

select @logicalCPUs = cpu_count -- [Logical CPU Count]
    ,@hyperthreadingRatio = hyperthread_ratio --  [Hyperthread Ratio]
    ,@physicalCPU = cpu_count / hyperthread_ratio -- [Physical CPU Count]
    ,@HTEnabled = case 
        when cpu_count > hyperthread_ratio
            then 1
        else 0
        end -- HTEnabled
from sys.dm_os_sys_info
option (recompile);

select @logicalCPUPerNuma = COUNT(parent_node_id) -- [NumberOfLogicalProcessorsPerNuma]
from sys.dm_os_schedulers
where [status] = 'VISIBLE ONLINE'
    and parent_node_id < 64
group by parent_node_id
option (recompile);

select @NoOfNUMA = count(distinct parent_node_id)
from sys.dm_os_schedulers -- find NO OF NUMA Nodes 
where [status] = 'VISIBLE ONLINE'
    and parent_node_id < 64

-- Report the recommendations ....
select
    --- 8 or less processors and NO HT enabled
    case 
        when @logicalCPUs < 8
            and @HTEnabled = 0
            then 'MAXDOP setting should be : ' + CAST(@logicalCPUs as varchar(3))
                --- 8 or more processors and NO HT enabled
        when @logicalCPUs >= 8
            and @HTEnabled = 0
            then 'MAXDOP setting should be : 8'
                --- 8 or more processors and HT enabled and NO NUMA
        when @logicalCPUs >= 8
            and @HTEnabled = 1
            and @NoofNUMA = 1
            then 'MaxDop setting should be : ' + CAST(@logicalCPUPerNuma / @physicalCPU as varchar(3))
                --- 8 or more processors and HT enabled and NUMA
        when @logicalCPUs >= 8
            and @HTEnabled = 1
            and @NoofNUMA > 1
            then 'MaxDop setting should be : ' + CAST(@logicalCPUPerNuma / @physicalCPU as varchar(3))
        else ''
        end as Recommendations

-------------------------------------------------- -------

--MAX VERNON 

/* 
   This will recommend a MAXDOP setting appropriate for your machine's NUMA memory
   configuration.  You will need to evaluate this setting in a non-production 
   environment before moving it to production.

   MAXDOP can be configured using:  
   EXEC sp_configure 'max degree of parallelism',X;
   RECONFIGURE

   If this instance is hosting a Sharepoint database, you MUST specify MAXDOP=1 
   (URL wrapped for readability)
   http://blogs.msdn.com/b/rcormier/archive/2012/10/25/
   you-shall-configure-your-maxdop-when-using-sharepoint-2013.aspx

   Biztalk (all versions, including 2010): 
   MAXDOP = 1 is only required on the BizTalk Message Box
   database server(s), and must not be changed; all other servers hosting other 
   BizTalk Server databases may return this value to 0 if set.
   http://support.microsoft.com/kb/899000
*/
SET NOCOUNT ON;

DECLARE @CoreCount int;
SET @CoreCount = 0;
DECLARE @NumaNodes int;

/*  see if xp_cmdshell is enabled, so we can try to use 
    PowerShell to determine the real core count
*/
DECLARE @T TABLE (
    name varchar(255)
    , minimum int
    , maximum int
    , config_value int
    , run_value int
);
INSERT INTO @T 
EXEC sp_configure 'xp_cmdshell';
DECLARE @cmdshellEnabled BIT;
SET @cmdshellEnabled = 0;
SELECT @cmdshellEnabled = 1 
FROM @T
WHERE run_value = 1;
IF @cmdshellEnabled = 1
BEGIN
    CREATE TABLE #cmdshell
    (
        txt VARCHAR(255)
    );
    INSERT INTO #cmdshell (txt)
    EXEC xp_cmdshell 'powershell -OutputFormat Text -NoLogo -Command "& {Get-WmiObject -namespace "root\CIMV2" -class Win32_Processor -Property NumberOfCores} | select NumberOfCores"';
    SELECT @CoreCount = CONVERT(INT, LTRIM(RTRIM(txt)))
    FROM #cmdshell
    WHERE ISNUMERIC(LTRIM(RTRIM(txt)))=1;
    DROP TABLE #cmdshell;
END
IF @CoreCount = 0 
BEGIN
    /* 
        Could not use PowerShell to get the corecount, use SQL Server's 
        unreliable number.  For machines with hyperthreading enabled
        this number is (typically) twice the physical core count.
    */
    SET @CoreCount = (SELECT i.cpu_count from sys.dm_os_sys_info i); 
END

SET @NumaNodes = (
    SELECT MAX(c.memory_node_id) + 1 
    FROM sys.dm_os_memory_clerks c 
    WHERE memory_node_id < 64
    );

DECLARE @MaxDOP int;

/* 3/4 of Total Cores in Machine */
SET @MaxDOP = @CoreCount * 0.75; 

/* if @MaxDOP is greater than the per NUMA node
    Core Count, set @MaxDOP = per NUMA node core count
*/
IF @MaxDOP > (@CoreCount / @NumaNodes) 
    SET @MaxDOP = (@CoreCount / @NumaNodes) * 0.75;

/*
    Reduce @MaxDOP to an even number 
*/
SET @MaxDOP = @MaxDOP - (@MaxDOP % 2);

/* Cap MAXDOP at 8, according to Microsoft */
IF @MaxDOP > 8 SET @MaxDOP = 8;

PRINT 'Suggested MAXDOP = ' + CAST(@MaxDOP as varchar(max));