Làm cách nào để kiểm soát việc sử dụng quá mức ram của SQL Server?


13

Máy chủ cơ sở dữ liệu mà tôi đang sử dụng đang chạy 6 phiên bản SQL Server khác nhau. Nó có RAM 48 GB. Và một trong số họ đang tiêu thụ hơn 10 GB RAM, hiện tại tổng mức tiêu thụ là 20 GB. Tiêu thụ RAM đang tăng liên tục. Vài ngày trước khi nó sử dụng hơn 40 GB RAM và máy chủ đã phản hồi rất chậm. Ứng dụng cho thấy các vấn đề sự cố khi lưu dữ liệu.

Vì vậy, tôi đã khởi động lại các dịch vụ SQL Server.

Ngay sau khi các dịch vụ được khởi động lại, mức sử dụng đã giảm xuống còn 4 GB, nhưng giờ nó đang tăng lên. Và tôi lo lắng rằng nó sẽ tăng lên tới 40 GB sau 4 hoặc 5 ngày và khiến máy chủ chậm.

Tôi đoán khởi động lại dịch vụ không phải là lựa chọn tốt.

Tôi cũng tìm thấy từ các nguồn khác nhau mà chúng ta có thể đặt kích thước sử dụng bộ nhớ tối đa cho SQL Server. Và tôi không chắc chắn nếu điều này sẽ giúp hay không. Tôi không thể kiểm tra điều này bởi vì máy chủ đang sử dụng cơ sở dữ liệu sản xuất và sẽ gặp rủi ro nếu dịch vụ dừng trong khi sửa đổi cài đặt trong SQL Server.

Có ai có thể giúp đỡ cho vấn đề này?


1
Theo mặc định, SQL sẽ sử dụng nhiều RAM nhất có thể để tối đa hóa hiệu suất của nó, điều này rất tốt - điều đó có nghĩa là nó lưu các truy vấn và kết quả chung để giúp ứng dụng của bạn nhanh hơn. Nó sẽ chỉ sử dụng RAM tối đa đến giới hạn mà hệ điều hành báo cáo phân trang có thể xảy ra. Bạn có thể ghi đè hành vi này. Xem tài liệu MS này: Cách điều chỉnh mức sử dụng bộ nhớ bằng cách sử dụng các tùy chọn cấu hình trong SQL Server Điều này cũng có thể hữu ích: Cách xác định cài đặt cấu hình SQL Server phù hợp

4
Đây KHÔNG phải là vấn đề - đó là hành vi được thiết kế và mặc định cho SQL Server !! Và đúng vậy - khởi động lại quy trình SQL Server là một ý tưởng khủng khiếp ..... SQL Server lưu trữ càng nhiều trang dữ liệu và chỉ mục trong bộ nhớ càng tốt - nó tối ưu hóa hiệu năng hệ thống tổng thể theo cách đó. Đó là lý do máy SQL Server phải luôn là máy chủ chuyên dụng - không làm gì khác ngoài SQL Server.
marc_s

Vâng tôi hiểu rồi. Nó được thiết kế theo cách đó. Nhưng khi máy chủ sql sử dụng nhiều bộ nhớ, nó sẽ làm cho máy chủ bị chậm và khiến các báo cáo hết thời gian. Vì vậy, tôi muốn ngăn máy chủ sql sử dụng bộ nhớ hạn chế.

4
Trên thực tế nếu SQL Server đang sử dụng nhiều bộ nhớ nhất có thể, tôi sẽ nói rằng điều đó sẽ khiến nó ít gặp khó khăn hơn trong việc cung cấp báo cáo. Đó là khi bạn hạn chế SQL Server một cách giả tạo (hoặc đặt quá nhiều phiên bản trên một hộp đang cạnh tranh tài nguyên), nơi bạn sẽ thấy các vấn đề do cấp bộ nhớ và các vấn đề khác.
Aaron Bertrand

Nhưng tôi tự hỏi tại sao nó đột nhiên bắt đầu hiển thị các báo cáo tốt sau khi khởi động lại dịch vụ máy chủ sql. Có thể là trường hợp có quá nhiều khách hàng đang sử dụng ứng dụng do các báo cáo không được hiển thị?

Câu trả lời:


14

Đó là bởi thiết kế. SQL Server được cho là sử dụng tất cả bộ nhớ khả dụng, vì nó đang lưu trữ ngày càng nhiều dữ liệu trong bộ nhớ để không cần quay lại đĩa để nhận cùng một bộ nhớ.

Nếu bạn cần giới hạn dung lượng bộ nhớ mà một phiên bản SQL Server đang sử dụng, bạn có thể thực hiện việc này trong SQL Server Management Studio bằng cách nhấp chuột phải vào tên đối tượng trong Object Explorer và chọn thuộc tính. Sau đó chọn tab bộ nhớ và đặt lượng bộ nhớ tối đa mà Máy chủ SQL sẽ được phép sử dụng. Bây giờ điều này sẽ không giới hạn tất cả các khía cạnh của SQL Server với lượng bộ nhớ đó. Điều này chỉ kiểm soát nhóm bộ đệm và bộ đệm kế hoạch thực hiện. Những thứ như CLR, Toàn văn, bộ nhớ thực được sử dụng bởi các tệp exe của SQL Server, Tác nhân SQL, các thủ tục được lưu trữ mở rộng, v.v. không được kiểm soát bởi cài đặt này. Tuy nhiên, những thứ khác thường không cần nhiều bộ nhớ, đó là vùng đệm và bộ đệm của kế hoạch thực thi cần phần lớn bộ nhớ.

Nếu bạn đặt cài đặt này trên một phiên bản, bạn sẽ muốn đặt nó trên tất cả các phiên bản để chúng không bước lên nhau.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.