Gần đây chúng tôi đã tách các tệp tempdb của chúng tôi sang một ổ SSD mới và đã bắt đầu thấy:

5348 lần xuất hiện của các yêu cầu I / O mất hơn 15 giây để hoàn thành trên tệp [T: \ tempdb \ tempdb4.ndf].

Chúng tôi có nhiều lần xuất hiện lỗi này. Chúng tôi không thấy lỗi khi tempdb trở lại trang chủ RAID 5 ban đầu. Tôi đã làm theo một hướng dẫn về SQLIO và tôi nghĩ rằng SSD nên nhanh hơn nhiều, khi thực hiện đọc / ghi ngẫu nhiên 8kb, so với các đĩa RAID 5 trước đó. Vậy tại sao chúng ta lại thấy những lỗi này?

Ngoài ra, bằng cách chứng minh thêm rằng không phải tất cả đều ổn, tệp bó chúng tôi chạy qua đêm (đó là khi các lỗi này xảy ra) mất 7 giờ. Phải mất 6,25 giờ trên các đĩa cũ.

Các đĩa ngồi trong một mảng gắn trực tiếp. RAID5 cho dữ liệu, RAID 10 cho nhật ký và khe cắm dự phòng mà chúng tôi đã sử dụng cho SSD. RAID 5 và SSD được định dạng cho kích thước khối 64kb. Nhật ký được đặt không chính xác thành kích thước khối 4KB (tôi biết - sẽ sửa khi tôi có cơ hội).

Đây là kết quả của SQLIO:

Ổ đĩa T (ssd)
Ios = 8KB ghi ngẫu nhiên, IOs / giây = 31847,48, MBs / giây = 248,8
Ios = 8KB đọc ngẫu nhiên, IOs / giây = 76391.66, MBs / giây = 596.8

Ổ đĩa S (RAID 5)
Ios = 8KB ghi ngẫu nhiên, IOs / giây = 2601.3, MBs / giây = 20.32
Ios = 8KB đọc ngẫu nhiên, IOs / giây = 3138,45, MBs / giây = 24,51

Đối với 64K đọc / ghi tuần tự, chúng giống nhau.

Tempdb được chia thành 4 tệp 1.5Gb (điều này giống nhau trước và sau khi di chuyển).

Máy chủ SQL 2012 được vá vào SP3.

Bạn có biết điều gì có thể gây ra tất cả các lỗi I / O này được SQL Server báo cáo không?

Nó có thể là một vấn đề trình điều khiển Array hoặc HBA? Liệu một đĩa đơn được thêm vào một khe dự phòng trên một mảng được gắn trực tiếp có cần cấu hình cẩn thận về bộ đệm không?

Tôi thực sự khuyên bạn nên kiểm tra ổ đĩa T: \ mới của mình bằng Crystal Disk Mark. Kiểm tra hướng dẫn từ Brent Ozar tại đây:

Cách kiểm tra dung lượng của bạn với CrystalDiskMark

So sánh kết quả từ ổ đĩa T: \ với

• đĩa RAID 5 cũ (nơi sử dụng tempdb)
• máy của bạn

Nếu SSD chậm hơn hai thiết bị kia và không có gì thay đổi * trong thiết lập của bạn, có thể có vấn đề với chính đĩa hoặc trình điều khiển đang được sử dụng hoặc bộ điều khiển cho mảng mà đĩa này nằm trong, Vân vân.

* những thứ có thể đã thay đổi kể từ khi bạn di chuyển tempdb:

• số lượng tệp tempdb cho cơ sở dữ liệu tăng hoặc giảm (có người nói "này, tại sao không, vì chúng tôi phải khởi động lại cơ sở dữ liệu để di chuyển tempdb")
• các nhiệm vụ bảo trì đã được sắp xếp lại để trùng với công việc hàng đêm chậm chạp (đặc biệt là những công việc có khả năng tấn công tempdb khó khăn, như xây dựng lại chỉ mục hoặc checkdb)
• cửa sổ bảo trì để di chuyển tempdb cũng được sử dụng để triển khai mã mới (có lẽ là cho công việc hàng đêm) khiến việc sử dụng các bảng tạm thời nặng hơn hoặc có các truy vấn với sự cố tràn, v.v.

Bước tiếp theo

Vì có vẻ như đĩa rất nhanh (theo điểm chuẩn bạn đã chia sẻ), tôi nghĩ sẽ là một ý tưởng tốt để ghi lại nội dung của sys.dm_io_virtual_file_statstrước và sau công việc hàng đêm mà bạn đã đề cập. Điều này sẽ cho bạn biết bao nhiêu I / O đang xảy ra trên tempdb trong quá trình đó. Điều này rất quan trọng, vì có thể thực sự có nhiều I / O hơn đĩa có thể xử lý. Vì vậy, đây là những gì bạn làm:

1. Chạy truy vấn này ngay trước khi công việc hàng đêm của bạn được lên lịch để chạy:

   select * 
   from sys.dm_io_virtual_file_stats((select DB_ID('tempdb')), default);

2. Lưu kết quả ở đâu đó (như Excel hoặc một cái gì đó - có thể không có trong tempdb: P)

3. Đợi 7 giờ (cho đến khi công việc kết thúc)
4. Chạy cùng một truy vấn và lưu kết quả
5. Chỉnh sửa câu hỏi của bạn để bao gồm các kết quả

Sau đó chúng ta có thể lấy sự khác biệt của hai ảnh chụp nhanh và xác định có bao nhiêu byte được đọc / ghi trong công việc. Bạn cũng có thể sử dụng những con số đó để tính độ trễ tổng thể trong khoảng thời gian đó.

Lưu ý: một cách tiếp cận chi tiết hơn sẽ là ghi nhật ký kết quả của truy vấn đó vào bảng cứ sau 5 phút (hoặc ít hơn nếu bạn muốn)

Vấn đề này bây giờ dường như được giải quyết.

Tôi đã nêu vấn đề với nhóm SAN của chúng tôi và họ xác nhận rằng bộ nhớ đệm trên đĩa SSD đã bị vô hiệu hóa tại mảng. Khi bộ đệm được kích hoạt, các lỗi đã biến mất khỏi lỗi máy chủ SQL.

Tôi phải thừa nhận rằng tôi đã không biết rằng RAID Array cần các thiết lập cài đặt bổ sung này. Tôi đã mong đợi nó hoạt động mà không cần bất kỳ sự can thiệp nào.

Họ cũng cập nhật phần mềm Smart Array và áp dụng các bản vá mới nhất, điều mà tôi nghĩ rằng dù sao họ cũng nên làm và không cần DBA để đề xuất.

Rất cám ơn mọi người đã dành thời gian để xem xét vấn đề này với tôi.

Garrett