Trọng tâm chính của trang blog này là hiệu suất trong môi trường SQL Server. Người ta có thể tranh luận rằng hiệu suất bắt đầu từ thiết kế cơ sở dữ liệu và ứng dụng. Nhưng bạn cũng có thể đặt ra một trường hợp rằng việc có sẵn các nguồn lực phù hợp là điều cần thiết để đạt được hiệu suất tốt. Đối với tất cả các cuộc thảo luận về tài nguyên phù hợp (mô hình CPU, bao nhiêu bộ nhớ, loại lưu trữ), đôi khi chúng ta bỏ qua hành động lập kế hoạch dung lượng:sử dụng dữ liệu mà chúng ta có để đưa ra quyết định sáng suốt về những gì chúng tôi cần . Lập kế hoạch dung lượng không chỉ tìm ra dung lượng ổ đĩa chúng ta cần mà còn liên quan đến các tài nguyên mà phiên bản SQL Server phải có sẵn để xử lý khối lượng công việc.
Mới hay Hiện có?
Lập kế hoạch năng lực cho một giải pháp mới thực sự rất khó. Bạn phải đưa ra ước tính về khối lượng công việc dựa trên thông tin bạn thu thập được từ doanh nghiệp. Điều này có nghĩa là bạn phải đặt những câu hỏi khó về lượng dữ liệu mà họ sẽ mong đợi trong tháng đầu tiên, sáu tháng đầu tiên và năm đầu tiên. Khi một giải pháp mới được đưa ra, đây thường là điều CUỐI CÙNG mà doanh nghiệp nghĩ đến, vì vậy bạn thường sẽ nhận được những câu trả lời mơ hồ. Trong trường hợp có một giải pháp mới, bạn thực sự đã nỗ lực phỏng đoán tốt nhất. Đừng vén tóc khi cố gắng đưa ra những con số chính xác.
Nếu giải pháp là từ một nhà cung cấp, bạn phải yêu cầu nhà cung cấp lập kế hoạch đề xuất về cả không gian cần thiết và các nguồn lực cần thiết. Tôi thừa nhận, họ có thể không có dữ liệu đó, nhưng bạn không nhận được những gì bạn không yêu cầu. Không bao giờ đau khi thử.
[Phần thưởng:Nếu nhà cung cấp không có bất kỳ thông tin nào để cung cấp, sẽ không hữu ích nếu, sau khi hệ thống khởi động và chạy trong một vài tháng, bạn gửi cho họ dữ liệu của mình… chẳng hạn như phần cứng bạn có và khối lượng công việc trông như thế nào? Nó không cần phải là một bản viết dài 20 trang, nhưng phản hồi có thể thúc đẩy họ theo hướng chủ động hơn trong tương lai.]
Về giải pháp hiện có, nếu bạn đang gặp vấn đề về hiệu suất hoặc đang tìm cách nâng cấp phần cứng, bạn sẽ muốn nắm bắt thông tin về môi trường hiện tại để lập kế hoạch cho một môi trường mới.
Bộ nhớ
Lập kế hoạch cho số tiền dung lượng lưu trữ cần thiết khá đơn giản, nó chỉ yêu cầu một số kế hoạch trước. Trong các bài viết kiểm tra tình trạng SQL Server chủ động của tôi, tôi thảo luận về việc giám sát dung lượng đĩa và bao gồm một truy vấn để nắm bắt thông tin tệp. Truy vấn này nắm bắt kích thước của các tệp cơ sở dữ liệu cho phiên bản cũng như không gian được sử dụng. Bắt buộc phải tạo xu hướng dữ liệu này theo thời gian và điều đó không có nghĩa là một vài tuần. Bạn đang muốn xem các tệp thay đổi như thế nào qua các tháng, có thể lên đến một đến hai năm, vì các cách sử dụng cho một ứng dụng có thể thay đổi. Thông tin này rất dễ nắm bắt, cần ít dung lượng để lưu trữ và là vô giá để có thể tham khảo khi bạn mua sắm bộ nhớ. Nếu bạn có thể cung cấp dữ liệu định lượng về sự phát triển của hệ thống thì bạn có cơ hội tốt hơn nhiều để có được không gian bạn cần từ trước thay vì phải yêu cầu sau đó. Và khi bạn yêu cầu dung lượng, hãy đảm bảo bao gồm tempdb trong tính toán của bạn.
Tài nguyên phần cứng
CPU
Tối ưu hóa hiệu suất CPU của bạn không chỉ là về số lượng CPU mà bạn có, bạn còn phải xem xét mô hình và khối lượng công việc (ví dụ:kho dữ liệu với các truy vấn song song lớn so với OLTP với các truy vấn nối tiếp). Với thông tin này và một chút trợ giúp từ Glenn, bạn có thể xác định bộ xử lý tốt nhất cho máy chủ của mình. Đừng quên cân nhắc chi phí cấp phép và các giới hạn dựa trên phiên bản SQL Server của bạn!
Bộ nhớ
Bộ nhớ tương đối rẻ và chúng tôi khuyên bạn nên luôn mua dung lượng bộ nhớ tối đa mà máy chủ có thể chứa. Đọc dữ liệu từ bộ nhớ nhanh hơn đáng kể so với đọc từ đĩa, vì vậy càng nhiều dữ liệu phù hợp với bộ nhớ càng tốt. Lưu ý rằng toàn bộ cơ sở dữ liệu không có để phù hợp với bộ nhớ. Bạn chỉ cần tập hợp dữ liệu đang hoạt động để vừa với bộ nhớ. Hãy xem xét một cơ sở dữ liệu 2TB. Ít có khả năng xảy ra trường hợp OLTP, tất cả 2TB đều được truy cập mỗi ngày. Thông thường, chỉ dữ liệu gần đây mới được truy cập - có lẽ chỉ trong 30 hoặc 60 ngày qua. Đó là dữ liệu cần nằm gọn trong bộ nhớ. Nhưng tất nhiên, hiếm khi chúng ta thấy một môi trường OLTP thuần túy, thường đó là một môi trường hỗn hợp vì người dùng thích chạy báo cáo trên các tập hợp dữ liệu lớn và không có kho dữ liệu hoặc bản sao báo cáo của cơ sở dữ liệu nên họ có > để chạy các báo cáo chống lại sản xuất. Điều này làm phức tạp yêu cầu bộ nhớ. Bây giờ, đôi khi bạn cần dữ liệu cũ hơn đó trong bộ nhớ, nhưng đôi khi thì không. Điều quan trọng là phải hiểu khối lượng công việc; những loại truy vấn nào đang thực thi đối với cơ sở dữ liệu?
Nếu bạn đang sử dụng Standard Edition, hãy xác minh rằng bạn có nhiều bộ nhớ trong máy chủ hơn bộ nhớ tối đa được hỗ trợ. Ví dụ:với SQL Server 2014 trở lên, trong Standard Edition, lượng bộ nhớ tối đa mà bạn có thể phân bổ cho vùng đệm (thông qua cài đặt bộ nhớ máy chủ tối đa) là 128GB. Do đó, bạn muốn có thêm bộ nhớ trong máy chủ (ví dụ:160GB) để bạn có thể đặt bộ nhớ máy chủ tối đa ở giá trị cao nhất có thể là 128GB, đồng thời vẫn có bộ nhớ cho HĐH và các quy trình SQL Server khác. Hơn nữa, với SQL Server 2016 SP1 Standard Edition, bạn có thể sử dụng OLTP trong bộ nhớ, với giới hạn 32GB cho mỗi cơ sở dữ liệu. Giá trị này cao hơn giá trị bộ nhớ máy chủ tối đa, vì vậy nếu bạn định sử dụng tính năng này, hãy mua bộ nhớ tương ứng.
Bộ nhớ
Khi chúng ta nói về các yêu cầu hiệu suất đối với lưu trữ, bạn thường nghe mọi người nói về IOPS (hoạt động đầu vào / đầu ra mỗi giây). Trên thực tế, bài viết này được lấy cảm hứng từ câu hỏi của một người xem đã xem khóa học Pluralsight của tôi về Đo điểm chuẩn và đào tạo cơ sở. Câu hỏi là:"Làm thế nào để bạn tương quan các bộ đếm Màn hình hiệu suất cho các lần đọc và ghi mỗi giây với các kết nối của người dùng để ước tính số lượng IO trên mỗi người dùng?" Đọc và ghi mỗi giây là các hoạt động đầu vào / đầu ra, vì vậy, chúng tôi có sẵn dữ liệu này thông qua PerfMon ở cấp phiên bản và đây là những gì bạn sử dụng để xác định các yêu cầu IOPS cho một phiên bản.
Tuy nhiên, nếu bạn biết đọc và viết và kết nối người dùng, sau đó bạn có thể thực hiện một số phép toán và tìm ra IOPS cho mỗi người dùng. Điều này rất hữu ích nếu bạn đang có kế hoạch phát triển giải pháp và thêm nhiều người dùng hơn. Bạn muốn đảm bảo rằng giải pháp sẽ mở rộng quy mô và một tùy chọn bạn có là lấy IOPS được tính toán của bạn cho mỗi người dùng, dựa trên số lượng người dùng X, sau đó ước tính IOPS phiên bản cho Y số người dùng. Bây giờ, chúng tôi đưa ra rất nhiều giả định với phép tính này. Chúng tôi giả định rằng cách các kết nối mới sử dụng hệ thống cũng giống như ngày nay - điều đó cuối cùng có thể xảy ra hoặc không, bạn sẽ không biết cho đến khi có hệ thống. Khi bạn hiểu giá trị này (đọc + ghi / kết nối người dùng =IOPS trung bình trên mỗi người dùng), thì bạn biết cách ước tính IOPS cho một giải pháp dựa trên kết nối người dùng dự kiến.
Sau đó, bạn đưa thông tin này cho nhân viên lưu trữ của mình để thảo luận về các cấu hình tiềm năng có sẵn. Bạn có thể tính toán IOPS tối đa cho cấu hình đĩa, miễn là bạn có thông tin về đĩa (ví dụ:số lượng đĩa, tốc độ, kích thước và cấu hình RAID). Bạn có thể kiểm tra thông lượng IO cho một ổ đĩa bằng CrystalDiskMark, mặc dù điều này có thể không thực hiện được nếu bộ nhớ chưa được quyết định. Tuy nhiên, khi nó đã sẵn sàng, bạn nên thực hiện quá trình kiểm tra này để đảm bảo rằng IOPS cho một ổ đĩa nhất định có thể đáp ứng khối lượng công việc dự kiến.
IOPS chỉ là một cách để xem xét hiệu suất lưu trữ. Hiểu rằng dữ liệu này cho bạn biết mức độ IO đang xảy ra và lý tưởng là nếu bạn biết IOPS và bạn có bộ nhớ đáp ứng các yêu cầu thì độ trễ sẽ là tối thiểu. Tuy nhiên, độ trễ là thứ ảnh hưởng đến hiệu suất. Để xác định độ trễ tồn tại, bạn sẽ cần sử dụng một công cụ như DiskSpd để đánh giá bộ nhớ. Glenn có một bài viết tuyệt vời giải thích cách phân tích hiệu suất IO và sau đó là một bài viết khác về cách sử dụng DiskSpd để kiểm tra nó để hiểu độ trễ. Tôi thực sự khuyên bạn nên xem lại cả hai bài viết nếu trước đây bạn chưa xem xét dung lượng và hiệu suất.
Kết luận
Lập kế hoạch dung lượng không chỉ đơn thuần là biết bạn cần bao nhiêu dung lượng cho các tệp cơ sở dữ liệu. Bạn phải hiểu khối lượng công việc và những gì nó yêu cầu về tài nguyên CPU, bộ nhớ và ổ đĩa. Để làm điều này, bạn cần dữ liệu… có nghĩa là bạn cần nắm bắt các đường cơ sở. Phiên đầu tiên của tôi trong cộng đồng SQL Server là vào tháng 12 năm 2010, và đó là chủ đề về đường cơ sở. Sáu năm sau, tôi vẫn đang nói về tầm quan trọng của chúng và tôi vẫn nhận được phản hồi từ mọi người rằng họ không có những con số này. Nếu bạn muốn lập kế hoạch năng lực thông minh, có mục tiêu, thì bạn cần phải thu thập dữ liệu thích hợp… nếu không, bạn chỉ là phỏng đoán.
