SQL Server 캐시 플러시 및 디스크 I / O

우리는 .NET 4.0에서 개발 한 OLTP 시스템을로드 테스트 중이며 뒤에서 SQL Server 2008 R2를 실행하고 있습니다. 이 시스템은 성능이 뛰어난 SQL Server Service Broker 큐를 사용하지만 처리하는 동안 독특한 추세를 경험하고 있습니다.

SQL Server는 1 분 동안 블리 스터링 속도로 요청을 처리 한 다음 ~ 20 초의 디스크 쓰기 작업을 증가시킵니다. 다음 그래프는 문제를 보여줍니다.

Yellow = Transactions per second
Blue   = Total CPU usage
Red    = Sqlsrv Disk Write Bytes/s
Green  = Sqlsrv Disk Read Bytes/s

문제 해결 과정에서 패턴을 크게 변경하지 않고 다음을 시도했습니다.

• SQL Server 에이전트를 중지했습니다.
• 거의 모든 다른 실행중인 프로세스를 종료했습니다 (No A / V, SSMS, VS, Windows Explorer 등)
• 다른 모든 데이터베이스를 제거했습니다.
• 모든 대화 타이머를 비활성화했습니다 (트리거를 사용하지 않음).
• 메시지 큐 기반 접근 방식에서 단순 / 원유 테이블 모니터링 설계로 이동했습니다.
• 가벼운 것에서 무거운 것까지 다른 하중을 사용했습니다.
• 모든 교착 상태를 수정했습니다.

SQL Server가 캐시를 구축하고 특정 시간 기반 간격으로 디스크에 쓰는 것처럼 보이지만이 이론을 지원하기 위해 온라인에서 아무것도 찾을 수 없습니다.

다음으로 문제를 복제 할 수 있는지 확인하기 위해 솔루션을 전용 테스트 환경으로 옮길 계획입니다. 중간에 도움이 될 것입니다.

업데이트 1 요청에 따라 Checkpoint Pages / Sec , Page Life Expectancy 및 일부 디스크 대기 시간 카운터 를 포함하는 그래프가 있습니다 .

Checkpoint (연한 파란색 선)가 관찰중인 성능 저하 (노란색 선)의 원인 인 것처럼 보입니다. ^

디스크 대기 시간은 처리 과정에서 비교적 일정하게 유지되며 페이지 수명은 눈에 띄는 영향을 미치지 않는 것 같습니다. 또한 SQL Server에 사용할 수있는 램의 양을 조정했지만 큰 영향을 미치지 않았습니다. 에서 복구 모델 변경 SIMPLE에 FULL또한 만들어 약간의 차이.

업데이트 2 다음과 같이 "복구 간격"을 변경하여 검사 점이 발생하는 간격을 줄였습니다.

EXEC sp_configure 'show advanced options',1
GO 

RECONFIGURE
GO

EXEC sp_configure 'recovery interval', '30'
GO

RECONFIGURE 
GO

EXEC sp_configure 'show advanced options',0
GO
RECONFIGURE

이것이 나쁜 습관인지 확실하지 않습니까?

다른 사람들은 이미 범인을 지적했습니다. SQL Server는 버퍼 풀의 메모리에 업데이트를 누적하고 주기적으로 (체크 포인트에서) 플러시합니다. 제안 된 두 가지 옵션 (-k 및 검사 점 간격)은 보완 적입니다.

• -k 는 체크 포인트가 덜 적극적인 IO 요청 을 생성 하고 더 오래 지속 되게하는 원인이됩니다.
• 복구 간격 을 줄이면 검사 점이 더 자주 시작됩니다.

그러나 나는 당신이받은 훌륭한 의견을 regurgitate에만 응답하지 않았습니다 :)

안타깝게도 대기열 처리 의 매우 일반적인 동작입니다 . Service Broker 큐를 사용하든 큐에 접근 할 때 테이블 을 사용 하도록 선택하든 시스템은 이러한 종류의 동작에 매우 취약합니다. 큐 기반 처리는 쓰기가 많고 OLTP 처리보다 쓰기가 더 많기 때문입니다. 두 대기열 및 대기열에서 제외 프리미티브 쓰기 작업하고 거의 읽기 작업이 있습니다. 간단히 말해서, 대기열 처리는 다른 모든 워크로드, OLTP (예 : 워크로드와 같은 TPC-C )에 비해 가장 많은 쓰기 (= 가장 더러운 페이지 및 대부분의 로그)를 생성합니다 .

