Tốc độ xung nhịp CPU so với số lõi CPU - GHz cao hơn hoặc nhiều lõi hơn cho SQL Server?

Chúng tôi đang bắt đầu cung cấp một tập hợp các máy chủ vật lý cho một cụm các nút SQL Server 2016 ảo trong VMware. Chúng tôi sẽ sử dụng giấy phép Phiên bản doanh nghiệp.

Chúng tôi dự định thiết lập 6 nút, nhưng có một chút tranh luận về cách thức lý tưởng để cung cấp các máy chủ vật lý liên quan đến tốc độ xung nhịp của CPU so với số lượng lõi CPU.

Tôi biết điều này phần lớn phụ thuộc vào khối lượng giao dịch và số lượng cơ sở dữ liệu được lưu trữ giữa các yếu tố cụ thể phần mềm khác, nhưng có một quy tắc chung nào được khuyên dùng không?

Chẳng hạn, máy chủ vật lý 8 lõi, 3,2 GHz (16 lõi) có ưu tiên hơn so với máy chủ 16 lõi kép, 2,6 GHz (32 lõi) không?

Có ai bắt gặp một tờ giấy trắng đi sâu vào loại chủ đề này không?

Nguyên tắc chung là giữ cho số lõi càng thấp càng tốt và tốc độ xử lý càng cao càng tốt. Toán học cấp phép trên đó chứng minh điểm ở mức ~ 7.500 USD mỗi lõi cho Phiên bản đắt tiền.

Mua phần cứng chính xác có thể tự trả tiền trong việc giảm chi phí cấp phép. Xem Lựa chọn bộ xử lý cho SQL Server của Glenn Berry. Đây là một tài nguyên tuyệt vời về cách chọn bộ xử lý cho SQL Server.

Khi bạn xem xét cấu trúc cấp phép mỗi lõi của SQL Server, sẽ luôn hợp lý với tốc độ xử lý nhanh nhất có sẵn, bất kể loại khối lượng công việc, cho dù là OLTP hay phân tích. Có tốc độ lõi nhanh nhất có thể sẽ không bao giờ là vấn đề. Tăng số lượng lõi theo yêu cầu, nhưng không bao giờ làm điều đó bằng cách giảm tốc độ lõi.

Nói cách khác, đừng nghĩ bộ xử lý 16 x 2.2Ghz giống với bộ xử lý 8 x 4.5Ghz. Tiết kiệm chi phí khi sử dụng bộ xử lý 2.2Ghz so với bộ xử lý 4.5Ghz có thể sẽ tối đa khoảng 10.000 USD (đối với máy hai bộ xử lý Xeon thông thường). Nhảy từ 8 lõi lên 16 lõi với SQL Server Enterprise Edition có thể sẽ tiêu tốn hơn 60.000 USD phí bản quyền. Nói cách khác, bạn có thể tiết kiệm 10.000 đô la chi phí phần cứng, nhưng bạn sẽ mất thêm 50.000 đô la tiền cấp phép.

Nếu bạn quyết định bạn cần rất nhiều cơ xử lý song song và quyết định bạn cần 32 lõi cho nhiệm vụ trong tay, thì với các lõi nhanh nhất sẽ trả cổ tức trong thời gian xử lý giảm. Không ai sẽ có lỗi với bạn vì điều đó.

Đã nói tất cả, nếu lựa chọn là một CPU hoặc nhiều hơn một CPU, luôn luôn đi với nhiều hơn một . Chạy SQL Server (hoặc bất kỳ DBMS nào) trên một CPU có thể gây ra tất cả các loại sự cố do khả năng cho các hoạt động đồng thời bị hạn chế rất nhiều.

Giữ chặt giữ

Mặc dù các khía cạnh hiệu suất và cấp phép là thú vị, chúng không phải là khía cạnh duy nhất của khối lượng công việc cần xem xét.

Một điều có thể có tác động đến sự lựa chọn bộ xử lý là các luồng công nhân.

Chủ đề công nhân?

Vâng bạn thân! Chúng là những thứ mà SQL Server của bạn sẽ sử dụng để chạy các truy vấn của bạn và thực hiện tất cả các công cụ nền mà nó cần làm để giữ mọi thứ trong hình dạng.

Khi bạn hết chủ đề công nhân, bạn nhấn THREADPOOL chờ

THREADPOOL?

THREADPOOL. Đây là một trong những chờ đợi nhanh nhất mà bạn có thể có trên máy chủ của mình, cùng với RESOURCE_SEMAPHORE và RESOURCE_SEMAPHORE_QUERY_COMPILE . Nhưng đó là những chờ đợi bộ nhớ, và đây là một câu hỏi CPU.

Vì vậy, trở lại lý do tại sao điều này là wiggity wack.

Đây là cách SQL Server tính toán các luồng công nhân :

Lưu ý cách nhân đôi số lượng lõi không nhân đôi Chủ đề Max Worker và bạn có cùng số với 1 lõi như bạn làm với 4 lõi không? Phương trình là:512 + ((logical CPUs - 4) * 16)

Đó là một sự xấu hổ, bởi vì khi số lượng lõi tăng lên, tốc độ đồng hồ thường tăng lên một hoặc hai thế hệ.

