DTU là cái quái gì?

Tác giả:Andy Mallon (@AMtwo)

Không, nghiêm túc đấy. DTU là gì?

Khi bạn đang triển khai bất kỳ ứng dụng nào, một trong những câu hỏi đầu tiên xuất hiện là "Cái này sẽ tốn bao nhiêu?" Hầu hết chúng ta đã trải qua loại bài tập này để xác định kích thước cài đặt SQL Server tại một số điểm, nhưng nếu bạn đang triển khai lên đám mây thì sao? Với việc triển khai Azure IaaS, không có nhiều thay đổi – bạn vẫn đang xây dựng một máy chủ dựa trên số lượng CPU, một số bộ nhớ và định cấu hình bộ nhớ để cung cấp cho bạn đủ IOPS cho khối lượng công việc của bạn. Tuy nhiên, khi bạn chuyển sang PaaS, Cơ sở dữ liệu Azure SQL có kích thước với các cấp dịch vụ khác nhau, nơi hiệu suất được đo bằng DTU. DTU là cái quái gì?

Tôi biết BTU là gì. Có lẽ DTU là viết tắt của Database Thermal Unit? Đó có phải là lượng công suất xử lý cần thiết để tăng nhiệt độ của trung tâm dữ liệu lên một độ không? Thay vì phỏng đoán, hãy kiểm tra tài liệu và xem Microsoft phải nói gì:

OK, đó là dự đoán thứ hai của tôi - nhưng "biện pháp kết hợp" là gì? Làm cách nào để dịch những gì tôi biết về định cỡ máy chủ thành định cỡ Cơ sở dữ liệu Azure SQL? Thật không may, không có cách nào đơn giản để chuyển "2 lõi CPU và bộ nhớ 4GB" thành phép đo DTU.

Không có Máy tính DTU phải không?

Đúng! Microsoft cung cấp cho chúng tôi một Máy tính DTU để ước tính cấp dịch vụ thích hợp của Cơ sở dữ liệu SQL Azure. Để sử dụng nó, bạn tải xuống và chạy tập lệnh PowerShell (sql-perfmon.ps1) trên máy chủ trong khi chạy khối lượng công việc trong SQL Server. Tập lệnh xuất ra một CSV chứa bốn bộ đếm hiệu suất:(1) tổng thời gian xử lý%, (2) tổng số lần đọc đĩa / giây, (3) tổng số đĩa ghi mỗi giây và (4) tổng số byte nhật ký được xả / giây. Đầu ra CSV này sau đó được tải lên Máy tính DTU, công cụ này ước tính cấp dịch vụ nào sẽ đáp ứng tốt nhất nhu cầu của bạn. Dữ liệu duy nhất mà Máy tính DTU lấy ngoài CSV là số lõi CPU trên máy chủ đã tạo tệp. Máy tính DTU vẫn còn là một hộp đen - không dễ dàng để ánh xạ những gì chúng ta biết từ cơ sở dữ liệu tại chỗ vào Azure.

Tôi muốn chỉ ra rằng định nghĩa của DTU là nó là "thước đo kết hợp giữa CPU, bộ nhớ và dữ liệu I / O và I / O nhật ký giao dịch… "Không có bộ đếm hiệu quả nào được Máy tính DTU sử dụng tính đến bộ nhớ, nhưng nó được liệt kê rõ ràng trong định nghĩa là một phần của phép tính. Điều này không nhất thiết phải vấn đề, nhưng đó là bằng chứng cho thấy Máy tính DTU sẽ không hoàn hảo.

Tôi sẽ tải một số tải tổng hợp vào Máy tính DTU và xem liệu tôi có thể tìm ra cách hoạt động của hộp đen đó không. Trên thực tế, tôi sẽ chế tạo hoàn toàn các CSV để tôi có thể hoàn toàn kiểm soát các số hiệu quả mà chúng tôi tải vào Máy tính DTU. Hãy xem xét từng chỉ số một. Đối với mỗi chỉ số, chúng tôi sẽ tải lên dữ liệu được tạo có giá trị 25 phút (1500 giây – tôi thích số tròn) và xem cách dữ liệu thông thường đó được chuyển đổi thành DTU.

CPU

