Các vấn đề về hiệu suất với SQL Server 2012 Enterprise Edition theo cấp phép CAL

Nhiều thay đổi cấp phép đã được giới thiệu trong SQL Server 2012; quan trọng nhất là việc chuyển từ cấp phép dựa trên socket sang cấp phép dựa trên lõi cho Enterprise Edition. Một trong những thách thức mà Microsoft phải đối mặt với sự thay đổi này là cung cấp một đường dẫn di chuyển cho những khách hàng trước đây đã sử dụng cấp phép dựa trên Server + CAL cho Enterprise Edition trước SQL Server 2012. Khách hàng thuộc Software Assurance có thể nâng cấp lên SQL Server 2012 Enterprise Edition và vẫn sử dụng Server + Cấp phép CAL (còn được gọi là "grandfathering") nhưng với giới hạn đối với 20 bộ xử lý logic, như được ghi trong Hướng dẫn cấp phép SQL Server 2012. Giấy phép này cũng mở rộng cho các máy ảo với giới hạn 4 máy ảo được bao gồm trong giấy phép Máy chủ doanh nghiệp + CAL, nhưng vẫn có cùng giới hạn 20 bộ xử lý lôgic như được nêu trong Hướng dẫn cấp phép ảo hóa SQL Server 2012.

Rất nhiều người đã mất cảnh giác bởi giới hạn 20 bộ xử lý logic, mặc dù nó đã được ghi trong hướng dẫn cấp phép.

Một mục nhập được tạo trong tệp ERRORLOG khi phiên bản khởi động, chỉ định số lượng bộ xử lý logic và giới hạn 20 bộ xử lý đang được thực thi:

Với cấu hình mặc định mà SQL Server áp dụng theo giới hạn 20 bộ xử lý logic sử dụng Máy chủ + CAL, 20 bộ lập lịch đầu tiên có thể TRỰC TUYẾN và bất kỳ bộ lập lịch nào còn lại đều CÓ THỂ TRỰC TUYẾN. Do đó, chẳng hạn như có thể xảy ra các vấn đề về hiệu suất do sự mất cân bằng của trình lập lịch nút NUMA. Để chứng minh điều này, tôi đã tạo một máy ảo trên máy chủ thử nghiệm Dell R720 của chúng tôi, máy chủ này có cài đặt hai ổ cắm và bộ xử lý Intel Xeon E5-2670, mỗi ổ có 8 lõi và được bật Siêu phân luồng, cung cấp tổng cộng 32 bộ xử lý logic có sẵn trong Windows Server 2012 Datacenter Edition. Máy ảo đã được định cấu hình để có 32 CPU ảo với 16 bộ xử lý ảo được phân bổ trong hai nút vNUMA.

Hình 1 - cài đặt vNUMA

Trong SQL Server theo mô hình cấp phép Máy chủ Doanh nghiệp + CAL, điều này dẫn đến cấu hình bộ lập lịch tương tự như sau:

 SELECT parent_node_id, [status], Scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulers; 

Hình 2 - Gán bộ lập lịch trong Máy chủ doanh nghiệp + CAL

Như bạn có thể thấy, tất cả 16 bộ xử lý logic trong nút NUMA đầu tiên và chỉ bốn bộ xử lý logic trong nút NUMA thứ hai được sử dụng bởi phiên bản. Điều này dẫn đến sự mất cân bằng đáng kể của bộ lập lịch giữa hai nút NUMA có thể dẫn đến các vấn đề hiệu suất đáng kể khi tải. Để chứng minh điều này, tôi tạo ra 300 kết nối đang chạy khối lượng công việc AdventureWorks Books Online đối với phiên bản và sau đó nắm bắt thông tin về bộ lập lịch cho các bộ lập lịch VISIBLE ONLINE trong phiên bản bằng cách sử dụng truy vấn sau:

 SELECT parent_node_id, Scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE ONLINE '; 

Đầu ra ví dụ của truy vấn đang tải này được hiển thị trong Hình 3 bên dưới.

Hình 3 - Bộ lập lịch đang tải với Máy chủ doanh nghiệp + CAL

