Sử dụng bộ nhớ của SQL Server


11

Làm cách nào để kiểm tra việc sử dụng bộ nhớ của máy chủ SQL của tôi trong hộp sản xuất. Tôi đang sử dụng SQL Server 2016. Khi tôi kiểm tra trình quản lý tác vụ, nó hiển thị trên 90%. Tôi không nghĩ rằng đó là việc sử dụng bộ nhớ thực của máy chủ sql.

Tôi có một grafana công cụ hiệu suất SQL cho thấy mức độ sử dụng CPU rất ít so với những gì tôi thấy trong trình quản lý tác vụ. Tôi đã kiểm tra Resource Monitor, có thể thấy giá trị CPU trung bình. Tôi bối rối không biết đó là việc sử dụng bộ nhớ máy chủ SQL. Tôi đang cố gắng xác định xem áp lực bộ nhớ có phải là vấn đề đối với một số vấn đề của tôi không.

Ai đó có thể trực tiếp đến một lời giải thích tốt / thích hợp.

Câu trả lời:


12

Ai đó có thể trực tiếp đến một lời giải thích tốt / thích hợp.

Tôi sẽ bắt đầu bằng cách nói Trình quản lý tác vụ không phải là nơi chính xác để đánh giá mức tiêu thụ bộ nhớ của SQL Server, nó sẽ không cho bạn biết giá trị chính xác khi tài khoản dịch vụ SQL Server có đặc quyền Khóa trang trong bộ nhớ (LPIM). Điều này là do thông thường trình quản lý tác vụ theo dõi Process Private bytesbộ nhớ có thể phân trang và được phân bổ thông qua chức năng VirtualAlloc () nhưng với tài khoản Dịch vụ có phân bổ bộ nhớ LPIM được thực hiện bởi API AWE không thể phân trang được nên trình quản lý tác vụ không theo dõi và điều này có thể dẫn đến không chính xác giá trị.

Việc SQL Server sử dụng bộ nhớ được cấp phát cho nó là điều khá bình thường, có vẻ như nó đang sử dụng bộ nhớ cao nhưng điều này là khá bình thường. Đừng hoảng sợ nếu một số công cụ hiển thị mức sử dụng CPU thấp và trình quản lý tác vụ đang hiển thị bộ nhớ cao, điều này có thể chỉ là bình thường. Để biết SQL Server đang sử dụng bao nhiêu bộ nhớ vật lý, vui lòng sử dụng truy vấn bên dưới

select
(physical_memory_in_use_kb/1024)Phy_Memory_usedby_Sqlserver_MB,
(locked_page_allocations_kb/1024 )Locked_pages_used_Sqlserver_MB,
(virtual_address_space_committed_kb/1024 )Total_Memory_UsedBySQLServer_MB,
process_physical_memory_low,
process_virtual_memory_low
from sys. dm_os_process_memory

Phy_Memory_useby_Sqlserver_MB - Cung cấp tổng bộ nhớ vật lý được SQL Server sử dụng trong MB Total_Memory_useBy_QueryServer_MB- - Cung cấp tổng bộ nhớ (tệp RAM + trang) được SQL Server sử dụng trong MB

Để đọc thêm về lý do tại sao không nên sử dụng trình quản lý tác vụ, hãy xem Vui với các trang bị khóa, AWE, Trình quản lý tác vụ và Bộ làm việc


17

'Tôi đang cố gắng xác định xem áp lực bộ nhớ có phải là vấn đề đối với một số vấn đề của tôi không.'

tập lệnh rất hữu ích: https://github.com/ktaranov/sqlserver-kit/blob/master/Scripts/QueryServer_Memory_In information.sql

bạn thấy việc sử dụng bộ nhớ dài dòng: nhập mô tả hình ảnh ở đây

https://www.sqlskills.com/bloss/glenn/sql-server-diagnellect-inif-queries-for-november-2017/ Truy vấn thông tin chẩn đoán SQL Server 2017:
xem bình luận

-- Page Life Expectancy (PLE) value for each NUMA node in current instance  (Query 46) (PLE by NUMA Node)
SELECT @@SERVERNAME AS [Server Name], RTRIM([object_name]) AS [Object Name], instance_name, cntr_value AS [Page Life Expectancy]
FROM sys.dm_os_performance_counters WITH (NOLOCK)
WHERE [object_name] LIKE N'%Buffer Node%' -- Handles named instances
AND counter_name = N'Page life expectancy' OPTION (RECOMPILE);
------

-- PLE is a good measurement of internal memory pressure
-- Higher PLE is better. Watch the trend over time, not the absolute value

(Truy vấn 14)