Tôi sẽ tạo một CSV mô phỏng một máy chủ 16 lõi, từ từ tăng tốc độ sử dụng CPU cho đến khi nó được chốt ở mức 100%. Vì tôi sẽ mô phỏng quá trình tăng trên máy chủ 16 lõi, nên tôi sẽ tạo CSV của mình để tăng 1/16 một lúc – về cơ bản là mô phỏng một lõi đạt mức tối đa, sau đó tăng tối đa lần thứ hai, rồi đến lần thứ ba, v.v ... Trong khi đó, CSV sẽ không hiển thị lần đọc, ghi và ghi nhật ký. Một máy chủ sẽ không bao giờ thực sự tạo ra một khối lượng công việc như thế này – nhưng đó chính là vấn đề. Tôi đang cách ly hoàn toàn việc sử dụng CPU để có thể xem cách CPU ảnh hưởng đến DTU.

Tôi sẽ tạo tệp CSV có một hàng mỗi giây và cứ sau 94 giây, tôi sẽ tăng bộ đếm thời gian Tổng% bộ xử lý lên ~ 6%. Ba quầy còn lại sẽ bằng 0 trong mọi trường hợp. Bây giờ, tôi tải tệp này lên Máy tính DTU (và yêu cầu Máy tính DTU xem xét 16 lõi) và đây là kết quả đầu ra:

Đợi đã? Tôi đã không tăng cường sử dụng CPU trong 16 bước chẵn sao? Biểu đồ DTU này chỉ hiển thị năm bước. Chắc tôi đã làm rối tung lên. Không - CSV của tôi có 16 bước chẵn, nhưng điều đó (dường như) không chuyển đều thành DTU. Ít nhất là không theo Máy tính DTU. Dựa trên kiểm tra CPU tối đa của chúng tôi, ánh xạ CPU-DTU-to-Service Tier của chúng tôi sẽ trông giống như sau:

Nhìn vào dữ liệu này cho chúng ta biết một số điều:

1. Một lõi CPU, 100% sử dụng tương đương với 100 DTU.
2. DTU tăng kinda tuyến tính khi CPU tăng lên, nhưng dường như phù hợp và tăng vọt.
3. Các cấp dịch vụ Cơ bản và Tiêu chuẩn bằng với ít hơn một lõi CPU.
4. Bất kỳ máy chủ Đa lõi nào cũng sẽ dịch sang một số kích thước trong Bậc dịch vụ cao cấp.

Bài đọc

Lần này, tôi sẽ sử dụng cùng một phương pháp. Tôi sẽ tạo một CSV với số lượng ngày càng tăng cho bộ đếm lần đọc / giây, với các bộ đếm hiệu suất khác ở mức 0. Tôi sẽ từ từ tăng số lượng theo thời gian. Lần này, hãy bước lên theo phần 2000, cứ sau 100 giây, cho đến khi chúng ta đạt 30000. Điều này mang lại cho chúng ta tổng thời gian 25 phút như nhau – tuy nhiên, lần này tôi có 15 bước thay vì 16 (Tôi thích số tròn).

Khi chúng tôi tải CSV này lên máy tính DTU, nó sẽ cung cấp cho chúng tôi biểu đồ DTU:

Chờ một chút… trông khá giống với biểu đồ đầu tiên. Một lần nữa, nó tăng lên 5 bước không đồng đều, mặc dù tôi đã có 15 bước chẵn trong tệp của mình. Hãy xem nó ở định dạng bảng:

Một lần nữa, chúng ta thấy rằng các tầng Cơ bản &Chuẩn bị tăng lên khá nhanh (ít hơn 2000 lần đọc / giây), nhưng sau đó, tầng Cao cấp khá rộng, trải dài từ 2000 đến 30000 lần đọc mỗi giây. Trong bảng trên, "Số lần đọc / giây" có thể được coi là "IOPS" ... Hoặc, về mặt kỹ thuật, chỉ là "OPS" vì không có lần ghi nào để tạo thành phần "đầu vào" của IOPS.

Đã viết

Nếu chúng tôi tạo CSV sử dụng cùng một công thức mà chúng tôi đã sử dụng cho Số lần đọc và tải CSV đó lên Máy tính DTU, chúng tôi sẽ nhận được một biểu đồ giống với biểu đồ cho Số lần đọc:

