SQL Server의 메모리 내 OLTP에 대한 하드웨어 고려 사항
메모리 내 OLTP는 메모리 및 디스크를 기존 디스크 기반 테이블과 다른 방식으로 사용합니다. 메모리 내 OLTP에서 볼 수 있는 성능 향상은 사용하는 하드웨어에 따라 달라집니다. 이 문서에서는 몇 가지 일반적인 하드웨어 고려 사항에 대해 설명하고 메모리 내 OLTP와 함께 사용할 하드웨어에 대한 일반적인 지침을 제공합니다.
참고 항목
이 문서는 Microsoft SQL Server 2014 팀이 2013년 8월 1일에 게시한 블로그입니다. 블로그 웹 페이지가 사용 중지됩니다.
CPU
메모리 내 OLTP는 높은 처리량 OLTP 워크로드를 지원하기 위해 하이 엔드 서버가 필요하지 않습니다. 두 개의 CPU 소켓이 있는 중간 범위 서버를 사용하는 것이 좋습니다. 메모리 내 OLTP에서 사용하도록 설정된 처리량 증가로 인해 두 개의 소켓이 비즈니스 요구 사항에 충분할 수 있습니다.
메모리 내 OLTP를 사용하여 SMT(동시 다중 스레딩)를 켜는 것이 좋습니다. 일부 OLTP 워크로드에서는 SMT를 사용할 때 성능이 최대 40%까지 향상되었습니다.
메모리
모든 메모리 최적화 테이블은 메모리에 완전히 상주합니다. 따라서 테이블 자체에 충분한 실제 메모리가 있어야 하며 데이터베이스에 대해 실행되는 워크로드를 유지해야 합니다. 실제로 필요한 메모리의 크기는 워크로드에 따라 달라지지만, 시작점으로는 데이터 크기의 약 2배에 충분한 사용 가능한 메모리가 필요합니다. 워크로드가 기존 디스크 기반 테이블에서도 작동하는 경우에도 버퍼 풀에 충분한 메모리가 필요합니다.
지정된 메모리 최적화 테이블에서 사용하는 메모리 양을 확인하려면 다음 쿼리를 실행합니다.
select object_name(object_id), * from sys.dm_db_xtp_table_memory_stats;
결과는 메모리 최적화 테이블 및 해당 인덱스에 사용되는 메모리를 보여 줍니다. 테이블 데이터에는 사용자 데이터와 트랜잭션을 실행하는 데 여전히 필요하거나 시스템에서 아직 클린 않은 모든 이전 행 버전이 포함됩니다. 해시 인덱스에 사용되는 메모리는 상수이며 테이블의 행 수에 따라 달라지지 않습니다.
메모리 내 OLTP를 사용할 때는 전체 데이터베이스가 메모리에 맞지 않아도 되므로 주의해야 합니다. 핫 데이터(즉, 메모리 최적화 테이블)의 크기가 256GB를 초과하지 않는 한 다중 테라바이트 데이터베이스를 사용할 수 있으며 메모리 내 OLTP의 이점을 누릴 수 있습니다. SQL Server에서 단일 데이터베이스에 대해 관리할 수 있는 검사포인트 데이터 파일의 최대 수는 4,000개이며 각 파일은 128MB입니다. 이론적 최대값은 512GB이지만 SQL Server가 검사point 파일 병합을 계속 수행하고 4,000개의 파일 제한에 도달하지 않도록 하기 위해 최대 256GB를 지원합니다. 이 제한은 메모리 최적화 테이블에만 적용됩니다. 동일한 SQL Server 데이터베이스의 기존 디스크 기반 테이블에는 이러한 크기 제한이 없습니다.
내구성이 없는 NDT(메모리 최적화 테이블) 즉, DURABILITY=SCHEMA_ONLY 메모리 최적화 테이블은 디스크에 유지되지 않습니다. NDT는 검사포인트 파일 수로 제한되지 않지만 256GB만 지원됩니다. 데이터가 메모리에만 존재하기 때문에 이 게시물의 re기본der에 있는 로그 및 데이터 드라이브에 대한 고려 사항은 비지속 테이블에 적용되지 않습니다.
로그 드라이브
메모리 최적화 테이블과 관련된 로그 레코드는 다른 SQL Server 로그 레코드와 함께 데이터베이스 트랜잭션 로그에 기록됩니다.
트랜잭션이 너무 오래 기다릴 필요가 없도록 대기 시간이 짧은 드라이브에 로그 파일을 배치하고 로그 I/O에서 경합을 방지하는 것이 항상 중요합니다. 시스템은 가장 느린 구성 요소(Amdahl의 법칙)만큼 빠르게 실행됩니다. 메모리 내 OLTP를 실행할 때 로그 I/O 디바이스가 병목 상태가 되지 않도록 해야 합니다. 대기 시간이 짧은 스토리지 디바이스, 적어도 SSD를 사용하는 것이 좋습니다.
메모리 최적화 테이블은 인덱스 작업을 기록하지 않고 UNDO 레코드를 기록하지 않으므로 디스크 기반 테이블보다 로그 대역폭을 적게 사용합니다. 이렇게 하면 로그 I/O 경합을 완화하는 데 도움이 될 수 있습니다.
데이터 드라이브
검사point 파일을 사용하는 메모리 최적화 테이블의 지속성은 스트리밍 I/O를 사용합니다. 따라서 이러한 파일은 대기 시간이 짧거나 임의 I/O가 빠른 드라이브가 필요하지 않습니다. 대신 이러한 드라이브의 기본 요소는 HBA(호스트 버스 어댑터)의 순차 I/O 및 대역폭의 속도입니다. 따라서 검사포인트 파일에는 SSD가 필요하지 않습니다. 순차 I/O 속도가 요구 사항을 충족하는 한 고성능 스핀들(예: SAS)에 배치할 수 있습니다.
속도 요구 사항을 결정하는 가장 큰 요인은 서버 다시 시작 시 RTO [복구 시간 목표]입니다. 데이터베이스를 복구하는 동안 메모리 최적화 테이블의 모든 데이터를 디스크에서 메모리로 읽어 들여야 합니다. 데이터베이스 복구는 I/O 하위 시스템의 순차적 읽기 속도로 발생합니다. 디스크가 병목 상태입니다.
엄격한 RTO 요구 사항을 충족하려면 MEMORY_OPTIMIZED_DATA 파일 그룹에 여러 컨테이너를 추가하여 검사point 파일을 여러 디스크에 분산하는 것이 좋습니다. SQL Server는 여러 드라이브에서 검사점 파일을 병렬로 로드하는 것을 지원하여, 복구는 드라이브의 합산 속도로 진행됩니다.
디스크 용량 측면에서는 메모리 최적화 테이블 크기의 2~3배를 사용할 수 있는 것이 좋습니다.