Máy chủ SQL tempdb trên đĩa RAM?

Cơ sở dữ liệu ứng dụng nhà cung cấp của chúng tôi rất chuyên sâu TempDB.

Máy chủ là ảo (VMWare) với 40 lõi và RAM 768GB, chạy SQL 2012 Enterprise SP3.

Tất cả các cơ sở dữ liệu bao gồm TempDB đều có trên SSD Cấp 1 trong SAN. Chúng tôi có 10 tệp dữ liệu tempdb, mỗi tệp được tăng lên 1GB và chúng không bao giờ tự động phát triển. Tương tự với tệp nhật ký 70GB. Cờ Trace 1117 & 1118 đã được thiết lập.

sys.dm_io_virtual_file_stats hiển thị hơn 50 Terabyte đọc / ghi trên dữ liệu và tệp nhật ký tempdb trong tháng qua, với io_stall tích lũy trong 250 giờ hoặc 10 ngày.

Chúng tôi đã điều chỉnh mã và SP của nhà cung cấp trong hơn 2 năm qua.

Bây giờ, chúng tôi đang nghĩ đến việc đặt các tệp tempdb trên RAM Drive vì chúng tôi có rất nhiều bộ nhớ. Vì tempdb bị hủy / tái tạo khi máy chủ được khởi động lại, nên đây là một ứng cử viên lý tưởng để đặt vào bộ nhớ dễ bay hơi cũng bị xóa khi máy chủ được khởi động lại.

Tôi đã thử nghiệm điều này trên môi trường thấp hơn và nó đã dẫn đến thời gian truy vấn nhanh hơn nhưng việc sử dụng CPU tăng lên, vì CPU đang làm việc nhiều hơn thay vì chờ đợi trên ổ đĩa tempdb chậm.

Có ai khác đặt tempdb của họ trên RAM trong các hệ thống sản xuất oltp cao không? Có bất lợi lớn? Có bất kỳ nhà cung cấp để lựa chọn cụ thể hoặc tránh?

Đầu tiên, vá lỗi: đảm bảo bạn đang ở trên Gói dịch vụ 2012 Cập nhật tích lũy 10 hoặc mới hơn. Trong SQL 2014, Microsoft đã thay đổi TempDB để bớt háo hức ghi vào đĩa và họ đã đưa nó vào phiên bản 2012 SP1 CU10 một cách khủng khiếp , do đó có thể giảm bớt rất nhiều áp lực ghi TempDB.

Thứ hai, có được con số chính xác về độ trễ của bạn. Kiểm tra sys.dm_io_virtual_file_stats để xem gian hàng ghi trung bình cho các tệp TempDB của bạn. Cách yêu thích của tôi để làm điều này là:

sp_BlitzFirst @ExpertMode = 1, @Seconds = 30 /* Checks for 30 seconds */
sp_BlitzFirst @SinceStartup = 1 /* Shows data since startup, but includes overnights */

Nhìn vào phần thống kê tập tin và tập trung vào ghi vật lý. Dữ liệu BecauseStartup có thể gây hiểu nhầm đôi chút vì nó cũng bao gồm cả thời gian khi CHECKDB đang chạy và điều đó thực sự có thể làm hỏng TempDB của bạn.

Nếu độ trễ ghi trung bình của bạn là hơn 3ms, thì có, bạn có thể có bộ nhớ trạng thái rắn trong SAN của mình, nhưng nó vẫn không nhanh.

Trước tiên hãy xem xét SSD cục bộ cho TempDB. Các ổ SSD cục bộ tốt (như thẻ PCIe NVMe của Intel, có giá dưới 2 nghìn USD, đặc biệt là ở các kích cỡ bạn mô tả) có độ trễ cực thấp, thấp hơn mức bạn có thể đạt được với bộ nhớ chia sẻ. Tuy nhiên, trong điều kiện ảo hóa, điều này đi kèm với một nhược điểm: bạn không thể vMotion khách từ máy chủ này sang máy chủ khác để phản ứng với tải hoặc với các vấn đề phần cứng.

Hãy xem xét một ổ đĩa RAM cuối cùng. Có hai vấn đề lớn với cách tiếp cận này:

Đầu tiên, nếu bạn thực sự có hoạt động ghi TempDB nặng, tốc độ thay đổi trên bộ nhớ có thể cao đến mức bạn sẽ không thể vMotion khách từ máy chủ này sang máy chủ khác mà không ai nhận ra. Trong vMotion, bạn phải sao chép nội dung của RAM từ máy chủ này sang máy chủ khác. Nếu nó thực sự thay đổi nhanh, nhanh hơn bạn có thể sao chép nó qua mạng vMotion của mình, bạn có thể gặp sự cố (đặc biệt là nếu hộp này có liên quan đến phản chiếu, AG hoặc cụm chuyển đổi dự phòng.)

Thứ hai, ổ đĩa RAM là phần mềm. Trong thử nghiệm tải mà tôi đã thực hiện, tôi chưa bao giờ ấn tượng với tốc độ của chúng trong hoạt động TempDB thực sự nặng nề. Nếu nó quá nặng đến nỗi ổ SSD cấp doanh nghiệp không thể theo kịp, thì bạn cũng sẽ đánh thuế phần mềm ổ đĩa RAM. Bạn thực sự muốn tải thử nghiệm này thật nhiều trước khi phát hành trực tuyến - hãy thử những thứ như nhiều bản dựng lại chỉ mục đồng thời trên các chỉ mục khác nhau, tất cả đều sử dụng sort-in-tempdb.

Tạo một ổ đĩa RAM là chuyện nhỏ. Nhiều ổ đĩa Linux và ổ đĩa quang có khả năng khởi động tạo ra một ổ đĩa RAM và lưu trữ các tệp hệ điều hành ở đó. Hệ thống tập tin gốc là trong bộ nhớ. Trong các cửa sổ, vào ban ngày, một ổ đĩa RAM đã được tải dưới dạng trình điều khiển thiết bị trong config.sys. Thông thường trình điều khiển đã được tải trong bộ nhớ cao. Theo tôi, đây là một giải pháp rất tốt và đơn giản. Nếu đã tạo ra giải pháp của bạn bằng cách sử dụng ổ đĩa RAM, tôi muốn nghe về nó. Tôi muốn làm một cái gì đó tương tự nhưng muốn ghi vào bộ nhớ vĩnh viễn và lưu trữ một db trong RAM. Trong trường hợp của tôi, chúng tôi có các máy có thể cài đặt nhiều RAM hơn hệ điều hành có thể sử dụng. Tạo đĩa RAM trước khi tải HĐH sẽ cho phép sử dụng RAM mà HĐH sẽ không thấy khác.