인터넷 검색 중에 충돌하는 정보가 있습니다.
일부 사이트는 데이터를위한 실제 메모리가 남아 있지 않으면 SQL Server는 기존 데이터를 TEMPDB로 옮깁니다 ( SQL Server : TempDb 및 권장 사항 제거 참조 ).
그러나 다른 사이트에 따르면 실제 메모리가 충분하지 않으면 운영 체제에서 PAGE FILE을 사용하여 실제 메모리에서 해당 페이지로 데이터를 이동할 수 있다고합니다 ( SQL Server 용 페이지 파일 참조 ).
실제 메모리가 부족할 때 SQL Server가 데이터를 쓰는 위치가 궁금합니다. tempdb 또는 OS 페이지 파일로? 아니면 둘 다?
답변:
데이터를위한 실제 메모리가 남아 있지 않으면 SQL Server는 기존 데이터를 TEMPDB로 옮깁니다.
귀하가 연결 한 기사가 기껏해야 잘못되어 일부 지역에서 잘못되었습니다. 필자는 저자가 복잡한 것을 지나치게 단순화하려고했지만 그렇게하는 데 조금 멀었다 고 생각한다.
SQL Server는 이러한 방식으로 데이터를 메모리 (버퍼 풀)에서 tempdb로 이동하지 않습니다. "최근에 가장 적게 사용 된"캐싱 전략 (일반적으로)을 사용하므로 메모리가 부족하고 새로운 데이터를 메모리로 가져와야하는 경우 SQL Server는 버퍼 풀에서 LRU 데이터를 추출하여 새 데이터를 수용합니다. 이 동작은 종종 "PLE (Page Life Expectancy)" 라는 perfmon 카운터에 의해 모니터링됩니다 .
PLE 정의는 버퍼 풀 (데이터 파일 페이지의 메모리 내 캐시 페이지)로 읽은 데이터 파일 페이지가 다른 데이터를위한 공간을 만들기 위해 메모리 밖으로 푸시되기 전에 메모리에 남아있을 것으로 예상되는 시간 (초)입니다. 파일 페이지. PLE를 생각하는 또 다른 방법은 디스크에서 페이지를 읽을 수있는 여유 공간을 만들기 위해 버퍼 풀의 압력을 즉시 측정하는 것입니다. 이 두 가지 정의 모두 숫자가 높을수록 좋습니다.
쿼리 실행 중에 SQL Server 는 특정 작업에 tempdb를 사용할 수 있습니다. 이는 추정치가 나쁜 경우에 일반적으로 수행되지만 사용 가능한 메모리가 부족하면이 동작에 영향을 줄 수 있습니다.
이러한 방식으로 tempdb에 "유출"할 수있는 일부 작업은 해시 행 (조인 또는 집계 등), 메모리에서 행 정렬 및 병렬 쿼리 실행 중 행 버퍼링입니다.
사용자 쿼리는 tempdb (전역 또는 로컬 임시 테이블 사용)를 명시 적으로 사용하고 tempdb (스냅 샷 또는 읽기 커밋 된 스냅 샷 격리 수준 사용)를 암시 적으로 사용할 수 있습니다.
이러한 상황 중 어느 것도 당신이 인용 한 진술에 맞지 않는 것 같습니다.
실제 메모리가 충분하지 않은 경우 운영 체제는 PAGE FILE을 사용하여 실제 메모리에서 데이터를 이동할 수 있습니다.
이것은 확실히 일어날 수 있으며 대부분 SQL Server의 통제 범위를 벗어납니다. 일부 유형의 OS 레벨 페이징을 방지하기 위해 시도 할 수있는 노브가 있습니다. 즉, "LPIM (Page in Memory)"를 켭니다 .
이 Windows 정책은 프로세스를 사용하여 실제 메모리에 데이터를 보관할 수있는 계정을 결정하여 시스템이 디스크의 가상 메모리에 데이터를 페이징하지 못하게합니다.
그렇다면 디스크에 페이징되지 않도록 무엇을 할 수 있습니까?
SQL Server 2012 이전에는 "단일 페이지 할당 자"라는 구성 요소를 통해 할당 된 페이지가 메모리에서 잠겼습니다 (페이징 할 수 없음). 여기에는 버퍼 풀 (데이터베이스 페이지), 프로 시저 캐시 및 기타 메모리 영역이 포함됩니다.
참조 잠긴 된 페이지, AWE, 작업 관리자 및 작업 집합 ... 함께 재미를 , 자세한 내용은 특히 섹션 잠금 페이지 "4. 지금은 SQL 서버가 64에서 사용할 수 있다는 것을 알고" "정확히 잠겨 무엇?" 추가 관련 읽기는 여기에서 찾을 수 있습니다. 훌륭한 SQL Server 토론 : 메모리에서 페이지 잠금
SQL Server 2012 이상에는 "단일 페이지 할당 자"가 없습니다 ( 메모리를 심도있게 살펴 보는 단일 및 다중 페이지 할당 자 -SQL Server 2012/2014 ). 정확하게보고 할 수있는 것과 불가능한 것에 대한 세부 사항은 내가 본 곳에서 자세히 설명되어 있지 않습니다. 당신은 쿼리를 사용하여 다음과 같은 것을 볼 수 있다 잠금 :
select osn.node_id, osn.memory_node_id, osn.node_state_desc, omn.locked_page_allocations_kb
from sys.dm_os_memory_nodes omn
inner join sys.dm_os_nodes osn on (omn.memory_node_id = osn.memory_node_id)
where osn.node_state_desc <> 'ONLINE DAC'동일한 MS 지원 기사에 따라 DBCC MEMORYSTATUS"잠긴"메모리 양을 확인할 수도 있습니다 .
참고로, 오류 로그에서 OS에 의해 SQL Server의 작업 세트가 페이징되고 있다는 증거를 볼 수 있습니다. 다음과 같은 메시지가 나타납니다.
2019-09-02 10 : 19 : 27.29 spid11s SQL Server 프로세스 메모리의 상당 부분이 페이징 아웃되었습니다. 성능이 저하 될 수 있습니다. 지속 시간 : 329 초 작업 세트 (KB) : 68780, 커밋 (KB) : 244052, 메모리 사용률 : 28 %
최신 버전의 SQL Server는 완전히 끊어 질 가능성이 거의 없습니다. SQL Server는 .NET Framework를 해당 주소 공간에로드하고 정상적인 작업에서 사용합니다. 실제 메모리와 페이지 파일이 모두 소모되면 Windows는 페이지 파일을 늘리려 고 시도합니다. 그러나 페이지 파일을 늘릴 수 있더라도 이는 즉각적인 작업이 아니며 페이지 파일이 커지는 동안 메모리 할당이 실패합니다. .NET 비동기식 I / O 핸들러에는 APC 알림에 대한 응답으로 메모리를 할당하는 버그가 있습니다. 호출이 new실패하면OutOfMemoryException. 이 예외는 작업 스케줄러 내부의 기본 코드에서 발견됩니다. 그러나 비동기 I / O는 완료되지 않은 것으로 보입니다. FileStream의 종료 자 스레드는 I / O가 완료되기를 기다리는 것을 차단하여 버퍼를 고정 해제하여 종료 자 스레드를 영구적으로 중단합니다. 이로 인해 .NET Framework는 메모리를 더 이상 할당 할 수 없을 때까지 점점 더 많은 메모리를 점진적으로 사용하게됩니다.이 시점에서 winsock이 더 이상 버퍼를 할당 할 수 없으므로 관리자 액세스 연결조차도 쓸모 없기 때문에 SQL Server가 응답하지 않습니다.
실제로 메모리 부족으로 인해 .NET 응용 프로그램에서 작업 스케줄러 총 끊기가 발생했습니다. 고맙게도 프로세스는 OutOfMemoryException몇 번의 실패 후에 그것을 잡지 않은 스레드 를 던져서 실제로 죽어 실제로 서버에 걸려있는 것이 무엇인지 알아낼 수있었습니다.
내가 무엇을 찾고 있는지 알면 정적 분석에서 버그를 찾는 것이 쉬웠습니다.