Từ những gì tôi có thể nói Thủ tục Cache Tỷ lệ trúng dưới 95% là một vấn đề. Trên hộp của tôi, các giá trị di chuột từ 85 đến 95%.
Làm thế nào để tôi khắc phục vấn đề này? Máy chủ dường như có rất nhiều RAM nên không phải là vấn đề. nó có thể là gì khác?
Câu trả lời:
Hãy để tôi tóm tắt (và làm tròn!) Các điểm dữ liệu quan trọng trong bảng tính của bạn:
Total Use Count 1
--------------------------------------- -----------------------
Total Plans Total MBs Avg Use Count Total Plans Total MBs
----------- --------- ------------- ----------- ---------
Adhoc 55,987 3,054 3 38,314 2,036
Proc 709 1,502 1,549 135 527Vì vậy, hàng đầu tiên hiển thị nội dung xấu, chiếm khoảng 2/3 bộ nhớ cache của gói (những thứ hầu như chỉ được sử dụng một lần, với một vài ngoại lệ rất nhỏ). Bạn cần phải cố gắng và loại bỏ càng nhiều càng tốt. Hàng thứ hai cho thấy những thứ tốt. Đây là những điều bạn muốn trong bộ nhớ cache của gói (kế hoạch có số lượng tái sử dụng cao). Phần còn lại của dữ liệu phần lớn không liên quan IMHO. Một điểm khác: bạn nói rằng quyền truy cập chỉ dành riêng cho các thủ tục được lưu trữ, nhưng nếu các thủ tục đó sử dụng SQL động, thì các câu lệnh đó được lưu trong bộ nhớ cache dưới dạng AdHockế hoạch, không phải là Prockế hoạch.
Vào năm 2008 hoặc cao hơn, tôi sẽ nói bật optimize for ad hoc workloadsvà chuyển sang vấn đề tiếp theo - điều này sẽ lấy số lượng MB mà các gói sử dụng một lần của bạn hiện đang chiếm giữ bên cạnh không có gì. Thật không may, vào năm 2005, các tùy chọn của bạn khá hạn chế, ngoài việc cấu trúc lại các quy trình được lưu trữ đó để sử dụng mức câu lệnh OPTION (RECOMPILE)và / hoặc ít hơn / không có SQL động hoặc bật tham số hóa bắt buộc ở cấp cơ sở dữ liệu - để cố gắng sử dụng lại kế hoạch tốt hơn truy vấn tương tự bằng cách coi chữ là tham số cho mục đích khớp kế hoạch. Tôi ngần ngại thậm chí đề cập đến các hướng dẫn kế hoạch bởi vì chúng không dành cho sự rụt rè và - như tôi sẽ thảo luận sau trong câu trả lời này - tôi không chắc rằng nó đáng để đi theo con đường đó trừ khi bạn biết bộ nhớ cache của kế hoạch chắc chắn là nguồn hiệu suất của bạn vấn đề.
Tôi đã hỏi về @@VERSIONbởi vì, trước SP2, thuật toán cho số lượng bộ nhớ có thể được phân bổ cho bộ đệm của kế hoạch là tương đối lỏng lẻo. Kể từ SP2, họ đã thắt chặt điều đó lên một chút (sự thay đổi được ghi lại và giải thích trong bài này và bài này ). Trong trường hợp của bạn, bộ đệm của gói tương đối đầy đủ, do đó, không có gì đáng ngạc nhiên khi bạn nhận được bộ nhớ cache. 26 GB = giới hạn trên 5,8 GB; Tôi thấy ~ 4,5 GB trong bảng tính nhưng có thể có một số khác biệt về tính toán hoặc cấu hình ở đây mà tôi không biết.
Bài viết MSDN này nói về optimize for ad hoc workloadscài đặt máy chủ được thêm vào năm 2008 và đề cập đến cờ theo dõi 8032, điều này sẽ cho phép bạn phân bổ thêm bộ nhớ cho bộ nhớ cache của bạn (có lẽ trong trường hợp không cài đặt cài đặt này ở cấp máy chủ, mà tôi hiện khuyên dùng cho tất cả khách hàng của chúng tôi, hoặc ít nhất là 99% không còn trên 2005). Tôi chưa bao giờ thử nghiệm cờ theo dõi này trên 2005 SP3 hoặc SP4, và thành thật mà nói thậm chí không chắc chắn khi nó được giới thiệu. Tôi cũng không biết liệu nó sẽ giải quyết vấn đề của bạn hay chỉ thay đổi nó, vì tôi nghĩ ngay cả khi bạn có thêm% RAM được phân bổ cho bộ nhớ cache, bạn vẫn sẽ lấp đầy nó và có rất nhiều lỗi nhớ cache vì bản chất của thủ tục lưu trữ của bạn.
Hoặc, tất nhiên, nếu thậm chí có một vấn đề cần giải quyết liên quan trực tiếp đến bộ đệm của kế hoạch. Chỉ vì tỷ lệ trúng bộ nhớ cache của bạn không cao như bạn mong đợi không có nghĩa là nó gây ra sự cố của bạn và tất nhiên điều ngược lại là ngay cả ở tỷ lệ trúng bộ nhớ cache 100% - điều đó dường như không thực tế khi có quá nhiều kế hoạch của bạn là sử dụng một lần và đặc biệt - người dùng của bạn vẫn có thể gặp phải vấn đề về hiệu suất do một thứ khác hoàn toàn gây ra.
Đề nghị của tôi là tìm kiếm súng hút thuốc tốt hơn so với kế hoạch tỷ lệ trúng bộ nhớ cache. Nhận thông tin cụ thể hơn về khiếu nại về hiệu suất của người dùng của bạn. Có phải tất cả các truy vấn luôn luôn chậm? Một số truy vấn nhất định? Thời gian nhất định trong ngày / tuần / chu kỳ kinh doanh? Có phải chỉ báo cáo truy vấn chậm? Hãy đọc một cách nghiêm túc thông qua tài liệu dài và khô khan được thừa nhận này về các thực tiễn tốt nhất của SQL Server - đặc biệt là phần chờ đợi và hàng đợi, có thể giúp bạn hình thành một cách tiếp cận hợp lý để xác định, chẩn đoán và giải quyết các vấn đề về hiệu suất. Làm cho một số số trên bảng điều khiển trông đẹp hơn - một số mà bạn thậm chí không biết trực tiếp góp phần gây ra sự cố - có thể rất thỏa mãn, nhưng nếu nó không giải quyết được các vấn đề về hiệu suất của người dùng, thì nó thực sự đã khiến bạn hiểu bất cứ nơi nào
Đây cũng có thể hữu ích trong việc đọc lên biên dịch / biên dịch lại và lập kế hoạch tái sử dụng bộ đệm. Một số trong số này tập trung vào năm 2008 (đặc biệt là về cài đặt khối lượng công việc đặc biệt), nhưng phần lớn thông tin vẫn hữu ích cho năm 2005 và / hoặc để hiểu rõ hơn về lợi ích của việc nâng cấp (gợi ý, gợi ý).