Trong phần tiếp theo của loạt bài 'điều chỉnh hiệu suất đầu gối' của tôi, tôi muốn thảo luận về Đĩa trạng thái rắn (SSD) và một số vấn đề tôi gặp phải khi sử dụng chúng trong môi trường Máy chủ SQL. Để có mô tả chuyên sâu về SSD, hãy xem bài viết này trên Wikipedia.
SSD có tác dụng gì đối với hiệu suất máy chủ SQL?
SSD không có bất kỳ bộ phận chuyển động nào nên khi đọc hoặc ghi xảy ra, hầu như không có độ trễ I / O. Độ trễ trong một ổ quay đến từ hai nguyên nhân:
- Di chuyển đầu đĩa đến đúng rãnh trên bề mặt đĩa (được gọi là thời gian tìm kiếm)
- Đang đợi đĩa quay đến đúng điểm trên bản nhạc (được gọi là độ trễ quay)
Điều này có nghĩa là SSD mang lại hiệu suất tăng đáng kể khi có sự cố I / O.
Thật đơn giản.
Có một chút phức tạp đáng nói nhưng nằm ngoài phạm vi của bài viết này để đi sâu vào:hiệu suất SSD có thể bắt đầu giảm khi ổ đĩa thực sự đầy (được điều tra và giải thích chi tiết trong bài viết này từ AnandTech). Cũng có thể có một số bộ nhớ hệ thống cần thiết cho trình điều khiển SSD để giúp cân bằng độ mòn (kéo dài tuổi thọ của các ô NAND trong SSD) và điều đó sẽ thay đổi tùy theo nhà cung cấp. Vậy là đủ - quay lại nội dung SQL Server.
Tránh những lời khuyên xấu từ Internet
Có hai lời khuyên rất tồi mà tôi thấy trên Internet về SQL Server và SSD.
Đầu tiên là về những gì nên đặt trên SSD, trong đó lời khuyên là luôn đặt tempdb và nhật ký giao dịch của bạn trên SSD. Thoạt nghe, điều này có vẻ là một lời khuyên tốt, vì nhật ký giao dịch và tempdb thường là những nút thắt cổ chai trong hệ thống.
Nhưng nếu không thì sao?
Khối lượng công việc của bạn có thể hầu như chỉ được đọc, trong trường hợp đó, nhật ký giao dịch có thể sẽ không phải là nút thắt cổ chai khối lượng công việc và do đó, việc đặt nó vào ổ SSD có thể gây lãng phí một ổ SSD đắt tiền.
Tempdb của bạn có thể không được sử dụng nhiều bởi khối lượng công việc của bạn, vì vậy việc đặt nó trên SSD có thể gây lãng phí một SSD đắt tiền.
Khi đang xem xét phần nào của môi trường SQL Server sẽ chuyển sang SSD, bạn muốn điều tra xem vị trí của các nút thắt cổ chai I / O. Điều này có thể được thực hiện rất dễ dàng bằng cách sử dụng mã mà tôi đã đăng vào tuần trước sử dụng sys.dm_io_virtual_file_stats DMV để cung cấp ảnh chụp nhanh về độ trễ I / O cho tất cả các tệp trong tất cả cơ sở dữ liệu trên phiên bản. Để hiểu các con số về độ trễ của bạn và so sánh chúng với các giá trị tốt / xấu, hãy đọc qua bài đăng dài này mà tôi đã làm cụ thể về độ trễ I / O của nhật ký giao dịch và tempdb.
Và sau đó, ngay cả khi bạn có độ trễ cao, đừng vội vàng và nghĩ rằng giải pháp duy nhất là di chuyển (các) tệp hoạt động kém sang SSD:
- Đối với độ trễ đọc tệp dữ liệu, hãy điều tra lý do tại sao có quá nhiều lần đọc xảy ra. Tôi đề cập đến vấn đề đó ở đây.
- Đối với độ trễ ghi tệp nhật ký, hãy xem xét tất cả các cách để điều chỉnh hiệu suất của nhật ký và những gì đang được ghi. Tôi trình bày nội dung đó tại đây, tại đây và tại đây.
Trường hợp xấu nhất có thể xảy ra là khi bạn được cung cấp một loạt ổ SSD, hãy làm theo lời khuyên trên Internet để chuyển tempdb và các tệp nhật ký của bạn sang chúng, sau đó không tăng hiệu suất khối lượng công việc. Điều đó sẽ không khuyến khích ban quản lý của bạn cung cấp cho bạn những ổ SSD đắt tiền hơn.
Lời khuyên hữu ích thứ hai là về phân mảnh chỉ mục, trong đó lời khuyên là vì SSD rất nhanh, bạn không cần phải lo lắng về phân mảnh chỉ mục khi sử dụng SSD.
Thật vớ vẩn!
Có ba cách để tôi bác bỏ lời khuyên tồi tệ đó:
- SSD không có cách nào ngăn chặn được nguyên nhân gây phân mảnh chỉ mục:chia trang khỏi các trang cần dung lượng trống để chèn ngẫu nhiên hoặc tăng kích thước hàng. Việc tách trang sẽ tạo ra cùng một lượng nhật ký giao dịch, sử dụng tài nguyên và chuỗi tiềm năng chờ đợi bất kể nơi lưu trữ tệp dữ liệu / nhật ký.
- Phân mảnh chỉ mục bao gồm việc có nhiều trang dữ liệu / chỉ mục với mật độ trang thấp (tức là nhiều không gian trống, trống). Bạn có thực sự muốn ổ SSD đắt tiền của mình lưu trữ nhiều không gian trống không? SSD hoàn toàn không giúp ích gì ở đây.
- Đồng nghiệp của tôi Jonathan Kehayias đã thực hiện một cuộc điều tra chuyên sâu, sử dụng Sự kiện mở rộng, về các mẫu I / O xung quanh phân mảnh chỉ mục cụ thể để giải quyết lời khuyên tồi tệ này và nhận thấy rằng vẫn có tác động về hiệu suất do phân mảnh chỉ mục khi sử dụng SSD. Bạn có thể đọc bài đăng dài của anh ấy tại đây.
Điều duy nhất mà SSD thực hiện đối với việc phân mảnh chỉ mục là làm cho quá trình đọc diễn ra nhanh hơn, do đó, việc quét phạm vi chỉ mục sẽ ít bị phạt hơn khi có hiện tượng phân mảnh chỉ mục, nhưng điểm 3 ở trên cho thấy vẫn có một hình phạt.
SSD không thay đổi cách bạn xử lý và / hoặc ngăn phân mảnh chỉ mục trong môi trường SQL Server của bạn.
Đảm bảo Bảo vệ Dữ liệu của Bạn
Một trong những tội lỗi lớn nhất mà tôi thấy mọi người phạm phải khi sử dụng SSD là chỉ sử dụng một trong số chúng. Chỉ với một ổ đĩa, bạn đang sử dụng mức RAID nào? Số không. RAID-0 hoàn toàn không cung cấp dự phòng.
Nếu bạn định sử dụng SSD, thì bạn cần sử dụng ít nhất hai ổ, trong cấu hình RAID-1 (phản chiếu). Không có lý do gì để tăng hiệu suất nếu bạn đang hy sinh tính khả dụng của hệ thống để đánh đổi.
Một trở lại mà tôi đôi khi gặp phải khi sử dụng ít nhất hai ổ SSD là thẻ SSD cung cấp hai ổ cho Windows và vì vậy chắc chắn việc tạo một ổ đĩa được sao chép Windows trên hai ổ cũng giống như RAID-1 trên hai ổ SSD riêng biệt?
Không, không phải vậy. Nó vẫn là một ổ SSD vật lý, không có ổ dự phòng. Bạn đã bao giờ thấy một nửa thẻ SSD bị lỗi chưa? Không, tôi cũng vậy.
Điểm trở lại khác mà tôi nhận được là chúng là ổ SSD, không phải ổ quay, vì vậy sẽ không hỏng. Sai rồi. SSD có thể và không thành công giống như ổ đĩa quay. Cá nhân tôi đã thấy hai ổ SSD cấp doanh nghiệp bị lỗi trong quá trình thử nghiệm trong môi trường phòng thí nghiệm của chúng tôi. Theo bài viết này trên StorageReview.com, SSD cấp tiêu dùng có MTBF là 2 triệu giờ so với 1,5 triệu giờ đối với ổ quay cấp tiêu dùng và tôi mong đợi kết quả tương tự đối với ổ đĩa cấp doanh nghiệp, nhưng SSD thì không thành công.
Tóm tắt
Đừng rơi vào bẫy khi nghĩ rằng bất cứ thứ gì bạn đặt trên SSD đều có nghĩa là bạn sẽ nhận được sự gia tăng về hiệu suất - bạn phải chọn và chọn cẩn thận. Và đừng tin những điều vô nghĩa ngoài kia về việc bỏ qua phân mảnh chỉ mục khi sử dụng SSD.
SSD là một cách rất hữu ích để tăng hiệu suất, nhưng đối với chi phí của chúng, bạn muốn đảm bảo rằng bạn đang tối đa hóa lợi tức đầu tư của công ty bằng cách sử dụng chúng một cách chính xác và chỉ khi thích hợp.
Trong phần tiếp theo của loạt bài này, tôi sẽ thảo luận về một nguyên nhân phổ biến khác của việc điều chỉnh hiệu suất giật đầu gối. Cho đến lúc đó, chúc bạn khắc phục sự cố!
