VMware CPU Hot Plug vNUMA Hiệu ứng trên SQL Server

Khi ESX 5 và Hyper-V trong Windows Server 2012 được phát hành và thay đổi các hạn chế tồn tại trước đây đối với kích thước VM, tôi gần như ngay lập tức biết rằng chúng ta sẽ thấy nhiều khối lượng công việc SQL Server mở rộng quy mô lớn hơn bắt đầu được ảo hóa. Trong năm ngoái, tôi đã làm việc với một số khách hàng đang ảo hóa Máy chủ SQL lõi 16-32 với nhiều lý do khác nhau, từ các chiến lược Khôi phục thảm họa đơn giản hóa phù hợp với phần còn lại của doanh nghiệp, đến hợp nhất và giảm tổng chi phí sở hữu trên phần cứng mới hơn nền tảng. Một trong những lý do giải thích cho sự thay đổi khả năng mở rộng với ESX 5+ là sự ra đời của NUMA ảo (vNUMA) cho nhiều khách vượt quá kích thước của một nút NUMA phần cứng riêng lẻ. Với vNUMA, máy ảo khách được tối ưu hóa để phù hợp với cấu trúc liên kết NUMA phần cứng, cho phép hệ điều hành khách và bất kỳ ứng dụng nhận biết NUMA nào, như SQL Server, đang chạy trên máy ảo để tận dụng tối ưu hóa hiệu suất NUMA, giống như khi chúng đang chạy trên máy chủ vật lý.

Trong VMware, cấu trúc liên kết vNUMA có sẵn trên phiên bản phần cứng 8 trở lên và được định cấu hình theo mặc định nếu số lượng vCPU lớn hơn tám cho khách. Cũng có thể định cấu hình cấu trúc liên kết vNUMA cho máy ảo theo cách thủ công bằng cách sử dụng các tùy chọn cấu hình nâng cao, điều này có thể hữu ích cho máy ảo có nhiều bộ nhớ được cấp cho chúng hơn so với nút NUMA vật lý có thể cung cấp, nhưng vẫn sử dụng tám vCPU trở xuống. Đối với hầu hết các phần, cài đặt cấu hình mặc định hoạt động cho phần lớn các máy ảo mà tôi đã xem xét trong vài năm qua, nhưng có một số trường hợp nhất định trong đó cấu trúc liên kết vNUMA mặc định không lý tưởng và cấu hình thủ công có thể mang lại một số lợi ích. Gần đây, tôi đã làm việc với một máy khách có 32 máy ảo vCPU SQL Server với 512GB RAM được phân bổ để thực hiện một số điều chỉnh hiệu suất trong đó cấu trúc liên kết vNUMA không giống với những gì mong đợi.

Máy chủ lưu trữ VM trong môi trường này là bốn bộ xử lý lõi tám socket E5-4650 và RAM 1TB, mỗi máy dành riêng cho một máy chủ SQL duy nhất trong các hoạt động điển hình, nhưng có khả năng duy trì hai máy ảo trong trường hợp lỗi. Với cách bố trí phần cứng này, có bốn nút NUMA, một nút trên mỗi ổ cắm và cấu hình VM dự kiến ​​cũng sẽ có 4 nút vNUMA được trình bày cho cấu hình 32 vCPU. Tuy nhiên, những gì tôi tìm thấy khi xem các DMV trong SQL Server là không phải như vậy:

Hình 1 - Cấu hình vNUMA không chính xác

Như bạn có thể thấy trong hình ảnh, có điều gì đó thực sự không ổn với cấu hình NUMA trên máy chủ này. Có bốn nút bộ nhớ trong SQLOS và chỉ một nút CPU duy nhất, với tất cả các vCPU được cấp phát trong đó. Thành thật mà nói, điều này đã làm tôi suy nghĩ khi nhìn thấy nó vì nó đi ngược lại tất cả những gì tôi biết về cách SQLOS định cấu hình các cấu trúc bên trong khi khởi động phiên bản. Sau khi tìm hiểu một chút về các tệp ErrorLog, Performance Monitor và Windows Task Manager, tôi đã tải xuống bản sao của CoreInfo từ SysInternals và xem bố cục NUMA đang được báo cáo cho Windows.

Bộ xử lý lôgic tới Bản đồ nút NUMA:
******************************** Nút NUMA 0

Đầu ra CoreInfo xác nhận rằng máy ảo trình bày 32 vCPU dưới dạng 4 ổ cắm khác nhau, nhưng sau đó nhóm tất cả 32 vCPU thành NUMA Node 0. Nhìn vào bộ đếm hiệu suất Windows Server 2012 trên VM, tôi có thể thấy từ nhóm bộ đếm NUMA Node Memory, rằng 4 NUMA nút bộ nhớ đã được trình bày cho HĐH với bộ nhớ được phân bổ đồng đều trên các nút. Tất cả điều này đều phù hợp với những gì tôi đã thấy trong SQLOS và tôi cũng có thể biết từ các mục nhập ERRORLOG khởi động rằng mặt nạ cpu cho nút đang che tất cả các CPU có sẵn vào CPU Node 0, nhưng bốn Bộ phân bổ Trang Lớn đang được tạo, một cho mỗi nút bộ nhớ.