Nhìn vào bất kỳ dòng chip Intel nào gần đây sẽ cho thấy một xu hướng tương tự.

Làm thế nào để tôi biết tôi cần bao nhiêu chủ đề?

Điều này sẽ phụ thuộc rất nhiều vào:

• Số lượng người dùng
• Số lượng truy vấn song song
• Số lượng truy vấn nối tiếp
• Số lượng cơ sở dữ liệu và đồng bộ hóa dữ liệu (Phản chiếu, AG, sao lưu cho Nhật ký vận chuyển)
• Nếu bạn để MAXDOP và CTFP mặc định

Nếu bạn không chạy ra khỏi chúng ngày hôm nay, có lẽ bạn ổn.

Nhưng làm thế nào để bạn biết nếu bạn là?

Có những câu hỏi hay, và có những câu hỏi hay, và tôi nói cho bạn điều gì đó, đó là một CÂU HỎI TUYỆT VỜI .

THREADPOOL có thể biểu hiện dưới dạng sự cố kết nối và bạn có thể thấy các thông báo trong nhật ký lỗi về việc không thể sinh ra một chuỗi .

Bạn cũng có thể xem số liệu thống kê chờ của máy chủ của mình bằng công cụ miễn phí như sp_Blitz hoặc sp_BlitzFirst (tiết lộ đầy đủ, tôi đóng góp cho dự án này).

EXEC sp_Blitz

EXEC sp_BlitzFirst @SinceStartup = 1

Tôi không thể tăng Chủ đề Công nhân Tối đa?

Tăng MWT có thể dẫn đến tăng SOS_SCHEDULER_YIELDchờ đợi.

Đó không phải là ngày tận thế, nhưng hãy nghĩ về nó giống như thêm một lũ trẻ la hét vào lớp giáo viên.

Thật bất ngờ, mỗi đứa trẻ sẽ khó thu hút sự chú ý hơn.

Khi một quá trình cạn kiệt lượng tử 4ms của nó , có khả năng sẽ có nhiều luồng hơn trước nó chờ đợi để có được trên CPU.

Hiệu suất có thể cảm thấy như nhau.

Làm thế nào tôi có thể sử dụng ít Chủ đề Công nhân hơn?

Bạn độc ác [danh từ] của một [danh từ], đó là những công nhân có gia đình để hỗ trợ! Thế chấp! Ước mơ!

Nhưng không sao, phải tôn trọng điểm mấu chốt. Bạn là ông chủ.

Nơi dễ nhất để bắt đầu là thay đổi cài đặt như MAXDOP và Ngưỡng chi phí cho tính song song từ mặc định.

Nếu bạn có câu hỏi về cách đặt chúng, hãy vào đây:

• Thuật toán cài đặt MAXDOP cho SQL Server

• Tại sao ngưỡng chi phí cho tính song song không nên được đặt thành 5

Sau đó, công việc của bạn trở nên khó khăn hơn rất nhiều. Bạn đã tìm ra những gì sử dụng tất cả các chủ đề. Đôi khi bạn có thể làm điều đó bằng cách nhìn vào số liệu thống kê chờ đợi của bạn.

Cụ thể hơn, nếu bạn có sự chờ đợi cao đối với tính song song ( CXPACKET) VÀ sự chờ đợi cao đối với các khóa ( LCK_), thì bạn có thể đang chạy vào chuỗi chặn dài liên quan đến các truy vấn song song.

Bạn biết những gì hôi thối? Trong khi tất cả các truy vấn song song đó đang chờ để lấy khóa của họ, họ không trả lại các luồng được phân bổ.

Bạn gần như có thể nghe thấy rằng bốn VM lõi mà quản trị viên của bạn đảm bảo rằng bạn đã quá đủ cho bất kỳ khối lượng công việc nào đang thở hổn hển, phải không?

Thật không may, loại truy vấn và điều chỉnh chỉ mục bạn phải làm để giải quyết nội dung đó nằm ngoài phạm vi của câu hỏi.

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

_{Cộng đồng wiki trả lời :}

Cái dài và ngắn của nó là: Hầu hết các khối lượng công việc cho SQL Server là OLTP, được hưởng lợi từ tốc độ xung nhịp cao hơn vì đây là một hoạt động nối tiếp.

Trừ khi bạn đặc biệt thiết kế cho một hệ thống song song ồ ạt, tốc độ đồng hồ sẽ luôn chiến thắng. Trường hợp cạnh tồn tại nhưng đó là 95% câu trả lời thời gian. Thực tế là nó kết thúc với chi phí ít hơn cũng là một điều tốt đẹp.

Câu trả lời cho điều này: nó phụ thuộc vào trường hợp sử dụng của bạn.

• Bạn đang xử lý nhiều yêu cầu nhỏ cùng một lúc hay một vài yêu cầu lớn?
• Là chương trình bạn chạy thậm chí được tối ưu hóa cho đa lõi?

Ví dụ: tôi có một máy tính lõi tứ nhưng trình biên dịch ESP8266 chỉ sử dụng 25% CPU của tôi vì nó chỉ được thiết kế để sử dụng một lõi. Nếu tôi có 1 lõi nhanh thì điều đó sẽ tối ưu hơn.