RAM 디스크의 SQL Server tempdb?

벤더 애플리케이션 데이터베이스는 매우 TempDB를 많이 사용합니다.

서버는 40 개의 코어와 768GB RAM의 가상 (VMWare)이며 SQL 2012 Enterprise SP3을 실행합니다.

TempDB를 포함한 모든 데이터베이스는 SAN의 Tier 1 SSD에 있습니다. 10 개의 tempdb 데이터 파일이 있으며 각 파일은 1GB로 미리 자라지 않으며 자동으로 자라지 않습니다. 70GB 로그 파일과 동일합니다. 추적 플래그 1117 및 1118이 이미 설정되어 있습니다.

sys.dm_io_virtual_file_stats는 지난 달 tempdb 데이터 및 로그 파일에서 50 테라 바이트 이상의 읽기 / 쓰기를 보여 주며 누적 io_stall은 250 시간 또는 10 일입니다.

우리는 이미 2 년 동안 공급 업체의 코드와 SP를 조정했습니다.

이제 우리는 많은 메모리를 가지고 있기 때문에 tempdb 파일을 RAM 드라이브에 배치하려고합니다. 서버가 재부팅 될 때 tempdb가 소멸 / 재 작성되므로 서버가 재부팅 될 때 플러시되는 휘발성 메모리에 배치하는 것이 이상적입니다.

나는 이것을 더 낮은 환경에서 테스트했으며 CPU가 느린 tempdb 드라이브를 기다리는 대신 더 많은 작업을 수행하기 때문에 쿼리 시간은 빨라지지만 CPU 사용량은 증가했습니다.

다른 사람이 높은 oltp 프로덕션 시스템에서 tempdb를 RAM에 넣었습니까? 큰 단점이 있습니까? 구체적으로 선택하거나 피해야 할 공급 업체가 있습니까?

sql-server tempdb

— d -_- b
소스

공급 업체가 tempDB를 너무 많이 사용하고 있습니까?

— paparazzo

@Max, 그 질문은 'tempdb 쓰기가 디스크로 이동하는지 여부'문제의 일부에 대해서만 답변합니다. tempdb에서 읽지 않음

— d -_- b

SAN 수준에서 SSD를 사용한다고해서 실제로 네트워크 대기 시간으로 인해 많은 이점을 얻지는 못합니다. NVMe SSD를 SQL Server에 넣고 tempdb를 실행하십시오.

— Max Vernon

방금 'nvme ssd vs ramdisk'를 검색했으며 첫 번째 결과는 후자가 ~ 3 배 빠르다고 주장하는 레딧 게시물입니다. 또한 데이터 센터로 운전하여 블레이드에 설치하는 것보다 쉽습니다. :)

— d -_- b

Microsoft는 일부 클러스터에서 PCI-E FusionIO 카드를 사용합니다 (사용하는 로컬 디스크와 함께 tempdb를 계속 사용할 수있는 약간의 해결 방법이 있습니다). Max가 지적한 PCI-E 인터페이스는 훨씬 빠릅니다. 초당 더 많은 요청을 받고 있는지 측정하기 위해 초당 CPU 인터럽트를 측정하려고합니다. 디스크 대기 시간은 인터럽트 요청이 적은 주요 원인 중 하나이므로 (SQL 시간 아님)

— Ali Razeghi

답변:

먼저 패치 : 2012 서비스 팩 1 누적 업데이트 10 이상을 사용하고 있는지 확인하십시오. SQL 2014 년, 마이크로 소프트는로 임시 데이터베이스를 변경 하면 디스크에 기록 덜 열망 , 그들은 놀랍 2012 SP1 CU10으로 백 포트 즉 임시 데이터베이스 쓰기 많은 압력을 완화 할 수 있습니다.

둘째, 지연 시간에 대한 정확한 수치를 얻으십시오. sys.dm_io_virtual_file_stats 를 확인 하여 TempDB 파일의 평균 쓰기 중단 을 확인하십시오. 가장 좋아하는 방법은 다음과 같습니다.

sp_BlitzFirst @ExpertMode = 1, @Seconds = 30 /* Checks for 30 seconds */
sp_BlitzFirst @SinceStartup = 1 /* Shows data since startup, but includes overnights */

파일 통계 섹션을보고 실제 쓰기에 중점을 둡니다. SinceStartup 데이터는 CHECKDB가 실행되는 시간도 포함하기 때문에 약간 오해의 소지가 있으며, 이는 실제로 TempDB를 손상시킬 수 있습니다.

평균 쓰기 대기 시간이 3ms를 초과하면 SAN에 솔리드 스테이트 스토리지가있을 수 있지만 여전히 빠르지는 않습니다.

TempDB 용 로컬 SSD를 먼저 고려하십시오. 좋은 로컬 SSD (예 : 크기가 $ 2k 미만인 Intel의 PCIe NVMe 카드와 같은)는 공유 스토리지로 달성 할 수있는 것보다 대기 시간이 매우 낮습니다. 그러나 가상화에서는 단점이 있습니다. 게스트를 한 호스트에서 다른 호스트로 vMotion하여로드 또는 하드웨어 문제에 대응할 수는 없습니다.

마지막으로 RAM 드라이브를 고려하십시오. 이 접근법에는 두 가지 큰 문제가 있습니다.

첫째, 실제로 TempDB 쓰기 활동이 많은 경우 메모리의 변경 률이 너무 높아서 모든 사람이 알지 못하는 한 게스트를 다른 호스트로 vMotion하지 못할 수 있습니다. vMotion 중에는 한 호스트에서 다른 호스트로 RAM의 내용을 복사해야합니다. 실제로 vMotion 네트워크를 통해 복사 할 수있는 것보다 빠르게 빠르게 변경되는 경우 문제가 발생할 수 있습니다 (특히이 상자가 미러링, AG 또는 장애 조치 클러스터와 관련된 경우).

둘째, RAM 드라이브는 소프트웨어입니다. 내가 한로드 테스트에서 실제로 TempDB 활동이 심한 경우 속도에 감명을받은 것은 아닙니다. 엔터프라이즈 급 SSD를 유지할 수 없을 정도로 무거 우면 RAM 드라이브 소프트웨어에 부담을주게됩니다. 라이브로 가기 전에이 테스트를 많이로드하고 싶을 것입니다. 다른 인덱스에서 동시 인덱스 재 구축과 같은 작업을 모두 sort-in-tempdb를 사용하여 시도하십시오.

— 브렌트 오자
소스

RAM 드라이브를 만드는 것은 쉽지 않습니다. 부팅 가능한 많은 Linux 썸 드라이브 및 광학 드라이브는 RAM 드라이브를 생성하고 여기에 OS 파일을 저장합니다. 루트 파일 시스템은 메모리에 있습니다. 당시에는 Windows에서 config.sys에 RAM 드라이브가 장치 드라이버로로드되었습니다. 일반적으로 드라이버는 높은 메모리에로드되었습니다. 제 생각에는 이것이 매우 좋고 간단한 해결책입니다. RAM 드라이브를 사용하여 솔루션을 만든 경우 듣고 싶습니다. 비슷한 작업을하고 싶지만 영구 저장소에 쓰고 DB를 RAM에 저장하고 싶습니다. 제 경우에는 OS가 사용할 수있는 것보다 많은 RAM을 설치할 수있는 기계가 있습니다. OS가로드되기 전에 RAM 디스크를 만들면 OS가 다르게 볼 수없는 RAM을 사용할 수 있습니다.

— 에드워드 코일
소스