Tại thời điểm này, tôi đã chắc chắn đó là một cái gì đó liên quan đến cấu hình VM, nhưng tôi không thể xác định vấn đề cụ thể là gì vì tôi chưa bao giờ thấy hành vi này trên các máy ảo SQL Server rộng khác mà tôi đã hỗ trợ khách hàng trên VMware ESX 5+ trong quá khứ. Sau khi thực hiện một vài thay đổi cấu hình đối với máy chủ VM thử nghiệm đã có sẵn, chỉ có điều không ai trong số họ sửa cấu hình vNUMA được trình bày bên trong máy ảo. Sau khi gọi đến bộ phận hỗ trợ của VMware, chúng tôi đã được yêu cầu tắt tính năng ổ cắm nóng vCPU cho máy ảo thử nghiệm và xem liệu điều đó có khắc phục được sự cố hay không. Với việc tắt phích cắm nóng trên máy ảo, đầu ra CoreInfo xác nhận rằng ánh xạ vNUMA của bộ xử lý cho máy ảo bây giờ là chính xác:

Bộ xử lý lôgic tới Bản đồ nút NUMA:
******** ———————— Nút NUMA 0
——– ******** ————— - Nút NUMA 1
—————- ******** ——– Nút SỐ 2
———————— ******** Nút NUMA 3

Hành vi này thực sự được ghi lại trong bài viết VMware KB, (vNUMA bị vô hiệu hóa nếu VCPU hotplug được bật), từ tháng 10 năm 2013. Đây là máy ảo rộng đầu tiên dành cho SQL Server mà tôi đã làm việc với nơi bật vCPU hotplug và nó không phải là cấu hình điển hình mà tôi mong đợi cho một máy ảo 32 vCPU, nhưng là một phần của mẫu tiêu chuẩn đang được sử dụng tại máy khách và đã tình cờ ảnh hưởng đến Máy chủ SQL của họ.

Hiệu ứng của vNUMA bị vô hiệu hóa

Có một số tác động mà vNUMA bị vô hiệu hóa như vậy có thể phải đối với khối lượng công việc, nhưng có hai vấn đề cụ thể có thể ảnh hưởng đến SQL Server cụ thể theo kiểu cấu hình này. Đầu tiên là máy chủ có thể gặp sự cố với tích lũy chờ CMEMTHREAD vì có 32 vCPU được phân bổ cho một nút NUMA duy nhất và phân vùng mặc định cho các đối tượng bộ nhớ trong SQLOS là trên mỗi nút NUMA. Vấn đề cụ thể này đã được ghi lại bởi Bob Dorr trong nhóm CSS tại Microsoft trên bài đăng blog của họ SQL Server 2008/2008 R2 trên các máy mới hơn có hơn 8 CPU được trình bày trên mỗi nút NUMA Có thể cần theo dõi cờ 8048. Như một phần của việc xem xét số liệu thống kê chờ trên máy ảo với máy khách, tôi lưu ý rằng CMEMTHREAD là kiểu chờ cao thứ hai của họ, điều này là bất thường theo kinh nghiệm của tôi và khiến tôi phải xem cấu hình SQLOS NUMA được hiển thị trong Hình 1 ở trên. Trong trường hợp này, cờ theo dõi không phải là giải pháp, việc gỡ bỏ phích cắm nóng vCPU khỏi cấu hình máy ảo sẽ giải quyết được sự cố.

Vấn đề thứ hai sẽ ảnh hưởng đến SQL Server cụ thể nếu bạn đang sử dụng phiên bản chưa được vá được liên kết với quản lý bộ nhớ NUMA trong SQLOS và cách SQLOS theo dõi và quản lý các trang Away trong giai đoạn tăng cường bộ nhớ ban đầu sau khi khởi động phiên bản. Hành vi này đã được ghi lại bởi Bob Dorr trên bài đăng trên blog CSS, Cách hoạt động:SQL Server (NUMA Local, Foreign and Away Memory Blocks). Về cơ bản, khi SQLOS cố gắng cấp phát bộ nhớ nút cục bộ trong quá trình tăng cấp ban đầu, nếu địa chỉ bộ nhớ được trả về từ một nút bộ nhớ khác, trang sẽ được thêm vào danh sách Đi và một nỗ lực cấp phát bộ nhớ cục bộ khác xảy ra và quá trình lặp lại cho đến khi cấp phát bộ nhớ cục bộ thành công hoặc đạt đến mục tiêu bộ nhớ máy chủ. Vì ba phần tư bộ nhớ phiên bản của chúng tôi tồn tại trên các nút NUMA mà không có bất kỳ bộ lập lịch nào, điều này tạo ra điều kiện hiệu suất bị suy giảm trong quá trình tăng cấp bộ nhớ ban đầu cho phiên bản này. Các bản cập nhật gần đây đã thay đổi hành vi cấp phát bộ nhớ trong quá trình tăng cấp ban đầu để chỉ cố gắng cấp phát bộ nhớ cục bộ một số lần cố định (số cụ thể không được ghi lại) trước khi sử dụng bộ nhớ ngoài để tiếp tục xử lý. Các bản cập nhật đó được ghi lại trong KB # 2819662, Khắc phục:Sự cố hiệu suất SQL Server trong môi trường NUMA.

Tóm tắt

Đối với các máy ảo rộng, được định nghĩa là có nhiều hơn 8 vCPU, người giám sát mong muốn vNUMA được truyền vào máy ảo để cho phép Windows và SQL Server tận dụng tối ưu hóa NUMA trong cơ sở mã của chúng. Do đó, các máy ảo rộng hơn này không được bật cấu hình ổ cắm nóng vCPU, vì cấu hình này không tương thích với vNUMA và có thể dẫn đến giảm hiệu suất cho SQL Server khi được ảo hóa.