SQL Server Cache Flush và I / O đĩa

Chúng tôi đang bận kiểm tra tải hệ thống OLTP mà chúng tôi đã phát triển trong .NET 4.0 và chạy SQL Server 2008 R2 ở phía sau. Hệ thống sử dụng hàng đợi Nhà môi giới dịch vụ SQL Server, rất hiệu quả, nhưng chúng tôi đang gặp phải một xu hướng đặc biệt trong khi xử lý.

SQL Server xử lý các yêu cầu với tốc độ phồng trong 1 phút, sau đó là ~ 20 giây hoạt động ghi đĩa tăng lên. Biểu đồ sau minh họa vấn đề.

Yellow = Transactions per second
Blue   = Total CPU usage
Red    = Sqlsrv Disk Write Bytes/s
Green  = Sqlsrv Disk Read Bytes/s

Trong quá trình khắc phục sự cố, chúng tôi đã thử các cách sau mà không có bất kỳ thay đổi đáng kể nào trong mẫu:

• Đại lý máy chủ SQL đã dừng.
• Giết chết hầu hết mọi quy trình đang chạy khác (Không có A / V, SSMS, VS, Windows Explorer, v.v.)
• Đã xóa tất cả các cơ sở dữ liệu khác.
• Vô hiệu hóa tất cả các bộ hẹn giờ hội thoại (chúng tôi không sử dụng bất kỳ trình kích hoạt nào).
• Đã chuyển từ cách tiếp cận theo hướng hàng đợi tin nhắn sang thiết kế giám sát bảng đơn giản / thô.
• Sử dụng tải khác nhau từ nhẹ đến nặng.
• Đã sửa tất cả các bế tắc.

Có vẻ như SQL Server có thể đang xây dựng bộ đệm của nó và ghi nó vào đĩa theo các khoảng thời gian cụ thể, nhưng tôi không thể tìm thấy bất cứ điều gì trực tuyến để hỗ trợ lý thuyết này.

Tiếp theo, tôi dự định chuyển giải pháp sang môi trường thử nghiệm chuyên dụng của chúng tôi để xem liệu tôi có thể tái tạo vấn đề không. Bất kỳ trợ giúp tạm thời sẽ được đánh giá rất cao.

Cập nhật 1 Theo yêu cầu, theo đây là một biểu đồ bao gồm Trang / Điểm kiểm tra , Tuổi thọ trang và một số bộ đếm độ trễ của đĩa.

Có vẻ như Điểm kiểm tra (đường màu xanh nhạt) là nguyên nhân làm giảm hiệu suất (đường màu vàng) mà chúng tôi đang quan sát. ^

Độ trễ của đĩa vẫn tương đối ổn định trong quá trình xử lý và tuổi thọ trang dường như không có bất kỳ ảnh hưởng đáng chú ý nào. Chúng tôi cũng đã điều chỉnh lượng ram có sẵn cho SQL Server, điều này cũng không có ảnh hưởng lớn. Thay đổi mô hình phục hồi từ SIMPLEđến FULLsự khác biệt nhỏ cũng được thực hiện.

Cập nhật 2 Bằng cách thay đổi "Khoảng thời gian phục hồi" như sau, chúng tôi đã cố gắng giảm khoảng thời gian xảy ra điểm kiểm tra:

EXEC sp_configure 'show advanced options',1
GO 

RECONFIGURE
GO

EXEC sp_configure 'recovery interval', '30'
GO

RECONFIGURE 
GO

EXEC sp_configure 'show advanced options',0
GO
RECONFIGURE

Tôi không chắc chắn liệu đây là thực hành xấu?

Những người khác đã chỉ ra thủ phạm: SQL Server tích lũy các bản cập nhật trong bộ nhớ (trong vùng đệm) và chỉ xóa chúng theo định kỳ (tại các điểm kiểm tra). Hai tùy chọn được đề xuất (-k và khoảng thời gian điểm kiểm tra) là bổ sung:

• -k sẽ khiến cho điểm kiểm tra tạo ra các yêu cầu IO ít tích cực hơn và tồn tại lâu hơn
• giảm khoảng thời gian phục hồi sẽ khiến điểm kiểm tra bắt đầu thường xuyên hơn

Nhưng tôi đã không trả lời chỉ để lấy lại những bình luận tốt đẹp mà bạn nhận được từ xa :)

