Việc sử dụng CPU rất không đồng đều với SQL Server 2012 trên máy tính 2 bộ xử lý với 16 nhân / bộ xử lý


8

Sau khi cài đặt SQL Server Enterprise 2012 với mô hình giấy phép Server + Cal, trên máy tính có 2 bộ xử lý, mỗi lõi có 16 lõi (và không liên quan đến siêu phân luồng) và đặt máy chủ dưới tải cực lớn, 16 lõi trên bộ xử lý đầu tiên được sử dụng rất ít, 4 lõi đầu tiên trên CPU thứ 2 đã được sử dụng rất nhiều và 12 lõi cuối cùng hoàn toàn không được sử dụng (vì giới hạn 20 lõi cho phiên bản máy chủ sql này). Tổng mức sử dụng CPU được hiển thị khoảng 25%. Thật không may, máy chủ phải chịu hiệu năng cực kỳ kém mặc dù nếu các tác vụ được phân bổ đều trên 20 lõi thì nó sẽ không ở đâu tệ như vậy.

Máy chủ Windows đang chạy trên hình ảnh ảo VMWare trong ESX Server, nhưng tất cả CPU được phân bổ cho máy chủ windows.

Chúng tôi đã thử thay đổi cài đặt mối quan hệ (ví dụ: phân bổ hầu hết các lõi cho CPU và các lõi khác cho I / O), nhưng điều đó không giúp giải quyết các vấn đề về hiệu năng.

Nâng cấp phiên bản sản phẩm lên SQL Server Enterprise Core 2012 không chỉ cho phép SQL Server sử dụng 12 lõi chưa sử dụng trước đó trên bộ xử lý thứ 2 mà còn dẫn đến phân phối nhiệm vụ đồng đều hơn trên tất cả các bộ xử lý. Để vượt qua các yêu cầu tồn đọng, việc sử dụng cpU đã tăng vọt lên khoảng 90%, và sau đó giảm xuống còn khoảng 33% sau khi nó bị bắt kịp, nhưng hiệu suất đã được cải thiện đáng kể do chúng tôi đã thất bại với phiên bản mới cập nhật và các vấn đề về hiệu suất đã biến mất.

Tôi đã tự hỏi liệu có ai biết điều gì có thể khiến SQL Server phân phối tải không đều, hầu như chỉ dựa vào 4 lõi đầu tiên của bộ xử lý thứ 2 có 12 lõi nhàn rỗi và chỉ phân bổ một vài nhiệm vụ cho mỗi trong số 16 lõi đầu tiên bộ xử lý. Ngoài ra, có cách nào để chúng tôi có thể phân phối tải đều hơn trên 20 lõi đang được sử dụng mà không cần nâng cấp phiên bản sản phẩm không?

Mặt trái của câu hỏi đó là việc nâng cấp sản phẩm đã làm gì khiến SQL Server bắt đầu phân phối tải đều trên tất cả các lõi mà nó nhận ra?

Nhờ có bất kỳ cái nhìn sâu sắc nào để trả lời những câu hỏi và / hoặc liên kết này có thể giúp tôi hiểu rõ hơn về cách hiểu ý nghĩa của những gì đã xảy ra.


Bạn đang nói rằng máy đang được đề cập là một VM có 32 vCPU? Trong cả hai kịch bản?
mfinni

Vâng, đó là cùng một máy có 2 bộ xử lý, mỗi bộ có 16 lõi (và không có siêu phân luồng nào được tham gia).
cooplarsh

1
Tại sao nhân danh CHÚA bạn có 32 vCPU? Bạn đã thử giảm điều đó? Tôi biết rằng ESXi đã cải thiện việc lập lịch trình cho các nhóm CPU của mình, nhưng bạn chỉ đang gặp rắc rối với số đó. Bạn đang dùng phiên bản ESXi nào và phần cứng cơ bản là gì?
mfinni

Câu trả lời:


4

Hiệu suất không đồng đều có thể là sự kết hợp của giới hạn 20 lõi kết hợp với cách máy chủ sql lên lịch các luồng trên các máy NUMA. Thật không may, SQL Server 2012 không sử dụng bất kỳ trí thông minh nào trong việc quyết định sử dụng 20 lõi nào, dẫn đến số lượng lõi không cân bằng trên mỗi nút NUMA. Với 32 lõi trải đều trên 2 NUMA Nút, rất có thể bạn sẽ kết thúc với việc phân chia 16/4. Đây là vấn đề vì SQL sẽ cố gắng cân bằng hoạt động như nhau trên các nút NUMA theo kiểu vòng tròn (giả sử rằng bạn không ép buộc mối quan hệ w / tài nguyên tài nguyên).

Trong trường hợp của bạn, 1/2 tải được gán cho 4 lõi và 1/2 đến 16 lõi. Nút cổ chai trên nút 4 lõi hoạt động hiệu quả như một bộ tiết lưu, giới hạn công suất của máy ở mức 2 nhân 4 nhân = 8 nhân = 25% mức sử dụng CPU.

Khi bạn nâng cấp lên phiên bản lõi, thì sql sử dụng tất cả 32 lõi trên 2 nút numa (chia 16/16). Hiệu suất được cải thiện, vv

Một tùy chọn có thể cải thiện hiệu suất của bạn sẽ là sử dụng bộ điều chỉnh tài nguyên máy chủ sql để xác định phần lớn khối lượng công việc của bạn thành một nút numa. Ví dụ: bạn có thể tạo một nhóm tài nguyên WEB_APP và xác nhận lại nó để chỉ chạy trên nút số 16 lõi. Tải được gán cho nhóm WEB_APP có thể sử dụng 50% dung lượng máy chủ, cộng với 12,5% dung lượng còn lại từ nút 4 lõi.

Tùy chọn khác sẽ giới hạn các lõi có sẵn cho máy chủ sql chỉ còn 10 từ mỗi nút numa.

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.