-- Good basic information about OS memory amounts and state  (Query 14) (System Memory)
SELECT total_physical_memory_kb/1024 AS [Physical Memory (MB)], 
       available_physical_memory_kb/1024 AS [Available Memory (MB)], 
       total_page_file_kb/1024 AS [Total Page File (MB)], 
       available_page_file_kb/1024 AS [Available Page File (MB)], 
       system_cache_kb/1024 AS [System Cache (MB)],
       system_memory_state_desc AS [System Memory State]
FROM sys.dm_os_sys_memory WITH (NOLOCK) OPTION (RECOMPILE);
------

-- You want to see "Available physical memory is high" for System Memory State
-- This indicates that you are not under external memory pressure

-- Possible System Memory State values:
-- Available physical memory is high
-- Physical memory usage is steady
-- Available physical memory is low
-- Available physical memory is running low
-- Physical memory state is transitioning

(47)

-- Memory Grants Pending value for current instance  (Query 47) (Memory Grants Pending)
SELECT @@SERVERNAME AS [Server Name], RTRIM([object_name]) AS [Object Name], cntr_value AS [Memory Grants Pending]
FROM sys.dm_os_performance_counters WITH (NOLOCK)
WHERE [object_name] LIKE N'%Memory Manager%' -- Handles named instances
AND counter_name = N'Memory Grants Pending' OPTION (RECOMPILE);
------

-- Run multiple times, and run periodically if you suspect you are under memory pressure
-- Memory Grants Pending above zero for a sustained period is a very strong indicator of internal memory pressure

(62)

-- Top Cached SPs By Total Logical Reads. Logical reads relate to memory pressure  (Query 62) (SP Logical Reads)
SELECT TOP(25) p.name AS [SP Name], qs.total_logical_reads AS [TotalLogicalReads], 
qs.total_logical_reads/qs.execution_count AS [AvgLogicalReads],qs.execution_count, 
ISNULL(qs.execution_count/DATEDIFF(Minute, qs.cached_time, GETDATE()), 0) AS [Calls/Minute], 
qs.total_elapsed_time, qs.total_elapsed_time/qs.execution_count AS [avg_elapsed_time],
CASE WHEN CONVERT(nvarchar(max), qp.query_plan) LIKE N'%<MissingIndexes>%' THEN 1 ELSE 0 END AS [Has Missing Index], 
FORMAT(qs.last_execution_time, 'yyyy-MM-dd HH:mm:ss', 'en-US') AS [Last Execution Time], 
FORMAT(qs.cached_time, 'yyyy-MM-dd HH:mm:ss', 'en-US') AS [Plan Cached Time]
-- ,qp.query_plan AS [Query Plan] -- Uncomment if you want the Query Plan
FROM sys.procedures AS p WITH (NOLOCK)
INNER JOIN sys.dm_exec_procedure_stats AS qs WITH (NOLOCK)
ON p.[object_id] = qs.[object_id]
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
WHERE qs.database_id = DB_ID()
AND DATEDIFF(Minute, qs.cached_time, GETDATE()) > 0
ORDER BY qs.total_logical_reads DESC OPTION (RECOMPILE);
------

-- This helps you find the most expensive cached stored procedures from a memory perspective
-- You should look at this if you see signs of memory pressure

(63)

-- Top Cached SPs By Total Physical Reads. Physical reads relate to disk read I/O pressure  (Query 63) (SP Physical Reads)
SELECT TOP(25) p.name AS [SP Name],qs.total_physical_reads AS [TotalPhysicalReads], 
qs.total_physical_reads/qs.execution_count AS [AvgPhysicalReads], qs.execution_count, 
qs.total_logical_reads,qs.total_elapsed_time, qs.total_elapsed_time/qs.execution_count AS [avg_elapsed_time],
CASE WHEN CONVERT(nvarchar(max), qp.query_plan) LIKE N'%<MissingIndexes>%' THEN 1 ELSE 0 END AS [Has Missing Index],
FORMAT(qs.last_execution_time, 'yyyy-MM-dd HH:mm:ss', 'en-US') AS [Last Execution Time], 
FORMAT(qs.cached_time, 'yyyy-MM-dd HH:mm:ss', 'en-US') AS [Plan Cached Time]
-- ,qp.query_plan AS [Query Plan] -- Uncomment if you want the Query Plan 
FROM sys.procedures AS p WITH (NOLOCK)
INNER JOIN sys.dm_exec_procedure_stats AS qs WITH (NOLOCK)
ON p.[object_id] = qs.[object_id]
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
WHERE qs.database_id = DB_ID()
AND qs.total_physical_reads > 0
ORDER BY qs.total_physical_reads DESC, qs.total_logical_reads DESC OPTION (RECOMPILE);
------

-- This helps you find the most expensive cached stored procedures from a read I/O perspective
-- You should look at this if you see signs of I/O pressure or of memory pressure