큐 워크로드의 쓰기는 삽입 / 삭제 패턴을 따릅니다. 삽입 된 모든 행이 매우 빠르게 삭제됩니다. 이는 인서트 무거운 (ETL) 워크로드의 추가 전용 패턴과 구별하기 위해 중요합니다. 당신은 기본적으로 고스트 정리 작업에 전체 식사를 제공하고 있으며, 쉽게 초과 할 수 있습니다. 그것이 무엇을 의미하는지 생각해보십시오.

• enqueue는 삽입입니다. 더티 페이지를 만듭니다.
• dequeue는 삭제입니다. 같은 페이지를 다시 더럽힐 것입니다 (행운하고 체크 포인트 전에 페이지를 잡을 수 있으므로 이중 플러시를 피할 수는 있지만 운이 좋은 경우에만)
• 고스트 정리는 페이지를 정리하여 다시 더러워집니다.

그렇습니다. 실제로 처리하는 각 메시지 (가장 최악의 경우)에 대해 세 개의 다른 IO 요청으로 디스크에 페이지를 세 번 쓰게 될 수 있습니다. 또한 두 개의 체크 포인트 사이에서 다시 헤드를 이동하는 사람들이 페이지의 쓰기 포인트를 방문 하므로 체크 포인트의 임의 IO가 실제로 임의적 임을 의미합니다 (많은 OLTP 워크로드와 비교하여 일부 '핫스팟'에서 쓰기를 그룹화하는 경향이 있음) 대기열이 아닙니다 ...).

따라서이 세 가지 쓰기 지점이 있으며 같은 페이지를 반복해서 더럽게 표시 합니다. 그리고 페이지 분할을 고려하기 전에 삽입 키 순서로 인해 대기열 처리 가 시작될 수 있습니다. '일반적인'OLTP 워크로드는 훨씬 더 균형 잡힌 읽기 / 쓰기 비율을 가지며 OLTP 쓰기는 종종 업데이트 ( '상태'변경) 및 삽입물이 가장 큰 비중을 차지하는 삽입 / 업데이트 / 삭제에 분산됩니다. 큐 처리 쓰기는 정의에 따라 50/50 분할을 통해 독점적으로 삽입 / 삭제됩니다.

몇 가지 결과는 다음과 같습니다.

• Checkpoint는 매우 뜨거운 문제가되었습니다 (더 이상 놀랄 일이 아닙니다)
• 심각한 조각화가 나타납니다 (범위 조각화를 수행하지 않아도 조각화 자체는 중요하지 않지만 IO 효율성이 저하되고 고스트 정리가 더 많이 작동하여 속도가 느려집니다)
• MDF 스토리지 임의 IO 처리량은 병목 현상이 될 것입니다

내 추천은 S, S 및 D의 3 글자로되어 있습니다. MDF를 빠른 임의 IO를 처리 할 수있는 스토리지로 옮기십시오. SSD. 돈이 있다면 Fusion-IO . 불행히도 이것은 더 저렴한 RAM으로 해결할 수없는 증상 중 하나입니다 ...

편집하다:

Mark가 지적한 것처럼 하나의 물리 디스크가 지원하는 두 개의 논리 디스크가 있습니다. 아마도 모범 사례를 따르고 D : 및 C :의 데이터에 대한 로그를 분할하려고했지만 아아는 사용할 수 없으며 C와 D는 동일한 디스크입니다. 체크 포인트간에 순차적 처리량을 달성하지만 체크 포인트가 시작 되 자마자 디스크 헤드가 이동하기 시작하고 로그 처리량이 축소되어 전체 앱 처리량이 줄어 듭니다. 데이터 IO (별도의 디스크)의 영향을받지 않도록 DB 로그를 분리하십시오.