성능 튜닝 및 모니터링
동기화 성능을 위해 다음과 같은 방법을 사용하는 것이 좋습니다.
성능을 최대화하도록 각 서버 및 데이터베이스, 응용 프로그램 코드 구성
성능 기준선 개발
기준선을 충족하거나 초과하도록 모니터링 및 튜닝 수행
구성
성능 튜닝의 첫 번째 단계는 하드웨어와 소프트웨어가 적절히 구성되었는지 확인하는 것입니다.
서버 및 네트워크 고려 사항
각 컴퓨터에 적합한 IO 하위 시스템이 있고 데이터베이스 파일이 제대로 할당되었는지 확인합니다.
대개 네트워크 속도보다 디스크에서 변경 내용을 읽고 쓰는 속도가 더욱 중요하므로 적합한 IO 하위 시스템을 갖추는 것은 필수입니다. 여러 RAID 디스크 배열을 사용하고 서버에서 tempdb, 사용자 데이터베이스 및 트랜잭션 로그에 대해 각각 전용 배열을 사용하는 것이 좋습니다. tempdb, 사용자 데이터베이스 및 트랜잭션 로그는 별개의 파일 그룹으로 만들어야 합니다. 하나 이상의 사용자 테이블에서 처리하는 데 병목 상태가 발생하면 별도의 파일 그룹으로 이동해 보십시오.
동기화 토폴로지의 컴퓨터에 메모리를 추가해 봅니다.
이 작업은 많은 수의 동시 동기화 세션과 관련된 서버에 특히 중요합니다. 동기화 세션에는 대개 장기 실행 트랜잭션이 포함되므로 서버 데이터베이스에서 직접 처리할 수 있도록 메모리 크기가 충분해야 합니다. SQL Server의 경우 32비트 시스템용 /3GB 스위치를 사용하거나 64비트 시스템으로 이동해 보십시오. 자세한 내용은 SQL Server 온라인 설명서에서 "프로세스 주소 공간"을 참조하십시오.
서버 데이터베이스에 할당될 최소 및 최대 메모리 양을 설정합니다.
예를 들어 기본적으로 데이터베이스 엔진은 사용할 수 있는 시스템 리소스에 따라 메모리 요구 사항을 동적으로 변경합니다. 동기화 작업 중 사용 가능한 메모리의 부족을 방지하기 위해 min server memory 옵션을 사용해서 사용 가능한 최소 메모리를 설정합니다. 메모리를 확보하기 위해 운영 체제가 디스크로 페이징하지 않도록 하기 위해 max server memory 옵션을 사용하여 최대 메모리를 설정할 수도 있습니다. 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오.
데이터베이스 및 응용 프로그램 디자인
최상의 데이터베이스 디자인 방법을 따릅니다.
일반적으로 동기화에 포함된 데이터베이스에 대한 성능 최적화의 영향은 유사한 데이터베이스에 대한 성능 최적화의 영향과 거의 동일합니다. 데이터베이스 최적화에 대한 자세한 내용은 SQL Server 온라인 설명서를 참조하십시오. 인덱스에 대한 다음 고려 사항에 주의하십시오.
인덱스는 선택, 삽입, 업데이트 및 삭제 성능에 영향을 줄 수 있으므로 기본 테이블의 인덱스는 동기화 작업을 염두에 두고 테스트해야 합니다.
메타데이터 테이블을 적절하게 인덱싱해야 합니다. Sync Framework에서는 만들어지는 모든 테이블에 인덱스를 추가합니다. DbSyncProvider의 메타데이터 테이블을 만들려면 방법: 공동 작업 동기화를 위한 서버 데이터베이스 프로비전(SQL Server 이외)을 참조하십시오. DbServerSyncProvider의 경우에는 방법: 사용자 지정 변경 내용 추적 시스템 사용을 참조하십시오.
데이터베이스 잠금 제한 시간 및 쿼리 제한 시간에 적절한 값을 설정합니다.
게시 디자인 및 응용 프로그램 동작을 통해 충돌을 최소화합니다.
충돌을 검색하고 해결하려면 보다 정교한 기술과 처리 능력이 필요하고 네트워크 트래픽이 증가하므로 응용 프로그램은 가능한 한 충돌을 방지하도록 디자인되어야 합니다. 충돌을 방지하는 가장 일반적인 방법은 다음과 같습니다.
한 노드의 테이블만 업데이트합니다. 또는
한 노드만 특정 행 집합을 업데이트하도록 데이터를 필터링합니다. 예를 들어 클라이언트-서버 시나리오에서 각 클라이언트가 워싱턴에 있는 고객의 연락처 정보와 같은 한 데이터 "조각"만 변경하도록 클라이언트 전체에서 데이터를 수평 분할할 수 있습니다.
필터링을 주의해서 사용합니다.
데이터를 필터링하면 충돌을 줄이고 보다 적은 데이터를 각 노드에 복사할 수 있습니다. 그러나 복잡한 필터링 절은 성능에 영향을 줄 수 있습니다. 필터가 많은 테이블을 조인하면 같은 논리를 구현하는 다른 방법을 생각해 보십시오.
트리거 및 동기화 쿼리의 응용 프로그램 논리에 유의합니다.
각 쿼리 및 트리거에서 추가 논리를 실행하면 성능이 대폭 저하될 수 있습니다.
데이터베이스 명령에 저장 프로시저를 사용합니다.
Sync Framework에서는 여러 가지 쿼리를 사용하여 동기화 세션 동안 데이터 및 메타데이터 변경 내용을 선택하고 적용합니다. 이러한 쿼리를 직접 만들 경우 저장 프로시저 안에 캡슐화합니다. 이렇게 하면 일반적으로 성능 및 유지 관리가 향상되고 응용 프로그램 보안에 도움이 될 수도 있습니다. 응용 프로그램에서 저장 프로시저 대신 인라인 SQL이 필요하면 모든 명령에 ADO.NET Prepare() 메서드를 사용합니다. 이렇게 하면 인라인 SQL의 성능이 향상됩니다.
각 노드에 필요한 데이터만 동기화합니다.
"만약을 위해" 데이터베이스의 전체 또는 대부분의 테이블을 게시하려는 생각을 해볼 수 있습니다. 응용 프로그램에 정말 필요한 테이블만 게시하고 각 노드를 동기화하는 횟수를 줄여 보십시오.
동기화 그룹 및 범위를 적절하게 디자인하고 각 범위에 적절한 동기화 방향을 사용합니다.
범위는 한 단위로 동기화되는 테이블 집합입니다. 범위에 있는 하나 이상의 테이블을 필터링할 수 있으며 테이블을 여러 범위에 포함할 수 있습니다. 범위가 포함된 테이블의 구조 및 사용 패턴을 반영하는지 확인합니다. 영업 응용 프로그램에 대해 다음과 같은 테이블 4개가 있다고 가정해 봅니다.
Orders 및 OrderDetails
행은 클라이언트 컴퓨터의 해당 테이블에만 삽입되지만 서버에서 업데이트될 수 있습니다. 변경 내용은 동일한 트랜잭션에서 커밋되어야 합니다. 이러한 테이블은 같은 범위 안에 있고 동기화 방향이 양방향이어야 합니다.
Pricing
행이 서버에서만 자주 삽입 및 업데이트됩니다. 이 테이블 및 이와 유사한 테이블은 한 범위에 있고 동기화 방향이 클라이언트 관점에서 다운로드 전용이어야 합니다.
Products
행이 서버에서만 가끔 삽입 및 업데이트됩니다. 이 테이블은 Pricing보다 업데이트 횟수가 적고 이에 따라 동기화 횟수도 적어질 수 있으므로 Pricing과 다른 범위에 있어야 합니다.
참고
동기화 방향은 각 세션에 대해 변경할 수 있지만 범위는 세션 간에 유지됩니다. 범위와 동기화 방향 사이에는 직접적인 연결이 없지만 이 예제에서는 응용 프로그램을 디자인할 때 두 가지 모두 고려하는 방법을 보여 줍니다.
DbSyncProvider의 경우 SelectTableMaxTimestampsCommand를 사용하여 열거형을 최적화합니다.
이 속성에 지정된 쿼리는 각 기본 테이블 또는 추적 테이블에서 최대 타임스탬프를 선택합니다. 이 타임스탬프는 각 테이블에 대해 원본의 변경 내용이 모두 대상에 이미 있는지 여부를 확인하는 데 사용됩니다. 대상에 변경 내용이 이미 있으면 Sync Framework에서 종종 열거형 쿼리를 생략할 수 있으므로 성능이 향상될 수 있습니다.
일괄 처리를 사용하여 불안정한 네트워크 및 메모리 부족 문제를 보완합니다.
기본적으로 Sync Framework에서는 각 노드에 대한 변경 내용을 단일 DataSet 개체로 전달합니다. 이 개체는 노드에 적용할 변경 내용으로 메모리에 유지됩니다. 변경 내용을 적용할 컴퓨터에 메모리가 충분하고 컴퓨터에 대한 연결이 안정적이면 기본 동작도 잘 작동합니다. 그러나 일부 응용 프로그램에서는 변경 내용을 일괄 처리로 나누는 것이 더욱 좋습니다. 일괄 처리는 추가 오버헤드를 발생시키지만 일부 응용 프로그램의 경우 실제로 성능을 향상시킬 수 있습니다. 자세한 내용은 방법: 변경 내용을 일괄 처리로 전달(SQL Server)을 참조하십시오.
동기화 일정을 엇갈리게 설정합니다.
많은 수의 노드를 중앙 노드와 동기화할 경우 일정을 엇갈리게 설정하여 중앙 노드의 메모리 가중과 경합을 줄입니다. 일정은 클럭 시간 또는 상대 시간에 기반을 둘 수 있습니다. 예를 들어 응용 프로그램에서 매시간 동기화하거나 해당 노드에 대한 마지막 세션이 성공적으로 완료되고 한 시간 이후에 동기화 세션을 시작할 수 있습니다.
적절한 메타데이터 정리 일정을 사용합니다.
메타데이터 양이 많으면 동기화 쿼리의 성능에 영향을 줄 수 있습니다.
기준선
동기화를 구성한 다음에는 응용 프로그램 및 토폴로지에 일반적으로 사용되는 작업과의 동기화 작동 방식을 결정할 수 있는 성능 기준선을 만드는 것이 좋습니다. 동기화 이벤트 및 시스템 모니터를 사용하여 다음과 같은 5가지 동기화 성능의 일반적인 수치를 확인할 수 있습니다.
대기 시간: 토폴로지의 노드 간에 데이터 변경 내용을 전파하는 데 소요되는 시간
처리량: 시간에 따라 시스템에서 지속할 수 있는 동기화 작업의 양(특정 기간 동안 전달된 행으로 측정)
동시성: 동시에 특정 노드와 동기화할 수 있는 노드 수. 이 값은 종종 특정 서버와 동기화할 수 있는 클라이언트 수와 같습니다.
동기화 기간: 지정된 동기화 세션을 완료하는 데 소요되는 시간
리소스 소비량: 동기화 처리의 결과로 사용되는 하드웨어 및 네트워크 리소스
응용 프로그램에 따라 이러한 성능 측정값 중 일부가 다른 측정값보다 중요할 수 있습니다. 예를 들어 높은 수준의 동시성이 유지 관리될 수 있다면 상대적으로 낮은 처리량이 허용될 수 있습니다. 기준선을 설정할 때 Sync Framework는 SQL Server 트랜잭션 복제와 같이 대기 시간이 적고 처리량이 많은 서버-서버 시스템으로 디자인되지 않고 오프라인 및 공동 작업 응용 프로그램을 지원하는 클라이언트-서버 및 클라이언트-클라이언트 동기화용으로 디자인되었다는 점에 유의하십시오.
기준선 수치를 설정한 후에는 시스템을 모니터링하여 성능 및 확장성 병목 상태를 찾아 필요에 따라 튜닝합니다.
모니터링 및 유지 관리
모니터링은 성능 기준선을 개발하는 동안 사용될 수 있습니다. 프로덕션 환경에서 정기적으로 사용하거나 성능 문제가 발생할 경우 더욱 집중적으로 사용할 수 있습니다. 다음 도구를 사용하여 동기화 작업 및 성능을 모니터링하는 것이 좋습니다.
동기화 이벤트
다음 이벤트를 사용하여 특정 단계에 소요되는 시간을 확인합니다.
각 공급자의 테이블당 이벤트: SelectingChanges, ChangesSelected, ApplyingChanges 및 ChangesApplied
각 공급자의 세션당 이벤트: SyncProgress
각 단계에 소요되는 시간을 메모리에 저장한 다음 동기화 세션이 끝난 후 로그 파일 또는 성능 데이터베이스에 결과를 씁니다.
SQL Server 프로파일러
TSQL_SPs 템플릿을 사용하여 특정 임계값(예: 10초)보다 오래 걸리는 쿼리를 식별합니다. 로그 파일 또는 성능 데이터베이스에 추적 정보를 쓸 경우 데이터를 메모리에 저장했다가 동기화 세션이 끝난 후 씁니다.
SQL Server Management Studio
Management Studio를 사용하여 각 동기화 쿼리에 대한 쿼리 계획을 확인하여 최적의 계획이 사용되는지 확인합니다.
시스템 모니터
다음과 같은 성능 개체 및 카운터를 사용하여 동기화에 중요한 영역을 모니터링합니다.
SQL Server 아래의 카운터: Memory Manager. 예를 들어 Target Server Memory와 Total Server Memory를 비교하여 SQL Server에서 사용 가능한 메모리를 사용 중인지 여부를 확인할 수 있습니다.
PhysicalDisk 아래의 카운터. 예를 들어 Avg. Disk Read Queue Length 및 Avg. Disk Write Queue Length는 동기화 성능이 IO 하한인지 또는 컴퓨터의 메모리가 부족한지를 확인하는 데 도움이 됩니다. 큐 길이가 비정상적이면 메모리 추가 및 드라이브 업그레이드 또는 추가를 고려해 보십시오.
기본값은 카운터가 모든 드라이브에 걸쳐 평균값을 보고하는 것입니다. 각 드라이브에 대한 카운터를 추가했는지 확인하십시오.
SQL Server 아래의 카운터: Transactions. 예를 들어 Snapshot Transactions 및 Version Store Size를 사용하여 변경 내용 열거 쿼리로 인해 tempdb 크기가 대량으로 늘어나는지 여부를 확인할 수 있습니다. 변경 내용 열거 쿼리에서는 스냅숏 트랜잭션을 사용하고 스냅숏 버전 정보가 tempdb에 저장됩니다. 버전 저장소의 크기가 크면 tempdb의 크기를 조정해야 할 수 있습니다.
SQL Server 아래의 카운터: Locks. 예를 들어 Lock Wait Time 및 Number of Deadlocks를 사용하여 데이터베이스에서 동시 작업을 수행하는 동안 경합이 문제인지 여부를 확인할 수 있습니다.
동기화 추적
Sync Framework에는 TraceListener 클래스 기반의 추적이 포함되어 있습니다. 추적을 사용하여 동기화 세션에 대한 정보를 수집할 수 있습니다. 이러한 정보는 모니터링 및 문제 해결에 유용합니다. 그러나 추적은 추가 오버헤드를 발생시키므로 주로 개발하는 동안 사용해야 합니다. 자세한 내용은 방법: 동기화 프로세스 추적을 참조하십시오. 이 항목은 DbServerSyncProvider에 중점을 두지만 다른 공급자에도 해당 정보를 적용할 수 있습니다.
모니터링 외에 다음과 같은 유지 관리 태스크를 정기적으로 수행하는 것이 좋습니다.
조각 모음 수준에 따라 기본 테이블 및 메타데이터 테이블을 다시 구성하거나 해당 인덱스를 다시 작성합니다.
인덱스 통계를 업데이트합니다.
동기화 메타데이터를 정리합니다.