(64)

-- Top Cached SPs By Total Logical Writes (Query 64) (SP Logical Writes)
-- Logical writes relate to both memory and disk I/O pressure 
SELECT TOP(25) p.name AS [SP Name], qs.total_logical_writes AS [TotalLogicalWrites], 
qs.total_logical_writes/qs.execution_count AS [AvgLogicalWrites], qs.execution_count,
ISNULL(qs.execution_count/DATEDIFF(Minute, qs.cached_time, GETDATE()), 0) AS [Calls/Minute],
qs.total_elapsed_time, qs.total_elapsed_time/qs.execution_count AS [avg_elapsed_time],
CASE WHEN CONVERT(nvarchar(max), qp.query_plan) LIKE N'%<MissingIndexes>%' THEN 1 ELSE 0 END AS [Has Missing Index], 
FORMAT(qs.last_execution_time, 'yyyy-MM-dd HH:mm:ss', 'en-US') AS [Last Execution Time], 
FORMAT(qs.cached_time, 'yyyy-MM-dd HH:mm:ss', 'en-US') AS [Plan Cached Time]
-- ,qp.query_plan AS [Query Plan] -- Uncomment if you want the Query Plan 
FROM sys.procedures AS p WITH (NOLOCK)
INNER JOIN sys.dm_exec_procedure_stats AS qs WITH (NOLOCK)
ON p.[object_id] = qs.[object_id]
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qp
WHERE qs.database_id = DB_ID()
AND qs.total_logical_writes > 0
AND DATEDIFF(Minute, qs.cached_time, GETDATE()) > 0
ORDER BY qs.total_logical_writes DESC OPTION (RECOMPILE);
------

-- This helps you find the most expensive cached stored procedures from a write I/O perspective
-- You should look at this if you see signs of I/O pressure or of memory pressure

PS đây không phải là một câu trả lời thấu đáo


Nhưng tập lệnh không cung cấp bộ nhớ được sử dụng bởi SQL Server, đây chính là thứ mà OP đang tìm kiếm. Có nó cung cấp thông tin về các quầy khác nhau.
Shanky

sqlskills.com/bloss/glenn/ Nhật SQL Server 2017 Truy vấn thông tin chẩn đoán (Truy vấn 14) (47) (62) (64) xem bình luận
Igor

Tôi thấy chỉ có 2 bình luận và không có bình luận nào liên quan đến câu hỏi của OP. Tất cả những gì tôi muốn nói là kịch bản khá hay và cung cấp cho bạn nhiều thông tin nhưng nó không cung cấp cho s physical memory utilized by SQL Server, đó là những gì OP đang hỏi
Shanky

imho, bạn trả lời 'Làm cách nào để kiểm tra việc sử dụng bộ nhớ của máy chủ SQL của tôi trong hộp sản xuất', tôi trả lời 'Tôi đang cố xác định xem áp lực bộ nhớ có phải là vấn đề đối với một số vấn đề của tôi không.' ?
Igor

1
Đủ công bằng, nhưng bạn chỉ đăng một số dữ liệu. Trong trường hợp này, bạn phải thêm cách rút ra suy luận từ dữ liệu đó và giá trị nào cho thấy là áp lực bộ nhớ.
Shanky

2

Tôi không chắc chắn về công cụ grafana, nhưng nếu bạn chạy truy vấn bên dưới, nó sẽ hiển thị bộ nhớ hiện được phân bổ

SELECT  
(physical_memory_in_use_kb/1024) AS Memory_usedby_Sqlserver_MB,  
(locked_page_allocations_kb/1024) AS Locked_pages_used_Sqlserver_MB,  
(total_virtual_address_space_kb/1024) AS Total_VAS_in_MB,  
process_physical_memory_low,  
process_virtual_memory_low  
FROM sys.dm_os_process_memory; 

0

Bạn nên bỏ trình quản lý tác vụ vì nó không báo cáo đúng thông tin cấp phát bộ nhớ trong một số trường hợp, tùy thuộc vào thói quen phân bổ bộ nhớ sử dụng ứng dụng. Từ hệ điều hành, bạn sẽ tốt với perfmon, vì nó sẽ báo cáo việc sử dụng bộ nhớ đúng cách. Bạn cũng có thể sử dụng SQL DMV báo cáo thông tin bộ nhớ, ví dụ sys.dm_os_sys_memory (có nhiều dmv liên quan đến bộ nhớ tùy theo nhu cầu của bạn và phiên bản SQL Server).

Dưới đây là một bài viết giải thích trình quản lý tác vụ báo cáo không chính xác việc sử dụng bản ghi SQL Server:

LINK: ngừng sử dụng tác vụ-trình quản lý-kiểm tra-sqls-bộ nhớ-sử dụng

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.