IOPS là IOPS, vì vậy cho dù đó là đọc hay ghi, có vẻ như phép tính DTU coi nó như nhau. Tất cả những gì chúng ta biết (hoặc nghĩ rằng chúng ta biết) về những lần đọc dường như áp dụng như nhau đối với những bài viết.

Số byte nhật ký bị xóa

Chúng tôi đang tính đến bộ đếm perfmon cuối cùng:số byte log được tuôn ra mỗi giây. Đây là một biện pháp khác của IO, nhưng dành riêng cho nhật ký giao dịch SQL Server. Trong trường hợp bây giờ bạn vẫn chưa nắm bắt được, tôi đang tạo các CSV này để các giá trị cao sẽ được tính dưới dạng P15 Azure DB, sau đó chỉ cần chia giá trị để chia nó thành các bước chẵn. Lần này, chúng ta sẽ tăng từ 5 triệu lên 75 triệu, trong các bước là 5 triệu. Như chúng tôi đã làm trong tất cả các thử nghiệm trước đó, các bộ đếm perfmon khác sẽ bằng không. Vì bộ đếm lưu lượng này tính bằng byte mỗi giây và chúng tôi đo bằng hàng triệu, chúng tôi có thể nghĩ về điều này trong đơn vị mà chúng tôi cảm thấy thoải mái hơn:Megabyte mỗi giây.

Chúng tôi tải CSV này lên máy tính DTU và chúng tôi nhận được biểu đồ sau:

Hình dạng của biểu đồ này đang trở nên khá dễ đoán. Ngoại trừ lần này, chúng tôi bước qua các tầng nhanh hơn một chút, đạt P15 chỉ sau 8 bước (so với 11 đối với IO và 12 đối với CPU). Điều này có thể khiến bạn nghĩ, "Đây sẽ là nút thắt cổ chai hẹp nhất của tôi!" nhưng tôi không chắc về điều đó. Tần suất bạn tạo 75 MB nhật ký trong một giây ? Đó là 4,5GB mỗi phút . Đó là rất nhiều hoạt động cơ sở dữ liệu. Khối lượng công việc tổng hợp của tôi không nhất thiết phải là khối lượng công việc thực tế.

Kết hợp mọi thứ

OK, bây giờ chúng ta đã thấy một số giới hạn trên bị tách biệt ở đâu, tôi sẽ kết hợp dữ liệu và xem chúng so sánh như thế nào khi CPU, I / O và IO trong nhật ký giao dịch đều diễn ra cùng một lúc – sau tất cả , đó không phải là cách mọi thứ thực sự xảy ra sao?

Để tạo CSV này, tôi chỉ cần lấy các giá trị hiện có mà chúng tôi đã sử dụng cho từng thử nghiệm riêng lẻ ở trên và kết hợp các giá trị đó thành một CSV duy nhất, tạo ra biểu đồ đáng yêu này:

Nó cũng mang lại thông báo:

Nếu bạn nhìn vào trục Y, bạn sẽ thấy chúng tôi đạt "1.000 nghìn" (tức là 1 triệu) DTU ở mốc 1200 giây. Điều đó có vẻ… uhh… sai? Nếu chúng ta nhìn vào các bài kiểm tra ở trên, thì mốc 1200 giây là khi tất cả 4 chỉ số riêng lẻ đạt mức 4000 DTU, P15. Có lý rằng chúng tôi sẽ ở ngoài phạm vi, nhưng hình dạng của biểu đồ không hoàn toàn hợp lý đối với tôi – Tôi nghĩ máy tính DTU vừa giơ tay lên và nói, "Sao cũng được, Andy. Nó rất nhiều. Nó quá nhiều. Đó là baji tỷ DTU. Khối lượng công việc này không phù hợp với Cơ sở dữ liệu Azure SQL. "

OK, vậy điều gì xảy ra trước đây mốc 1200 giây? Hãy cắt CSV và gửi lại cho máy tính chỉ trong 1200 giây đầu tiên. Các giá trị tối đa cho mỗi cột là:81% CPU (hoặc apx 13 lõi ở mức 100%), 24000 lần đọc / giây, 24000 lần ghi / giây và 60MB nhật ký xả / giây.

Xin chào, người bạn cũ… Hình dáng quen thuộc đó đã trở lại một lần nữa. Đây là bản tóm tắt dữ liệu từ CSV và những gì Máy tính DTU ước tính cho tổng Mức sử dụng DTU và cấp dịch vụ.