Thật không may, những gì bạn đang thấy là một hành vi rất điển hình của xử lý hàng đợi . Cho dù bạn sử dụng hàng đợi của Nhà môi giới dịch vụ hoặc chọn sử dụng các bảng làm phương pháp tiếp cận hàng đợi , hệ thống rất dễ bị loại hành vi này. Điều này là do xử lý dựa trên hàng đợi là ghi nặng, thậm chí viết nặng hơn xử lý OLTP. Cả hai nguyên hàm enqueue và dequeue đều là các thao tác ghi và hầu như không có thao tác đọc. Nói một cách đơn giản, xử lý hàng đợi sẽ tạo ra nhiều ghi nhất (= hầu hết các trang bẩn và hầu hết nhật ký) so với bất kỳ khối lượng công việc nào khác, thậm chí OLTP (tức là TPC-C như khối lượng công việc).

Rất quan trọng, việc ghi khối lượng công việc hàng đợi tuân theo mẫu chèn / xóa: mọi hàng được chèn sẽ bị xóa rất nhanh. Điều này rất quan trọng để phân biệt với mẫu chỉ có phần phụ của khối lượng công việc nặng (ETL). Về cơ bản, bạn đang cho ăn nhiệm vụ dọn dẹp ma một bữa ăn đầy đủ, và bạn có thể dễ dàng vượt qua nó. Hãy suy nghĩ về điều đó có nghĩa là gì:

• enqueue là một chèn, nó sẽ tạo ra một trang bẩn
• dequeue là một lần xóa, nó sẽ làm bẩn cùng một trang một lần nữa (nó có thể là may mắn và bắt được trang trước điểm kiểm tra, vì vậy nó sẽ tránh được việc quét hai lần, nhưng chỉ khi may mắn)
• dọn dẹp ma sẽ làm sạch trang, làm cho nó bẩn trở lại

Vâng, điều đó thực sự có nghĩa là bạn có thể sẽ viết một trang ba lần vào đĩa, trong ba yêu cầu IO khác nhau, cho mỗi tin nhắn bạn xử lý (trường hợp xấu nhất). Và điều đó cũng có nghĩa là IO ngẫu nhiên của các điểm kiểm tra sẽ thực sự ngẫu nhiên vì điểm ghi của trang sẽ được truy cập lại bởi những người di chuyển giữa hai điểm kiểm tra (so sánh với nhiều khối lượng công việc OLTP có xu hướng nhóm ghi vào một số 'điểm nóng', không phải hàng đợi ...).

Vì vậy, bạn có ba điểm viết này, chạy đua để đánh dấu cùng một trang bẩn hết lần này đến lần khác. Và đó là trước khi chúng tôi xem xét bất kỳ phân chia trang nào, việc xử lý hàng đợi cũng có thể bị ảnh hưởng do thứ tự khóa chèn. Bằng cách so sánh, khối lượng công việc OLTP 'điển hình' có tỷ lệ đọc / ghi cân bằng hơn nhiều và OLTP ghi phân phối trên các phần chèn / cập nhật / xóa, thường là với các cập nhật (thay đổi 'trạng thái') và chèn phần chia sẻ của sư tử. Ghi xử lý hàng đợi được chèn / xóa độc quyền với, theo định nghĩa, chia 50/50.

Một số hậu quả sau:

• Điểm kiểm tra trở thành một vấn đề rất nóng (không còn là một bất ngờ đối với bạn)
• Bạn sẽ thấy sự phân mảnh nặng nề (sự phân mảnh sẽ không còn quan trọng vì bạn sẽ không thực hiện quét phạm vi, nhưng hiệu quả IO của bạn bị ảnh hưởng và việc dọn dẹp ma có nhiều việc hơn, làm chậm nó hơn nữa)
• Thông lượng IO ngẫu nhiên của bộ lưu trữ MDF sẽ là nút cổ chai của bạn

Đề xuất của tôi có 3 chữ cái: S, S và D. Di chuyển MDF của bạn đến một bộ lưu trữ có thể xử lý IO ngẫu nhiên nhanh. SSD. Fusion-IO nếu bạn có moneys. Thật không may, đây là một trong những triệu chứng không thể giải quyết bằng RAM rẻ hơn ...

Biên tập:

Như Mark chỉ ra rằng bạn có hai đĩa logic được hỗ trợ bởi một đĩa vật lý. Có lẽ bạn đã cố gắng làm theo các thực tiễn tốt nhất và chia nhỏ nhật ký trên D: và dữ liệu trên C: nhưng than ôi là vô ích, C và D là cùng một đĩa. Giữa các điểm kiểm tra bạn đạt được thông lượng tuần tự nhưng ngay khi điểm kiểm tra bắt đầu, các đầu đĩa bắt đầu di chuyển và thông lượng nhật ký của bạn sụp đổ, lấy toàn bộ thông lượng ứng dụng. Đảm bảo bạn tách nhật ký DB để không bị ảnh hưởng bởi dữ liệu IO (đĩa riêng).