Bạn cũng có thể nhìn thấy triệu chứng này một cách trực quan trong các công cụ giám sát, chẳng hạn như SQL Sentry Performance Advisor:

Hình 4 - Sự mất cân bằng NUMA như được hiển thị trong SQL Sentry Performance Advisor

Thông tin này cho thấy sự mất cân bằng đáng kể và kết quả là hiệu suất sẽ bị ảnh hưởng. Điều này thể hiện rõ ràng trong số các tác vụ có thể chạy được cho bốn bộ lập lịch trong nút NUMA thứ hai, gấp ba đến bốn lần kích thước của các bộ lập lịch trong nút NUMA đầu tiên. Vậy vấn đề chính xác là gì và tại sao điều này lại xảy ra?

Thoạt nhìn, bạn có thể nghĩ rằng đây là một lỗi trong SQL Server, nhưng không phải vậy. Đây là một cái gì đó xảy ra theo thiết kế, mặc dù tôi nghi ngờ rằng kịch bản này đã được mong đợi khi giới hạn bộ xử lý lôgic 20 được triển khai ban đầu. Trên các hệ thống dựa trên NUMA, các kết nối mới được chỉ định cho các nút NUMA theo kiểu vòng tròn và sau đó bên trong nút NUMA, kết nối được chỉ định cho một bộ lập lịch dựa trên tải. Nếu chúng tôi thay đổi cách chúng tôi xem xét dữ liệu này và tổng hợp dữ liệu dựa trên parent_node_id, chúng tôi sẽ thấy rằng các tác vụ thực sự đang được cân bằng trên các nút NUMA. Để thực hiện việc này, chúng tôi sẽ sử dụng truy vấn sau, kết quả của nó được hiển thị trong Hình 5.

 SELECT parent_node_id, SUM (current_tasks_count) AS current_tasks_count, SUM (runnable_tasks_count) AS runnable_tasks_count, SUM (active_workers_count) AS active_workers_count, AVG (load_factor) AS avg_load_factorFROM_BLE_dịch_sĩ_của_bình_trạng_nhưng / pre> 

  
  Hình 5 - Số dư vòng quay của nút NUMA  
 

 Hành vi này được ghi lại trong Books Online for SQL Server (http://msdn.microsoft.com/en-us/library/ms180954(v=sql.105).aspx). Biết những gì tôi biết về SQLOS, SQL Server và phần cứng, điều này có ý nghĩa. Trước giới hạn 20 bộ xử lý logic trong SQL Server 2012 Enterprise Edition với cấp phép Máy chủ + CAL, một trường hợp hiếm gặp là SQL Server sẽ có sự mất cân bằng bộ lập lịch giữa các nút NUMA trong máy chủ sản xuất. Một trong những vấn đề trong trường hợp cụ thể này là cách mà NUMA ảo được truyền đến máy ảo. Thực hiện cài đặt giống hệt nhau trên phần cứng vật lý cho phép tất cả các bộ lập lịch CÓ THỂ TRỰC TUYẾN vì các bộ xử lý logic bổ sung được trình bày bởi siêu luồng có thể phân biệt được bằng SQL và miễn phí. 
 

  Nói cách khác, giới hạn 20 bộ xử lý logic thực sự dẫn đến 40 bộ lập lịch TRỰC TUYẾN nếu (a) nó không phải là máy ảo, (b) bộ xử lý là Intel và (c) siêu phân luồng được bật.  
 

 Vì vậy, chúng tôi thấy thông báo này trong nhật ký lỗi:
 Ngày 14/11/2012 10:36:18 CH 
 Nhật ký SQL Server (Hiện tại - 14/11/2012 10:36:00 CH) 
 Máy chủ nguồn 
 Thông báo 
 SQL Máy chủ đã phát hiện 2 ổ cắm với 8 lõi trên mỗi ổ cắm và 16 bộ xử lý lôgic trên mỗi ổ cắm, tổng số 32 bộ xử lý lôgic; sử dụng 32 bộ xử lý logic dựa trên giấy phép SQL Server. Đây là một thông báo; không có hành động nào của người dùng được yêu cầu. 

 Và truy vấn tương tự như trên dẫn đến tất cả 32 bộ xử lý đều CÓ THỂ TRỰC TUYẾN:
 
 SELECT parent_node_id, [status], Scheduler_id, [cpu_id], is_idle, current_tasks_count, runnable_tasks_count, active_workers_count, load_factorFROM sys.dm_os_schedulersWHERE [status] =N'VISIBLE ONLINE '; 
 

  
  Hình 6 - Cấu hình tương tự trên phần cứng vật lý  
 

 Trong trường hợp này, vì chỉ có 32 bộ xử lý logic nên giới hạn lõi 20 (tốt, 40) hoàn toàn không ảnh hưởng đến chúng tôi và công việc được phân bổ đồng đều trên tất cả các lõi. 
 

 Trong các tình huống mà giới hạn 20 bộ xử lý ảnh hưởng đến số dư NUMA bộ lập lịch, có thể thay đổi cấu hình máy chủ theo cách thủ công để cân bằng số bộ lập lịch TRỰC TUYẾN CÓ THỂ trong mỗi nút trong số NUMA nút thông qua việc sử dụng ALTER SERVER CONFIGURATION . Trong ví dụ máy ảo được cung cấp, lệnh sau sẽ định cấu hình 10 bộ xử lý logic đầu tiên trong mỗi nút NUMA thành CÓ THỂ TRỰC TUYẾN. 
 
 QUY TRÌNH CÀI ĐẶT CẤU HÌNH MÁY CHỦ ALTER AFFINITY CPU =0 TO 9, 16 TO 25; 
 

 Với cấu hình mới này, chạy cùng một khối lượng công việc 300 phiên và khối lượng công việc AdventureWorks Books Online, chúng ta có thể thấy rằng tình trạng mất cân bằng tải không còn xảy ra nữa. 
 

  
  Hình 7 - Cân bằng được khôi phục với cấu hình thủ công  
 

 Và một lần nữa bằng cách sử dụng SQL Sentry Performance Advisor, chúng ta có thể thấy tải CPU được phân bổ đồng đều hơn trên cả hai nút NUMA:
 

  
  Hình 8 - Số dư NUMA như được hiển thị trong SQL Sentry Performance Advisor  
 

 Vấn đề này không chỉ giới hạn ở các máy ảo và cách các CPU ảo được trình bày với hệ điều hành. Cũng có thể gặp sự cố này với phần cứng vật lý. Ví dụ:Dell R910 cũ hơn với bốn ổ cắm và tám lõi trên mỗi ổ cắm hoặc thậm chí là một máy chủ dựa trên AMD Opteron 6200 Interlagos với hai ổ cắm và 16 lõi trên mỗi ổ cắm, tự thể hiện dưới dạng bốn nút NUMA với tám lõi mỗi ổ. Theo một trong hai cấu hình này, sự mất cân bằng quy trình cũng có thể dẫn đến một trong các nút NUMA được đặt ngoại tuyến hoàn toàn. Do đó, các tác dụng phụ khác như bộ nhớ từ nút đó được phân phối trên các nút trực tuyến dẫn đến các vấn đề truy cập bộ nhớ nước ngoài cũng có thể làm giảm hiệu suất. 
 
 Tóm tắt 
 

 Cấu hình mặc định của SQL Server 2012 sử dụng cấp phép Phiên bản Doanh nghiệp cho Máy chủ + CAL không phải là lý tưởng trong tất cả các cấu hình NUMA có thể tồn tại cho Máy chủ SQL. Bất cứ khi nào cấp phép Máy chủ Doanh nghiệp + CAL đang được sử dụng, cấu hình NUMA và trạng thái bộ lập lịch trên mỗi nút NUMA cần được xem xét để đảm bảo rằng Máy chủ SQL được định cấu hình để có hiệu suất tối ưu. Sự cố này không xảy ra theo giấy phép dựa trên lõi vì tất cả các bộ lập lịch đều được cấp phép và CÓ THỂ TRỰC TUYẾN.