 64비트 플랫폼에서 SQL Server 통합 교훈 게시 날짜: 2004년 5월 1일저자 : Mike Ruthruff 요약: Microsoft는 서로 다른 실제 컴퓨터에 배치되었던 기존의 Microsoft SQL Server 인스턴스를 통합하기 위한 64비트 서버를 구축하여 운영하는 시나리오를 테스트했습니다. 이 문서에서는 그러한 테스트를 통해 얻은 결과에 대해 설명합니다. 개요 여러 SQL Server 데이터베이스를 서버 하나에 통합하기 위한 방법을 결정할 때는 여러 가지 사항을 고려하고 평가해야 합니다. 이때 고려해야 할 중요한 사항 중 하나는 최상의 통합 결과를 얻기 위해 64비트 플랫폼을 사용할 것인지 32비트 플랫폼을 사용할 것인지 판단하는 일입니다. 64비트 플랫폼을 사용하면 32비트 플랫폼에 비해 몇 가지 이점을 얻을 수 있습니다. 예를 들어, 32비트 플랫폼에서는 몇 가지 기술적인 제한으로 인해 다중 인스턴스를 사용해야 할 수도 있습니다. 그러나 64비트 플랫폼의 경우 SQL Server의 다중 인스턴스를 사용할지 여부를 결정하는 데는 플랫폼으로 인한 기술적인 제한보다 데이터 관리를 위한 필요성이 더 중요한 요인으로 작용합니다. Microsoft는 물리적으로 서로 다른 컴퓨터에 배치되었던 기존의 SQL Server 인스턴스를 통합하기 위한 64비트 서버를 구축하여 운영하는 시나리오를 테스트했습니다. 이 문서에서는 그러한 테스트를 통해 얻은 결과에 대해 설명합니다. 여기에는 64비트 플랫폼에서 Microsoft SQL Server를 사용하여 통합을 수행하는 방법에 대한 예제도 나와 있습니다. 이 문서에서는 특히 다음과 같은 내용을 제공합니다.