Bây giờ, hãy xem các tính toán DTU riêng lẻ (khi chúng tôi đánh giá riêng lẻ) so với các tính toán DTU từ lần kiểm tra gần đây nhất này:

Bạn sẽ nhận thấy rằng tính toán DTU không đơn giản như cộng các DTU riêng biệt của bạn. Như định nghĩa mà tôi đã trích dẫn ở phần đầu, nó là "thước đo kết hợp" của các chỉ số riêng biệt đó. Công thức được sử dụng để "trộn" rất phức tạp và chúng tôi thực sự không có công thức đó. Những gì chúng ta có thể thấy là ước tính của Máy tính DTU thấp hơn so với tổng của các phép tính DTU riêng biệt.

Ánh xạ DTU với phần cứng truyền thống

Hãy lấy dữ liệu từ Máy tính DTU và cố gắng tập hợp một số phỏng đoán về cách phần cứng truyền thống có thể ánh xạ tới một số lớp Cơ sở dữ liệu Azure SQL.

Trước tiên, hãy giả sử rằng "read / sec" và "write / sec" dịch trực tiếp sang IOPS mà không cần bản dịch. Thứ hai, giả sử rằng việc thêm hai bộ đếm này sẽ cung cấp cho chúng ta tổng số IOPS của chúng ta. Thứ ba, hãy thừa nhận rằng chúng tôi không biết việc sử dụng bộ nhớ là gì, và chúng tôi không có cách nào để đưa ra bất kỳ kết luận nào về mặt đó.

Trong khi ước tính thông số kỹ thuật phần cứng, tôi cũng sẽ chọn kích thước Azure VM có thể phù hợp với từng cấu hình phần cứng. Có nhiều kích thước Azure VM tương tự, mỗi kích thước được tối ưu hóa cho các số liệu hiệu suất khác nhau, nhưng tôi đã tiếp tục và giới hạn các lựa chọn của mình cho A-Series và DSv2-Series.

Bậc cơ bản cực kỳ hạn chế. Nó tốt cho việc sử dụng không thường xuyên / bình thường và là một cách rẻ tiền để "đậu" cơ sở dữ liệu của bạn khi bạn không sử dụng nó. Nhưng nếu bạn đang chạy bất kỳ ứng dụng thực nào, thì Cấp cơ bản sẽ không phù hợp với bạn.

Bậc Tiêu chuẩn cũng khá hạn chế, nhưng đối với các ứng dụng nhỏ, nó có khả năng đáp ứng nhu cầu của bạn. Nếu bạn có một máy chủ 2 lõi đang chạy một số ít cơ sở dữ liệu, thì các cơ sở dữ liệu đó riêng lẻ có thể phù hợp với lớp Tiêu chuẩn. Tương tự như vậy, nếu bạn có một máy chủ chỉ có một cơ sở dữ liệu, chạy 1 lõi CPU ở mức 100% (hoặc 2 lõi đang chạy ở mức 50%), thì có lẽ nó chỉ đủ mã lực để nâng quy mô vào cấp dịch vụ Premium-P1.

Nếu bạn đang sử dụng một máy chủ đa lõi trong cơ sở (hoặc IaaS), thì bạn sẽ tìm kiếm trong lớp dịch vụ Cao cấp trên Cơ sở dữ liệu Azure SQL. Vấn đề chỉ là xác định bạn cần bao nhiêu mã lực CPU &I / O cho khối lượng công việc của mình. Máy chủ 2 lõi, 4GB của bạn có thể đưa bạn đến đâu đó xung quanh Cơ sở dữ liệu SQL Azure P6. Trong khối lượng công việc thuần túy của CPU (không có I / O), cơ sở dữ liệu P15 có thể xử lý 16 lõi xử lý, nhưng khi bạn thêm IO vào hỗn hợp, bất kỳ thứ gì lớn hơn ~ 12 lõi sẽ không phù hợp với Cơ sở dữ liệu Azure SQL.

Lần tới, tôi sẽ thực hiện một số khối lượng công việc thực tế và so sánh hiệu suất giữa các cấp dịch vụ. Các ước tính của Máy tính DTU có chính xác không? Chúng tôi sẽ tìm hiểu.

Giới thiệu về tác giả