Tần suất băm / sắp xếp tràn vào tempdb có liên quan gì?

Ứng dụng doanh nghiệp của chúng tôi sử dụng SQL Server để lưu trữ dữ liệu và chủ yếu là hệ thống OLTP. Tuy nhiên, một thành phần quan trọng trong ứng dụng của chúng tôi tạo ra khối lượng công việc OLAP đáng kể.

Độ trễ ghi của chúng tôi vào tempdb là khoảng 100ms. Xu hướng này giữ theo thời gian, và ALLOW_SNAPSHOT_ISOLATIONbị tắt . Chúng tôi đang khắc phục sự cố liên quan đến vấn đề này và điều thú vị duy nhất chúng tôi tìm thấy cho đến nay là có một số lượng đáng kể hàm băm và sắp xếp cho tempdb. Chúng tôi phỏng đoán điều này đến từ khối lượng công việc OLAP của chúng tôi.

Câu hỏi

Tần suất của sự cố tràn có liên quan? Bất kì? Có bao nhiêu sự cố tràn / giây? Dữ liệu sơ bộ của chúng tôi chỉ ra rằng chúng tôi có khoảng 2 lần tràn băm mỗi giây và 25 lần tràn sắp xếp mỗi phút.

Có thể là tần suất tràn này có thể là thủ phạm chính trong độ trễ ghi tempdb cao của chúng tôi?

Thông tin khác

Chúng tôi đang sử dụng nhiều tệp cho tempdb theo khuyến nghị cho mỗi số lõi. Các tệp tempdb nằm trên RAID 1 + 0 SAN (với SSD hiệu suất cao) nhưng đó là thiết bị tương tự như các tệp nhật ký và dữ liệu DB chính. Các tệp tempdb có kích thước đủ lớn để chúng phát triển không thường xuyên. Chúng tôi không sử dụng cờ theo dõi 1117 hoặc 1118. Một biến khác là thiết lập này được chia sẻ cho một số cơ sở dữ liệu khác nhau mà tất cả đều trải nghiệm tải trung bình đến cao.

Độ trễ ghi 100 ms của chúng tôi lớn hơn nhiều so với phạm vi chấp nhận được cho độ trễ ghi tempdb mà chúng tôi đã tìm thấy trên MSDN, Kỹ năng SQL và các trang web khác. Tuy nhiên, độ trễ ghi cho các cơ sở dữ liệu khác của chúng tôi là tốt (dưới 10ms). Dựa trên các số liệu thống kê khác, có vẻ như chúng tôi đang sử dụng tempdb rất nhiều, đặc biệt là cho các đối tượng nội bộ. Vì vậy, chúng tôi đang đào sâu để cố gắng tìm hiểu lý do tại sao ứng dụng của chúng tôi sử dụng các đối tượng nội bộ rất nhiều.

Chúng tôi có các vấn đề hiệu suất thực sự trên nền tảng của chúng tôi biểu hiện theo nhiều cách khác nhau. Chúng tôi đã theo dõi các bộ đếm hoàn hảo, xem xét các chế độ xem DM và phân tích hành vi ứng dụng của chúng tôi để cố gắng tìm hiểu các đặc điểm sử dụng tài nguyên của hệ thống của chúng tôi. Chúng tôi đang tập trung vào sự cố tràn ngay bây giờ vì chúng tôi đã đọc rằng sự cố tràn có tác động tiêu cực nghiêm trọng vì chúng được thực hiện trên đĩa thay vì trong bộ nhớ. Và chúng tôi dường như có số lượng tràn rất cao, nhưng tôi muốn nhận được một số ý kiến ​​đóng góp về những gì mọi người cho là "cao".

Có thể là tần suất tràn này có thể là thủ phạm chính trong độ trễ ghi tempdb cao của chúng tôi?

Có , có thể , mặc dù thông thường đó là kích thước trung bình của sự cố tràn và mức độ sâu của chúng (tức là sự cố tràn băm đệ quy, loại nhiều lượt) quan trọng hơn tần suất mỗi lần.

SQL Server cung cấp một loạt các thông số và thông tin DMV để giúp bạn khắc phục các yếu tố đóng góp khác nhau đối với áp lực tempdb, nhiều trong số đó được thảo luận trong Bài viết kỹ thuật của Microsoft, "Làm việc với tempdb trong SQL Server 2005" (áp dụng cho tất cả các phiên bản 2005 trở đi ).

Bạn sẽ có thể sử dụng các truy vấn hướng dẫn và chẩn đoán có trong tài liệu đó để bắt đầu xác định nguyên nhân chính của bất kỳ áp lực tempdb nào. Đừng coi thường hoạt động lưu trữ phiên bản đơn giản vì ALLOW_SNAPSHOT_ISOLATIONkhông được bật. Nhiều tính năng sử dụng kho phiên bản (ví dụ: trình kích hoạt, MARS, RCSI) ngoài cách ly ảnh chụp nhanh.

Nếu sự cố tràn và sắp xếp băm hóa ra có ý nghĩa ở mức cao, có lẽ bạn sẽ cần phải thiết lập một số giám sát cụ thể cho việc này. Tùy thuộc một chút vào phiên bản SQL Server của bạn, điều này không phải lúc nào cũng đơn giản như người ta có thể hy vọng. Để kết nối sự cố tràn và sắp xếp băm với truy vấn cụ thể gây ra chúng yêu cầu Thông báo sự kiện hoặc Sự kiện mở rộng. Bài viết của SolidQ, " Xác định và giải quyết các cảnh báo sắp xếp " chứa thông tin chi tiết và một số lời khuyên chung tốt về việc giải quyết các nguyên nhân phổ biến.

Bạn cũng nên làm việc với nhóm lưu trữ của mình để xác định mức độ trễ cao có thể quy cho khối lượng công việc của bạn, bao nhiêu đến từ việc sử dụng chung khác và những tùy chọn nào có thể cấu hình lại. Phân tích của bạn về các số liệu của SQL Server sẽ giúp thông báo cho cuộc thảo luận này, cũng như mọi số liệu mà người SAN có thể cung cấp.