이 문서는 SQL Server 데이터베이스 통합을 계획하는 단계에서 발생할 수 있는 모든 질문에 대한 답변을 제공하기 위한 것이 아닙니다. 또한, 이 문서에 나와 있는 시나리오의 결과를 모든 통합 환경에 적용할 필요는 없습니다. SQL Server 통합을 위한 환경을 성공적으로 선택하고 구축하는 데 필요한 계획과 관련하여 자세한 내용은 부록 C에 나와 있는 "Microsoft SQL Server 2000을 사용한 통합 계획"(영문) 자료를 참조하십시오. SQL Server 통합을 위해 Microsoft가 제공하는 서비스에 대한 자세한 내용은 부록 C의 "Microsoft 제공 서비스"(영문) 자료를 참조하십시오.
64비트 통합 환경 구성 호스트 하드웨어 구성이 문서에 나와 있는 테스트 시나리오에는 NEC Express5800/1320Xd 64비트 서버가 호스트 하드웨어로 사용되었습니다. 이 서버는 32개의 1.5GHz Intel Itanium II 프로세서와 64GB의 RAM으로 구성되었습니다. 서버는 16개의 프로세서로 구성된 두 개의 개별 파티션으로 분할되고, 각 파티션에는 전체 메모리의 절반에 해당하는 32GB의 메모리가 할당되었습니다. 각 파티션은 4개의 Emulex LP9002 HBA(호스트 버스 어댑터)로 구성했습니다. 16개의 프로세서로 구성된 두 파티션 중 하나만 테스트 통합 시나리오에 사용했습니다. 저장소 구성이 문서의 테스트 시나리오에 사용된 저장소는 NEC Storage S4300 디스크 배열로 구성되었으며 이 저장소는 모든 SQL Server 데이터 파일을 저장하는 데 사용되었습니다. 이 디스크 배열은 테스트 시나리오에 사용될 뿐만 아니라 연결되지 않은 SQL Server 작업 부하를 테스트하기 위해 NEC Express5800/1320Xd의 두 번째 파티션에도 동시에 사용되었습니다. 실제 구축 환경에서는 이러한 상황이 일반적으로 발생하며 이 경우 여러 호스트에서 SQL Server 작업 부하에 동일한 저장소 배열을 사용하게 됩니다. 테스트를 실행하는 동안 실제 디스크 수준에서 충돌이 발생하지 않도록 하기 위해 개별 실제 디스크의 각 파티션에 LUN(논리 단위 번호)이 사용되도록 NEC Storage S4300을 구성했습니다. 저장소 통합 부분에 사용되는 LUN은 총 56개의 실제 스핀들(또는 실제 디스크)에 걸쳐 분산되었습니다. 전체적으로 약 1TB의 용량에 달하는 4개의 LUN을 만들고 Microsoft Windows에 제공했습니다. 이 문서에 나와 있는 테스트 시나리오에 사용된 저장소 구성에 대한 자세한 내용은 부록 B를 참조하십시오. 단일 인스턴스 및 다중 인스턴스 비교 64비트 플랫폼을 사용하여 통합할 때의 주요 이점 중 하나는 SQL Server의 단일 인스턴스 내에서 확장할 수 있다는 점입니다. 32비트 플랫폼에서 실행되는 응용 프로그램과 달리 64비트 플랫폼에서 실행되는 응용 프로그램은 훨씬 더 큰 가상 주소 공간을 활용할 수 있습니다. 32비트 플랫폼의 경우 응용 프로그램에 사용할 수 있는 가상 주소 공간은 최대 4GB로 제한되고 2GB는 커널 사용을 위해 예비되어 있습니다. 64비트 플랫폼에서는 더 큰 가상 주소 공간을 사용할 수 있으므로 단일 인스턴스 내에서 더 많은 통합을 수행할 수 있고, 여러 데이터베이스를 통합하려는 경우나 지원해야 할 연결된 사용자 수가 많은 경우 또는 잠금 및 프로시저 캐시 같은 구조에 대한 메모리 요구 사항 때문에 이전에 서버를 다중 인스턴스로 분할해야 했던 경우 등의 시나리오에서 이러한 이점을 활용할 수 있습니다. 32비트 플랫폼에서도 /3GB, /PAE 및 AWE(Address Windowing Extensions) 같은 구성 옵션을 사용하여 SQL Server가 더 많은 양의 메모리를 활용하도록 만들 수 있지만 이러한 옵션을 사용할 때는 다음과 같은 사항을 고려해야 합니다.
64비트 플랫폼에서는 32비트 플랫폼보다 훨씬 더 많은 가상 주소 공간을 활용할 수 있으므로 단일 인스턴스를 사용할지 다중 인스턴스를 사용할지 결정할 때 좀더 융통성을 발휘할 수 있습니다. 64비트 플랫폼의 가상 주소 공간은 이론적으로 약 18엑사바이트까지 사용할 수 있습니다. 현재 64비트 버전의 SQL Server 2000은 최대 512GB의 메모리를 지원하고 주소 공간의 사용자 부분에서 데이터 구조가 배치될 수 있는 위치에 아무런 제한이 없습니다. SQL Server 통합 시나리오에서 SQL Server의 다중 인스턴스를 구축할지 결정할 때는 여러 가지 사항을 고려해야 합니다. 이러한 고려 사항에는 응용 프로그램 호환성, 작업 부하 격리, 유지 관리 융통성, 가용성 요구 사항 및 보안 등이 포함됩니다. 단일 서버에서 SQL Server의 다중 인스턴스를 사용하면 이러한 문제를 모두 해결할 수 있습니다. 이러한 각 문제에 대한 자세한 설명은 이 문서의 부록 A에 있는 "Microsoft SQL Server 2000을 사용한 통합 계획"(영문) 자료를 참조하십시오. SQL Server의 다중 인스턴스와 단일 인스턴스를 실행할 때 성능에 미치는 영향을 분명하게 확인할 수 있도록 Microsoft는 동일한 작업 부하를 사용하여 두 시나리오를 테스트했습니다. 그러나 테스트 결과를 검토하기 전에 서로 다른 데이터베이스의 특성과 테스트 시나리오에 관련된 작업 부하를 이해할 필요가 있습니다. 데이터베이스 및 작업 부하테스트 통합 시나리오에 대해 Microsoft는 개별 서버에 있던 기존의 실제 프로덕션 데이터베이스에서 여러 가지 데이터베이스와 작업 부하를 선택하여 사용했습니다. 데이터베이스는 총 10개의 서버에서 선택했으며 각 서버에는 1개에서 15개 사이의 데이터베이스가 포함되어 있었습니다. 사용된 데이터베이스는 모두 63개였으며, 2MB에서 85GB에 이르기까지 약 7GB의 평균 크기를 보였습니다. 관련된 모든 데이터베이스의 누적 데이터 크기는 약 460GB였습니다. 선택된 데이터베이스를 사용하여 테스트를 위한 두 가지 구성 시나리오를 설정했습니다.
통합 서버에 테스트할 작업 부하를 만들기 위해 개별 인스턴스 각각에 대해 SQL 프로필러 추적을 캡처하고 재생했습니다. 각 구성에 대해 동일한 작업 부하를 실행하고 Windows 성능 모니터를 사용하여 각 테스트 과정에서 성능을 모니터링했습니다. SQL 프로필러 추적 파일의 작업 부하는 다양하게 구성되어 있지만, 그 중 대부분은 기존의 데이터를 수정하고 새 데이터를 삽입하는 트랜잭션 쿼리로 이루어진 OLTP(온라인 트랜잭션 처리) 작업 부하입니다. 크기가 작은 쓰기 작업을 매우 많이 수행하는 이러한 작업 부하의 I/O 특성에 따라 매우 큰 로그 볼륨 트래픽이 발생하고 읽기/쓰기 작업 일부가 데이터 볼륨에 대해 수행됩니다. 데이터 파일에 대해 실행되는 대부분의 읽기 작업은 선택적입니다. 즉, 크기가 작은 읽기 작업이 수행됩니다. 위에서 설명한 작업 부하 이외에도 통합 환경에서 시스템 성능 전반에 미치는 영향을 더 확실하게 캡처하기 위해 작업 부하를 재생하여 I/O 특성이 서로 다른 작업 부하가 동시에 실행되는 추가 테스트를 수행했습니다. 이 작업 부하의 하위 집합에는 병렬 실행 계획이 포함된 복잡한 쿼리로 이루어진 DSS(의사 결정 지원 시스템) 작업 부하가 포함되었습니다. DSS는 RDW(관계형 데이터 웨어하우스)라고도 합니다. 이 작업 부하의 I/O는 데이터 볼륨에 대한 매우 많은 읽기 작업, 매우 적은 로그 트래픽 및 적절한 크기의 데이터베이스(25GB)에 대해 여러 가지 DBCC(데이터베이스 콘솔 명령) 작업(CHECKDB, SHOWCONTIG, DBREINDEX)을 수행하는 유지 관리 작업 부하를 특징으로 합니다. 이러한 추가 작업 부하는 모두 훨씬 많은 I/O를 필요로 합니다. 이러한 작업 부하를 사용한 결과에 대한 자세한 내용은 뒷부분의 "Tempdb 고려 사항" 및 "유형이 다른 작업 부하"를 참조하십시오. sp_configure 저장 프로시저를 통해 SQL Server에 사용할 수 있는 여러 가지 서로 다른 튜닝 옵션을 사용하여 작업 부하 성능을 테스트했습니다. 표 1.1에는 테스트에 사용된 설정이 나와 있습니다. 표 1.1 SP_CONFIGURE 저장 프로시저 설정
단일 인스턴스 및 다중 인스턴스의 성능 비교 작업 부하에 대해 Microsoft가 수행한 테스트 결과를 살펴보면 SQL Server의 단일 인스턴스로 통합할 때 성능이 약간 향상되는 것을 확인할 수 있습니다. 단일 인스턴스 내에서 작업 부하를 실행하면 다중 인스턴스에 걸쳐 구축된 동일한 작업 부하를 실행할 때보다 성능이 약간 향상됩니다. 이 결과는 테스트를 거친 모든 구성에서 동일하게 확인할 수 있었습니다. 그림 1.1은 모든 작업 부하가 활성화된 상태에서 일정 기간 동안 초당 트랜잭션의 평균 수를 측정한 결과를 보여 줍니다. 각 튜닝 옵션과 해당 결과에 대한 보다 자세한 내용은 이 문서의 뒷부분을 참조하십시오.  그림 1.1 단일 인스턴스 및 다중 인스턴스의 섹션별 트랜잭션 비교 성능이 중요한 요소이기는 하지만 단일 인스턴스를 사용할지 다중 인스턴스를 사용할지 결정할 때 이는 고려해야 할 여러 가지 사항 중 하나일 뿐입니다. 이 문서에서 다루고 있지는 않지만 성능 이외에도 고려해야 할 여러 가지 중요한 사항이 있습니다. 자세한 내용은 부록 C의 "Microsoft SQL Server 2000을 사용한 통합 계획"(영문)을 참조하십시오. 64비트 플랫폼에서 SQL Server 메모리 사용 관리 64비트 플랫폼에서는 32비트 플랫폼에서 사용할 수 있는 것보다 훨씬 많은 양의 메모리를 SQL Server에 사용할 수 있습니다. 따라서 서버에서 실행되는 기타 응용 프로그램을 비롯하여 모든 SQL Server 인스턴스가 올바르게 작동하는 데 필요한 충분한 메모리를 할당할 수 있도록 메모리를 구성하는 것이 매우 중요합니다. SQL Server는 항상 Windows가 올바르게 작동할 수 있도록 적어도 128MB의 실제 메모리를 남겨두려고 하지만 상황에 따라서는 SQL Server가 이 메모리를 확보하지 못할 수도 있습니다. 예를 들어, SQL Server의 다중 인스턴스가 동시에 실행되는 경우를 생각해 볼 수 있습니다. 다른 인스턴스가 계속하여 실행되는 동안 유지 관리를 위해 인스턴스 하나를 오프라인 상태로 만들면 서버의 거의 모든 실제 메모리가 소모될 때까지 다른 활성 인스턴스의 메모리 사용량이 증가할 수도 있습니다. 이러한 상황에서 오프라인 상태의 인스턴스가 다시 온라인 상태가 되면 데이터 캐시에 사용할 메모리가 충분하지 않을 수 있습니다. 그 결과로 인스턴스 간에 메모리 사용량을 다시 조정하는 동안 I/O가 증가할 수 있고 이는 I/O 하위 시스템을 사용하는 모든 인스턴스의 성능에 영향을 미칠 수 있습니다. 테스트를 진행하는 동안 각 SQL Server 인스턴스의 최대 서버 메모리 구성 옵션에 대한 최적의 값을 확인하기 위해 각 인스턴스별로 메모리 사용량을 모니터링했습니다. 이 작업에는 메모리 관리자: 총 서버 메모리 성능 모니터 카운터를 사용했습니다. 기본 메모리 설정을 사용하여 인스턴스의 메모리 사용량을 모니터링하면 각 인스턴스별로 잠재적인 메모리 사용량을 확인하는 데 도움이 됩니다. SQL Server의 단일 인스턴스 내에서 통합하는 데 따른 이점 중 하나는 단일 프로세스 안에 메모리 관리가 포함된다는 점입니다. 작업 부하를 테스트하는 동안 버퍼 풀을 더 효율적으로 사용한 결과 I/O 하위 시스템에서 실행된 I/O의 수가 줄어들었고, 궁극적으로는 트랜잭션 처리량이 증가하고 CPU 리소스를 더 효율적으로 사용하는 결과를 가져왔습니다. 일반적으로 SQL Server는 여러 인스턴스에 걸쳐 있는 경우보다 단일 인스턴스 내에서 메모리 사용을 더 쉽게 관리할 수 있습니다. 그림 1.2와 1.3은 다중 인스턴스의 경우와 비교하여 단일 인스턴스에서 SQL Server가 실행한 I/O가 감소하고 있음을 보여 주고, 단일 인스턴스와 다중 인스턴스 사이에 나타나는 프로세서 사용량의 차이를 보여 줍니다.  그림 1.2 단일 인스턴스 및 다중 인스턴스의 초당 총 디스크 읽기 비교  그림 1.3 단일 인스턴스 및 다중 인스턴스의 총 평균 프로세서 사용량 비교 32비트 플랫폼과 64비트 플랫폼 사이에는 SQL Server의 메모리 튜닝 옵션의 동작에 몇 가지 차이점이 있습니다. 이러한 차이에 대한 설명은 표 1.2에 나와 있습니다. 표 1.2 32비트 및 64비트 플랫폼의 메모리 구성 동작 비교
표 1.2에서 알 수 있듯이 64비트 플랫폼에서 최소 서버 메모리 옵션을 구성하면 SQL Server에서 프로세스를 시작할 때 메모리가 예약 및 커밋됩니다. 이러한 작동 방식을 활용하면 특정 인스턴스를 시작할 때 지정된 양의 메모리가 확보되도록 할 수 있지만, SQL Server 인스턴스를 시작할 때 서버에 사용할 최소한의 실제 메모리가 항상 남아 있도록 주의해야 합니다. 이렇게 하지 않으면 Windows 페이징 파일 내에서 가상 메모리를 과도하게 사용하여 전체 시스템의 성능에 부정적인 영향을 미칠 수 있습니다. 64비트 플랫폼에서 SQL Server의 메모리 사용량을 조정할 때는 다음 사항을 염두에 두어야 합니다.
다중 프로세서 시스템의 경우 CPU 리소스와 SQL Server의 상호 작용는 affinity mask와 affinity64 mask 구성 옵션을 설정하여 제어할 수 있습니다. 이러한 옵션을 구성하면 SQL Server의 스레드를 실행할 때마다 해당 스레드를 동일한 프로세서에서 실행하도록 예약됩니다. 이러한 옵션을 구성하지 않으면 프로세서 사이에 스레드가 마이그레이션될 수 있습니다. CPU 선호도 옵션을 사용할 때 고려할 수 있는 시나리오에는 크게 두 가지가 있습니다. CPU 선호도 시나리오 1: 선호도를 사용하여 메모리를 더 효율적으로 사용대부분의 최상위급 다중 프로세서 시스템에서는 이제 NUMA(Non-Uniform Memory Access) 또는 CMP(Cellular MultiProcessing) 아키텍처를 사용합니다. 이 문서에서 설명하고 있는 테스트에 사용된 NEC Express5800/1320Xd는 NUMA 아키텍처를 기반으로 하고 있습니다. NUMA 시스템에서 선호도 마스크 옵션을 설정하면 로컬 프로세서 캐시를 더 효율적으로 사용하여 성능을 향상시킬 수 있습니다. 이러한 방법에 대한 자세한 내용은 부록 C의 자료를 참조하십시오. 이 시나리오를 테스트하는 동안 모든 SQL Server 인스턴스에 대해 선호도 마스크 옵션을 65,535로 구성했습니다. 이 값은 비트 마스크 프로세서당 1비트를 나타내는 '1111111111111111'에 해당합니다. 테스트에 사용된 작업 부하의 경우 SQL Server 인스턴스를 이와 같은 방식으로 구성하여 전체 처리량이 약간 낮아지는 결과를 얻었습니다. 위의 그림 1.1을 참조하십시오. 그러나 이 설정을 사용하여 얻을 수 있는 결과는 각 작업 부하의 특성에 따라 다를 수 있다는 사실을 기억해야 합니다. 이 옵션을 설정하여 특정 작업 부하에 대한 성능을 향상시킬 수 있는지 확인하려면 각 상황별로 테스트를 수행하는 것이 좋습니다. 그림 1.4와 그림 1.5에서는 SQL Server의 단일 인스턴스 및 다중 인스턴스를 테스트하는 동안 선호도 마스크 옵션을 설정한 결과를 보여 줍니다.  그림 1.4 단일 인스턴스 및 다중 인스턴스의 프로세서 대기열 길이 비교 그림 1.4는 선호도 마스크 옵션을 설정한 경우와 설정하지 않은 경우의 프로세서 대기열 길이를 보여 줍니다. 프로세서 대기열 길이는 실행할 준비가 되었지만 프로세서를 사용할 수 있을 때까지 대기열에서 기다리는 스레드의 수입니다. 이 테스트 시나리오의 경우 선호도 마스크 옵션을 설정한 결과 프로세서 대기열 길이가 증가했습니다. 작업량이 많지 않은 CPU에서 실행되는 대신 특정 프로세서를 사용할 수 있게 될 때까지 스레드가 대기해야 했습니다. 여기에 나와 있는 프로세서 대기열 길이를 현재 사용 중인 하드웨어에서 수용할 수 없는 것은 아니지만 관련 프로세서의 사용률이 더 낮을수록 전체 CPU가 완전히 활용되지 않고 있음을 나타냅니다.  그림 1.5 단일 인스턴스 및 다중 인스턴스의 초당 컨텍스트 스위치 비교 그림 1.5는 초당 컨텍스트 스위치의 평균 수를 보여 줍니다. 컨텍스트 스위칭은 다른 스레드가 프로세서에 전달되는 경우 처리할 해당 컨텍스트를 로드해야 할 때 발생합니다. 선호도 마스크 설정을 사용하면 컨텍스트 스위치가 줄어들지만 CPU 리소스가 완전하게 활용되지 않는 결과도 보였습니다. Microsoft가 수행한 모든 테스트에서 초당 컨텍스트 스위치 수는 작업 부하를 SQL Server의 단일 인스턴스에 대해 실행할 때 더 줄어들었습니다. CPU 선호도 시나리오 2: CPU 리소스 분할선호도 마스크 옵션을 사용하는 일반적인 목적은 SQL Server의 특정 인스턴스에 사용할 수 있는 CPU를 제한하는 데 있습니다. 다중 인스턴스를 통합하는 시나리오의 경우 이러한 방식을 사용하면 여러 인스턴스 사이에 CPU 리소스를 분할할 수 있습니다. 그러나 이 방식을 사용하여 SQL Server의 특정 인스턴스에만 특정 CPU 리소스를 사용하도록 만들 수는 있지만 이 경우 궁극적으로는 서버에서 사용 가능한 전체 CPU 리소스가 완전히 활용되지 않는 결과를 낳을 수도 있습니다. CPU 리소스를 관리하는 좀더 효율적인 방법은 Windows 시스템 리소스 관리자 같은 관리 도구를 사용하는 것입니다. 이 방법에 대해서는 이 문서의 뒷부분에서 설명합니다. Tempdb 고려 사항SQL Server의 단일 인스턴스를 사용할지 다중 인스턴스를 사용할지 결정할 때는 앞서 설명한 내용 이외에 tempdb 사용에 관련된 다른 사항도 고려해야 합니다. tempdb 데이터베이스는 SQL Server의 동일한 인스턴스 내에 포함된 모든 데이터베이스 사이에 공유되는 리소스이므로 단일 경합 지점이 될 가능성이 있습니다. tempdb 데이터베이스를 사용하는 방식은 작업 부하에 따라 크게 달라질 수 있습니다. tempdb를 어떻게 구성할지 결정할 때는 여러 가지 요소를 고려해야 합니다. 이 테스트 시나리오 구성의 경우 Microsoft는 NEC Storage S4300 내에서 실제로 격리된 디스크에 tempdb의 데이터 파일을 배치했습니다. 작업 부하를 실행하는 동안 일정한 간격으로 마스터 시스템 프로세스를 폴링하여 tempdb 충돌을 모니터링했습니다. 또한, 성능 모니터를 사용하여 tempdb에 대한 I/O 작업 및 응답 시간을 모니터링했습니다. 테스트 시나리오의 구성에서는 충돌이 발견되지 않았습니다. tempdb 데이터베이스의 크기를 결정하는 데에도 여러 가지 요인을 고려해야 합니다. 개별 서버에 있는 tempdb의 현재 크기를 확인하고 사용량을 모니터링하면 통합을 위해 tempdb에 필요한 공간을 예측할 수 있습니다. 이 문서에 나와 있는 테스트 시나리오에서는 이전의 tempdb 사용량이나 크기에 대한 어떠한 정보도 주어지지 않았습니다. 따라서 단일 인스턴스 구성의 경우 tempdb 크기를 30GB로 설정했고 20퍼센트의 비율로 자동 증가 기능을 활성화했습니다. tempdb의 저장소 공간에는 전체 데이터 크기의 20퍼센트가 할당되었으며 이는 90에 가까운 값입니다. 테스트 시나리오에서 저장소는 tempdb가 증가하는 경우에 대비하여 이를 수용할 수 있도록 적절한 크기로 구성되었으며, 동시에 실행되는 DSS 및 유지 관리 작업 부하를 포함하여 모든 작업 부하에 대해 tempdb 파일 크기를 30GB로 설정해도 충분한 것으로 확인되었습니다. 작업 부하 테스트를 진행하는 동안 tempdb 데이터 파일이 자동으로 증가하는 경우는 관찰되지 않았지만 OLTP 작업 부하와 함께 DSS 및 유지 관리 작업 부하를 동시에 실행하면 tempdb I/O 작업량이 평균보다 약간 증가했습니다. 테스트를 진행하는 동안의 다른 I/O 작업을 비롯하여 tempdb I/O 작업에 대한 자세한 내용은 "부록 B: 저장소 구성 및 성능"을 참조하십시오. tempdb 구성 방식과 크기를 결정할 때는 다음과 같은 사항을 고려해야 합니다.
Windows 시스템 리소스 관리자 및 SQL Server Windows 시스템 리소스 관리자는 Microsoft Windows Server 2003, Enterprise Edition 및 Microsoft Windows Server 2003, Datacenter Edition에 포함된 서비스입니다. 이 서비스를 사용하면 관리자가 응용 프로그램, 서비스 및 프로세스에 CPU와 메모리 리소스가 할당되는 방식을 제어할 수 있습니다. 여기에서는 WSRM의 기능을 일부만 설명합니다. 자세한 내용은 WSRM과 함께 설치되는 WSRM 도움말 파일을 비롯하여 부록 C의 자료를 참조하십시오. SQL Server의 각 인스턴스에 할당되는 CPU 리소스의 양을 관리할 때는 WSRM을 사용하는 것이 좋습니다. 또한, WSRM을 사용하여 프로세서 선호도와 프로세스의 메모리 사용량을 제어할 수도 있지만 WSRM의 이러한 기능은 SQL Server 인스턴스를 관리하는 데 사용하지 않는 것이 좋습니다. 메모리 사용량이나 프로세서 선호도를 튜닝하는 작업에는 항상 선호도 마스크, 최소 서버 메모리 및 최대 서버 메모리 설정이 포함되어 있는 SQL Server sp_configure 시스템 저장 프로시저를 사용해야 합니다. WSRM에서는 관리 대상 프로세스의 기본 우선 순위를 동적으로 변경하여 관리되는 프로세스에 사용할 수 있는 CPU 리소스의 양을 제어합니다. 다음은 SQL Server와 함께 WSRM을 사용할 때 주의해야 할 몇 가지 일반적인 규칙입니다.
WSRM을 사용하여 테스트한 각 시나리오를 살펴보기에 앞서, WSRM 관련 테스트를 진행하는 동안 /NUMPROC=8 Boot.ini 스위치를 사용하여 Windows에 표시되는 CPU의 수를 제한했으므로 NEC Express 5800/1320Xd의 전체 CPU 리소스를 작업 부하에서 모두 소모하여 WSRM에서 CPU 사용량을 관리하게 되었다는 점을 기억할 필요가 있습니다. WSRM 시나리오 1: 특정 SQL Server 인스턴스로 리소스 제한 서버의 CPU 리소스에 대한 SQL Server 인스턴스의 액세스 우선 순위를 제어하기 위한 서로 다른 두 가지 시나리오에서 WSRM을 테스트했습니다. 첫 번째 시나리오에서는 CPU 리소스에 대한 우선 순위를 다른 인스턴스에서 확보할 수 있도록 WSRM을 사용하여 특정 SQL Server 인스턴스에 할당되는 CPU 리소스의 양을 제한했습니다. 작업 부하는 11개의 SQL Server 인스턴스에 대해 동시에 실행되었습니다. 처음 10개의 인스턴스에 대한 작업 부하는 주로 OLTP 유형의 작업 부하로 구성되었습니다. 11번째 인스턴스에 대한 작업 부하는 병렬 실행 계획이 포함된 복잡한 쿼리를 실행하는 다중 스트림, 즉 DSS 스타일의 작업 부하로 구성되었습니다. WSRM 정책은 DSS 작업 부하에 대상 CPU의 10퍼센트를 할당하도록 구성했습니다. 나머지 SQL Server 인스턴스는 기본 WSRM 정책을 사용하여 관리했습니다. 이 정책에서는 CPU 리소스의 나머지 90퍼센트를 모든 인스턴스 간에 균일하게 나눕니다. 테스트를 진행하는 동안 CPU 사용률과 트랜잭션 처리량을 측정했습니다. 그 결과는 그림 1.6과 그림 1.7에 나와 있습니다.  그림 1.6 SQL Server 인스턴스의 초당 트랜잭션 그림 1.6에서는 OLTP 유형의 작업 부하를 실행하는 각 SQL Server 인스턴스에 대한 초당 트랜잭션을 보여 줍니다. 모든 OLTP 유형의 작업 부하에 대해 측정한 초당 총 트랜잭션은 WSRM을 사용하여 프로세스를 관리하지 않는 경우 약 506개였고, WSRM을 사용하여 프로세스를 관리하는 경우 약 587개였습니다. DSS 스타일의 작업 부하를 실행하는 SQL Server 인스턴스에 사용할 수 있는 CPU 리소스의 양을 WSRM을 사용하여 제한하면 OLTP 작업 부하의 트랜잭션 처리량이 14퍼센트 증가한 것을 알 수 있습니다.  그림 1.7 SQL Server 인스턴스의 프로세서 사용량 그림 1.7에는 SQL Server 인스턴스의 CPU 사용량이 나와 있습니다. WSRM을 사용하는 경우 DSS 스타일의 작업 부하를 실행하는 SQL Server 인스턴스의 평균 CPU 사용량은 약 254퍼센트에서 206퍼센트로 감소했습니다. 이 값이 100퍼센트보다 큰 이유는 다중 프로세서 시스템의 경우 CPU 사용량이 프로세서의 수에 100퍼센트를 곱한 값까지 커질 수 있기 때문입니다. 더욱 주목해야 할 사실은 DSS 스타일의 작업 부하를 실행하는 SQL Server 인스턴스에 대해 기록된 최대 CPU 사용량이 WSRM을 사용하지 않는 경우 682퍼센트에서 WSRM을 사용하는 경우 361퍼센트로 크게 감소했다는 점입니다. WSRM 정책을 사용하면 WSRM에서 CPU 리소스에 대한 우선 순위를 OLTP 작업 부하에 부여할 수 있으므로 총 CPU 리소스가 모두 소모된 경우라 해도 이러한 작업 부하에 대해 얻을 수 있는 처리량이 증가했습니다. WSRM은 총 CPU 사용량을 모니터링하고 관리되는 프로세스의 기본 우선 순위를 동적으로 조정하여 특정 프로세스에 사용할 수 있는 CPU 리소스를 관리합니다. 그림 1.8에는 Windows 성능 모니터 도표가 나와 있습니다.
 그림 1.8 WSRM을 사용한 프로세스 우선 순위 관리 그림 1.8에서는 관리되는 프로세스와 WSRM이 상호 작용하는 방식에 주목할 필요가 있습니다. 인스턴스 sqlservr#8은 DSS 스타일의 작업 부하를 실행하는 프로세스를 나타내고, 인스턴스 sqlservr#3은 OLTP 유형의 작업 부하를 실행하는 SQL Server 인스턴스 중 하나를 나타냅니다. CPU 사용률이 75퍼센트 이상인 경우 WSRM은 DSS 작업 부하를 실행하는 인스턴스의 기본 우선 순위가 다른 OLTP 인스턴스보다 낮아지도록 조정합니다. 데이터를 쉽게 파악할 수 있도록 관련 SQL Server 프로세스에 대한 카운터의 일부는 포함시키지 않았습니다. WSRM 시나리오 2: SQL Server 인스턴스 그룹에 대한 우선 순위 부여두 번째 테스트 시나리오에서는 가장 많은 양의 CPU 리소스를 사용한 SQL Server 인스턴스 세 개에 더 많은 CPU 리소스를 부여하는 데 WSRM을 사용했습니다. 이 테스트를 위해 총 10개의 SQL Server 인스턴스에 대해 OLTP 유형의 작업 부하를 실행했습니다. 세 개의 SQL Server 인스턴스에 대해서는 각각 CPU의 20%가 할당되도록 WSRM 정책을 정의했습니다. 나머지 일곱 개의 인스턴스는 기본 WSRM 정책을 사용하여 제어했습니다. 기본 정책은 CPU 리소스의 나머지 40퍼센트를 균등하게 분할합니다. 테스트를 진행하는 동안 CPU 사용률과 트랜잭션 처리량을 측정했습니다. 그림 1.9와 그림 1.10은 테스트 대상이었던 10개의 SQL Server 인스턴스 각각에 대한 트랜잭션 처리량과 CPU 사용률을 보여 줍니다.  그림 1.9 SQL Server 인스턴스의 초당 트랜잭션  그림 1.10 SQL Server 인스턴스의 CPU 사용량 그림 1.9와 그림 1.10에서 OLTP4, OLTP7 및 OLTP8은 WSRM 정책에 정의된 대로 각각 대상 CPU의 20퍼센트가 할당된 세 개의 인스턴스를 나타냅니다. 나머지 인스턴스는 WSRM 기본 그룹에 속해 있으며 CPU 리소스의 나머지 40퍼센트를 분할하여 할당받고 있습니다. 이와 같은 방식으로 WSRM을 사용하면 모든 SQL Server 인스턴스에 대한 초당 누적 트랜잭션이 WSRM을 비활성화한 경우 627개에서 WSRM을 활성화한 경우 682개로 증가하여 약 8퍼센트가 증가함을 확인할 수 있습니다. 두 시나리오에서 모두 확인할 수 있듯이 WSRM을 사용하면 서버의 CPU 리소스에 대한 우선 순위를 성공적으로 관리할 수 있었습니다. 즉, 필요한 경우에만 WSRM을 사용하여 CPU 리소스를 관리하고 전반적인 시스템 리소스를 완전히 활용할 수 있었습니다. WSRM은 프로세스 수준에서 리소스를 관리하므로 WSRM을 활성화하여 SQL Server를 관리하려면 SQL Server의 다중 인스턴스를 사용해야 합니다. 유형이 다른 작업 부하 이 문서에서 말하는 유형이 다른 작업 부하는 I/O 특성이 크게 다른 작업 부하를 의미합니다. 여러 데이터베이스를 단일 서버에 통합하는 경우 일반적으로 I/O 특성이 크게 다른 작업 부하를 동일한 서버에 배치하거나 특히 공유 I/O 하위 시스템에 배치하는 구성은 피하는 것이 좋습니다. 데이터베이스 작업 부하는 다음과 같은 두 가지 일반 범주로 분류할 수 있습니다.
