[MSSQL] sys.dm_os_sys_info(시스템 리소스 확인) / 재부팅 후 일정시간 느려지는 이유(메모리 확인)

MSSQL의 다양한 정보를 알수 있는 테이블 중에 sys.dm_os_sys_info 라는 테이블이 있습니다.

해당 테이블은 컴퓨터에 대한 기타 유용한 정보 집합과 SQL Server 가 사용 가능한 리소스를 반환하는데요.

이번시간에는 메모리와 성능 관점에서 잠시 확인해 보는 시간을 가져 보려고 합니다.

---

메모리 확인

dm_os_sys_info 컬럼에서 확인해볼 컬럼입니다.

 

physical_memory_kb

컴퓨터에 있는 실제 메모리의 전체 크기를 지정합니다.

현재 물리적인 서버의 메모리는 8192MB 입니다.

 

committed_target_kb

SQL Server 메모리 관리자가 소비할 수 있는 메모리 크기(KB)를 나타냅니다. 다음과 같이 다양한 입력을 사용하여 필요한 메모리 양을 계산합니다.

현재 SQL서버의 최고 메모리 제한은 5940MB로 설정되어 있습니다.

 

committed_kb

메모리 관리자의 커밋된 메모리(KB)를 나타냅니다. 메모리 관리자의 예약된 메모리는 포함하지 않습니다.

(SQL 2008 까지는 bpool_committed로 버퍼풀 이라고 표시되었다.)

 

 

 

 

버퍼풀이란?

버퍼풀에 대해서 간단히 설명하자면 SQL서버는 데이터를 가져올때 디스크에서 가져와 버퍼풀 이라는 메모리 공간에 데이터를 올린다. 메모리는 디스크보다 빠르기 때문에 데이터가 올라가 있으면 다음에 사용할 경우 속도가 빠른 장점이 있다.

 

버퍼풀이 부족하게 되면 새로운 데이터를 디스크에서 가져오게될 경우 Lazy writes에 의해서 오래된 데이터부터 버퍼풀에서 정리를 시작한다. 이때 디스크 정보와 비교해서 데이터 변경이 없던 클린페이지는 메모리를 OS에 그냥 반환하며, 변경이 있었던 더티 페이지는 디스크에 기록하고 메모리를 OS에 반환하는 작업을 진행한다.

 

결론적으로 이런 작업을 진행하면 자원소모가 많기 때문에 메모리가 많아서 이런작업들이 없는 환경이 가장좋다.

 

결과는 아래의 쿼리로 비교해 보자.

SELECT
	physical_memory_kb/1024 as 'physical_memory_MB' --서버의 물리적인 메모리 
	,committed_target_kb/1024 as 'committed_target_MB' --SQL Server 메모리 관리자가 소비할 수 있는 메모리 크기 
	,committed_kb/1024 as 'committed_MB' --SQL Server가 버퍼풀에 올려서 사용하고 있는 메모리
FROM sys.dm_os_sys_info

 

메모리 테스트

현재 SQL서버의 메모리 사용 현황이다. 이제 SQL서버를 재시작을 진행한다.

재시작을 하면 "committed_MB"가 어떻게 변하는지 아래에서 확인해 보자.

 

physical_memory_MB : 8191 

committed_target_MB : 4968 

committed_MB :1468

 

재시작을 진행 후 10초의 간격을 두고 조회 쿼리를 확인한 결과는 다음과 같다.

"committed_MB"가 조금씩 증하가는 모습을 볼 수 있다. SQL서버가 디스크에서 버퍼풀로 데이터를 올리는 작업인 "램프 업"을 진행하는 것이다. 따라서 메모리가 큰 시스템일 경우 SQL서비스를 재시작하면 버퍼풀에 데이터가 어느정도 올라올 때 까지 속도가 저하된 것 처럼 느껴질 수있다.

 

physical_memory_MB : 8191 

committed_target_MB : 4956 

committed_MB : 520

 

physical_memory_MB : 8191 

committed_target_MB : 4956 

committed_MB : 815

 

 

physical_memory_MB : 8191 

committed_target_MB : 4956 

committed_MB : 1090

 

 

Memory 부족 현상 발생시 확인방법

메모리 부족으로 인해 다음과 같은 현상이 발생할 수 있으니 성능 모니터로 확인해 보자

• 추가 I/O(예: 매우 활성화된 LAZY WRITER 백그라운드 스레드)

• 더 높은 재컴파일 비율(SQL Re-Compilations/sec)

• 추가 CPU 사이클(CPU 사용률 증가)

• (메모리 부여 대기가 존재하는 경우) 더 오래 쿼리 실행(select * from sys.dm_exec_query_memory_grants where grant_time IS NULL )

 

이번 포스팅으로 아래의 3가지 컬럼과 변화에 대해서 알아보았다.

physical_memory_MB

committed_target_MB

committed_MB

 

만약 sys.dm_os_sys_info 테이블의 추가적인 컬럼 설명이 궁금하다면 여기를 참조하자.

https://learn.microsoft.com/ko-kr/sql/relational-databases/system-dynamic-management-views/sys-dm-os-sys-info-transact-sql?view=sql-server-ver16

sys.dm_os_sys_info(Transact-SQL) - SQL Server