여기에서는 내용을 쉽게 이해할 수 있도록 작업 부하에 대한 설명을 단순화했습니다. 실제로 사용되는 작업 부하가 항상 이러한 두 가지 범주 중 하나와 정확하게 일치하는 것은 아닙니다. 그러나 여러 작업 부하를 공통 디스크 집합에 함께 통합할 때는 특정 작업 부하의 I/O 특성을 이해하는 것이 중요합니다. 동일한 실제 스핀들 집합에 작업 부하 유형이 혼합되어 있으면 전반적인 시스템 성능에 부정적인 영향을 미칠 수 있습니다. 몇 가지 테스트 시나리오를 마련하기 위해 Microsoft는 DSS 스타일의 작업 부하를 OLTP 스타일의 작업 부하와 결합하여 DSS 작업 부하가 OLTP 성능에 미치는 영향을 관찰했습니다. 테스트 집합 하나는 OLTP 데이터 파일과 동일한 실제 스핀들에 배치된 DSS 데이터 파일을 사용하여 실행했고, 다른 테스트 집합은 별도의 실제 스핀들에 배치된 DSS 데이터 파일을 사용하여 실행했습니다. 그림 1.11에는 이러한 테스트의 결과가 나와 있습니다.  그림 1.11 유형이 다른 작업 부하 성능 그림 1.11의 결과에서 알 수 있듯이 DSS 스타일의 작업 부하에 대한 I/O는 일반적으로 디스크 대기 시간이 더 길어지는 결과를 가져왔습니다. DSS 데이터 파일이 별도의 실제 스핀들에 분리되어 있는 경우 OLTP 데이터 파일에 대해 실행한 읽기 작업의 디스크 대기 시간은 32밀리초(ms)에서 13.5ms로 줄어들었습니다. DSS 작업 부하의 성능은 읽기 처리량에 따라 달라집니다. 데이터 파일이 별도의 디스크에 배치되어 있는 경우 이 처리량이 유지되었지만 그 결과 성능에 미친 영향은 발견되지 않았습니다. 그러나 두 작업 부하를 분리한 결과 OLTP 작업 부하를 통해 실행한 I/O의 평균 대기 시간이 줄어드는 결과를 가져왔으며, 이는 궁극적으로 테스트 시나리오에서 OLTP 작업 부하에 대한 작업 부하 성능이 향상되는 결과를 낳았습니다. 작업 부하를 혼합한 결과 작업 부하의 I/O 특성과 사용 중인 하드웨어의 성능 및 저장소의 설계에 부정적인 영향을 보였습니다. 유형이 다른 작업 부하를 단일 서버에 혼합하려면 이러한 각 요소를 고려해야 합니다. 결론 SQL Server를 통합할 때 64비트 플랫폼을 사용하면 32비트 플랫폼에 비해 몇 가지 이점을 얻을 수 있습니다. SQL Server의 다중 인스턴스를 사용할지 결정하는 데는 플랫폼에 따른 기술적인 제한보다 데이터 관리에 따른 필요성이 더 큰 요인으로 작용합니다. 여러 SQL Server 데이터베이스를 서버 하나에 통합하기 위한 방법을 결정할 때는 성능 이외에도 여러 가지 사항을 고려하고 평가해야 합니다. 이 문서의 목적은 통합을 수행하기 위한 확실하고 간편한 규칙을 제공하는 데 있다기보다 통합을 위한 접근 방식의 예를 보여 주는 데 있습니다. 적절한 계획과 분석 과정을 거치면 데이터베이스를 효율적으로 통합하여 비용을 줄이고 관리 작업을 간소화할 수 있습니다. 이 문서의 통합 테스트 시나리오에서 얻을 수 있는 주요 결론을 요약하면 다음과 같습니다.
부록 A: 다중 인스턴스 메모리 경합 관련 고려 사항 메모리 부하가 작업 부하 성능에 미치는 영향 이 문서에서 설명한 통합 시나리오 이외에도 SQL Server의 다중 인스턴스를 사용한 테스트 시나리오를 NEC 시스템보다 CPU 리소스와 실제 메모리가 적은 다른 64비트 시스템에서 실행했습니다. 그 결과 SQL Server 인스턴스는 서버의 사용 가능한 메모리를 확보하기 위해 경합을 벌여야 했습니다. 이 테스트는 12GB의 RAM이 설치되어 있고 4개의 프로세서가 장착된 64비트 Itanium 시스템에서 수행되었습니다. 테스트를 진행하는 동안 성능에 미치는 전반적인 영향을 측정했습니다. SQL Server는 서버를 다시 시작하거나, 최대 서버 메모리 설정에 대한 구성을 변경하거나, 시스템의 다른 응용 프로그램에서 메모리를 요구하기 전까지 해당 버퍼 풀의 메모리를 계속 사용합니다. 메모리 부하가 작업 부하 성능에 미치는 영향을 확인하기 위해 하나의 SQL Server 인스턴스가 서버의 실제 메모리 대부분을 확보한 후에 다른 SQL Server 인스턴스를 시작했습니다. 테스트를 실행하기 전에 두 인스턴스를 모두 동시에 온라인으로 연결하여 성능 벤치마크를 수행했습니다(시나리오 A). 다음 테스트(시나리오 B)에서는 최대 서버 메모리와 최소 서버 메모리를 0으로 설정하여 인스턴스를 구성했습니다. 그 결과 SQL Server는 사용 가능한 실제 메모리가 128MB만 남을 때까지 메모리를 계속 사용합니다. 마지막 테스트(시나리오 C)에서는 최대 서버 메모리를 설정하여 이미 온라인으로 연결된 인스턴스에 사용되는 메모리의 양을 전체 사용 가능한 12GB 중 10GB로 제한했습니다. 표 A.1에는 실행된 작업 부하 시나리오의 개요가 나와 있습니다. 표 A.1 메모리 경합 시나리오
그림 A.1은 위에서 설명한 시나리오 A, B 및 C에 대해 작업 부하를 통해 실현된 트랜잭션 처리량을 보여 줍니다.  그림 A.1 다른 인스턴스에서 실제 메모리를 거의 모두 사용한 후에 온라인으로 연결되는 SQL Server 인스턴스의 초당 트랜잭션 그림 A.1은 사용할 수 있는 메모리의 일부가 다른 인스턴스에 이미 사용된 후에 온라인으로 연결되는 SQL Server 인스턴스의 트랜잭션 처리량에 미치는 영향을 보여 줍니다. 시나리오 A는 인스턴스 사이에 메모리 경합이 없는 상태에서 두 인스턴스가 모두 동시에 온라인으로 연결된 경우에 얻을 수 있는 트랜잭션 처리량을 보여 줍니다. 시나리오 B와 시나리오 C의 경우 파란색 막대는 사용 가능한 총 12GB 중 약 11.5GB를 이미 다른 인스턴스에서 사용한 후에 온라인으로 연결된 인스턴스의 트랜잭션 처리량을 나타냅니다. 이미 온라인으로 연결된 인스턴스의 최대 서버 메모리 옵션은 0 또는 무제한으로 설정되었습니다. 시나리오 B와 시나리오 C의 경우 빨간색 막대는 온라인으로 새로 들어오는 인스턴스에 사용할 약간의 메모리만 남겨둔 채 총 12GB의 실제 메모리 중 10GB를 다른 인스턴스가 사용한 상태에서 온라인으로 연결된 인스턴스를 통해 얻은 트랜잭션 처리량을 나타냅니다. 이미 온라인으로 연결된 인스턴스의 메모리 사용량은 최대 서버 메모리 옵션을 10GB로 설정하여 총 12GB 중 10GB로 제한되어 있습니다. 시나리오 B와 시나리오 C는 새 인스턴스가 온라인으로 들어올 때 기존의 인스턴스가 유휴 상태인 경우와 활성 상태인 경우의 차이를 보여 줍니다. 그림 A.1은 SQL Server 인스턴스 하나에 대한 메모리 양을 제한하여 새로 온라인으로 들어오는 인스턴스의 성능이 향상될 수 있음을 보여 줍니다. 시나리오 B에서 유휴 서버에 대해 인스턴스를 온라인으로 가져오는 경우 얻을 수 있는 초당 트랜잭션의 수가 55퍼센트 감소했습니다. 첫 번째 인스턴스에 대한 상한값을 설정하여 사용 가능한 메모리를 약간만 남겨둔 경우 성능이 크게 향상되었습니다. 시나리오 C에서 활성 서버에 대해 인스턴스를 온라인으로 가져오는 경우 그 차이는 훨씬 컸으며, 얻을 수 있는 초당 트랜잭션 수는 203퍼센트 감소했습니다.  그림 A.2 다중 인스턴스의 메모리 경합 상태에서 전체 디스크 하위 시스템에 대한 초당 총 디스크 읽기 그림 A.2에서 알 수 있듯이 인스턴스가 온라인으로 들어올 때 버퍼 풀에 대한 메모리 확보가 지연됨에 따라 트랜잭션 처리량이 줄어드는 것 이외에도 디스크 I/O가 증가하여 두 SQL Server 인스턴스 모두의 성능에 영향을 미칩니다. 온라인으로 들어오는 SQL Server 인스턴스는 요청된 데이터 페이지를 캐시할 수 없으므로 디스크 작업량이 증가합니다. 이미 온라인으로 연결된 인스턴스의 메모리 사용량을 제한하면 온라인으로 새로 연결되는 인스턴스에서 데이터 페이지를 좀더 효율적으로 캐시할 수 있으므로 전체 시스템 간에 I/O가 줄어듭니다. 부록 B: 저장소 구성 및 성능 이 문서에서 설명하고 있는 통합 테스트를 위해 Microsoft는 NEC Storage S4300을 사용했습니다. 벤치마크와 관련되지 않은 다른 작업 부하와 실제 디스크 수준에서 충돌이 발생하지 않도록 하기 위해 개별 실제 디스크의 각 파티션에 LUN(논리 단위 번호)이 사용되도록 NEC Storage S4300을 구성했습니다. 저장소 통합 부분에 사용되는 LUN은 총 56개의 실제 스핀들(또는 실제 디스크)에 걸쳐 분산되었습니다. 전체적으로 약 1TB의 용량에 달하는 4개의 LUN을 만들고 Windows에 제공했습니다. 그림 B.1에서 알 수 있듯이 통합 테스트에 사용된 LD(논리 장치)는 물리적으로 격리된 스핀들에 배치되었습니다. 각 논리 장치 번호는 실제 드라이브를 나타냅니다. 실제 스핀들은 NEC Storage S4300에서 LUN의 가장 작은 구성 요소이므로 이러한 격리는 설계하기가 매우 쉽습니다. 데이터와 로그 사이의 구분은 일반적인 I/O 특성을 그룹화하고 로그 기록의 대기 시간을 줄이는 데 사용되었습니다. 데이터 파일의 안정적인 성능을 확보하기 위해 tempdb를 데이터와 구분했습니다. 작업 부하 대부분의 tempdb 특성에 대한 정보를 충분히 얻을 수 없었기 때문입니다.  그림 B.1 논리적 실제 디스크 구성 표 B.1에서는 각 논리 단위 번호의 사용에 따른 자세한 정보를 보여 줍니다. 표 B.1 논리 단위 번호 구성
SQL Server와 함께 사용되는 SAN(저장소 영역 네트워크) 구성은 특정 사용 시나리오의 특징에 따라 크게 다를 수 있습니다. 이 문서에서 설명하고 있는 테스트 시나리오의 경우 저장소를 어떻게 구성할지 결정하는 데는 다음과 같은 사항을 고려했습니다.
다음 그림에서는 통합 시나리오를 테스트하는 동안 작업 부하를 실행하면서 NEC Storage S4300을 통해 얻은 I/O 성능을 보여 줍니다. 이 그림은 테스트한 구성 시나리오를 사용하여 얻을 수 있는 I/O 성능의 유형에 대한 참조 자료로 제공된 것입니다.  그림 B.2 단일 인스턴스 디스크 처리량(OLTP 및 DSS 동시 작업 부하)  그림 B.3 단일 인스턴스 디스크 처리량(OLTP 작업 부하만)  그림 B.4 다중 인스턴스 디스크 처리량(OLTP 및 DSS 동시 작업 부하)  그림 B.5 다중 인스턴스 디스크 처리량(OLTP 작업 부하만) 부록 C: 참고 자료 NEC Storage S4300 및 Express5800/1320Xd http://www.necstorage.com/product/san/s4300/index.shtml Microsoft SQL Server 2000을 사용한 통합 계획(영문)
http://www.microsoft.com/technet/prodtechnol/sql/2000/plan/SQL2KCon.mspx Microsoft 제공 서비스(영문) http://www.microsoft.com/services/microsoftservices/offe.mspx Windows 시스템 리소스 관리자 홈 페이지(영문) http://www.microsoft.com/windowsserver2003/technologies/management/wsrm/default.mspx Microsoft 저장소 기술 - 다중 경로 I/O(영문) http://www.microsoft.com/windowsserversystem/storage/technologies/mpio/default.mspx Microsoft 기술 자료 271624 INF: DBCC MEMORYSTATUS를 사용하여 SQL Server 메모리 사용 모니터 http://support.microsoft.com/?id=271624 Microsoft 기술 자료 314546 HOWTO: SQL Server를 실행하는 컴퓨터 간에 데이터베이스 이동 http://support.microsoft.com/?id=314546 Microsoft 기술 자료 328551 FIX: Tempdb 데이터베이스에 대한 동시성 강화 http://support.microsoft.com/default.aspx?kbid=328551 부록 D: 하드웨어 구성 서버 NEC Express5800/1320Xd
저장소 NEC Storage S4300 디스크 배열
MPIO(Microsoft Multipath I/O) 기술을 기반으로 한 다중 경로 소프트웨어 솔루션인 NEC Storage PathManager 3.0 Enterprise for Windows를 사용하여 네 개의 호스트 버스 어댑터 모두에 대한 I/O 트래픽 균형을 조정했습니다. 패브릭 스위치 스위치 없음(직접 연결) 운영 체제 64비트 버전의 Microsoft Windows Server 2003, Datacenter Edition 데이터베이스 서버 Microsoft SQL Server 2000(64비트 버전) 최종수정일 : 2004년 10월 15일 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
64비트 통합 환경 구성
