처리량

bsr 성능의 처리량 관련 최적화에 대해서 다룹니다. 최적화에 성능 최적화에 관한 몇 가지 하드웨어 고려 사항과 각각의 세부 튜닝 항목들을 검토하겠습니다튜닝 항목들에 대해 살펴보겠습니다.

하드웨어

bsr의 처리능력은 시스템 내의 하위 I/O 서브시스템(디스크, 컨트롤러, 그리고 캐시)과 네트워크 대역폭의 영향을 받습니다.

...

네트워크 처리량은 일반적으로 트래픽의 양과 네트워크 인프라(routing/switching) 장비에 의해 결정됩니다. 하지만 일반적으로 bsr을 위한 복제 링크는 전용선을 사용하기 때문에 이런 환경 조건들과는 크게 관련이 없습니다. 따라서 네트워크 처리량은 higher-throughput 전송대역(10 Gigabit Ethernet처럼)으로 전환하거나, 본딩 네트워크 드라이버 같은 복수의 링크를 통해서 향상시킬 수 있습니다.

처리속도 추정

처리 속도를 추정할 때는 다음과 같은 제한사항을 고려해야 합니다.

...

위 에서 설명한 바와 같이 처리 속도를 추정하기 위해 I/O

...

서브시스템과 네트워크 대역폭에 대해 고려하여 추정합니다.

이론적으로는 두 요소의 각각의 최대값 중에서 최소값을 최대 처리 속도로 추정할 수 있으며, 이 값에 오버헤드를 약 3% 정도로 가정해서 속도를 추산합니다.

• 200MB/s 처리 능력이 있는 I/O 서브시스템에서 기가 비트 이더넷이 연결된 클러스터 노드를 가정해 봅시다. 기가 비트 이더넷의 TCP 연결은 110MB/s 처리 속도를 제공한다고 가정하고, 네트워크의  병목현상을 감안해  3% 정도를 낮춰서 대략 107MB/s의 최대 처리 속도를 기대할 수 있습니다. 

• 또한, I/O 서브시스템에서 100MB/s의 처리 능력이 제공된다고 했을 때 이곳에서의 병목현상까지 감안하여 bsr의 최대 처리 속도는 전체 97MB/s까지 기대할 수 있습니다.

...

bsr의 성능에 영향을 줄 수 있는 몇 가지 구성 옵션 들 중 , 이 장에서는 몇 가지 권장할 만한 사항들을 소개합니다. 하지만 성능은 하드웨어에 크게 좌우되기 때문에 여기서 설명한 옵션들을 조정한 효과는 시스템마다 다를 수 있습니다. 따라서 이러한 권장사항들이 모든 병목현상을 성능 병목을 해결해주는 절대적인 요소는 아닙니다.

req-buf-size

Primary 노드의 I/O requet 버퍼 큐의 request 버퍼 큐(req-buf)의 최대 크기를 지정합니다. 이 버퍼는 로컬 디스크로 I/O 가 발생되면 해당 I/O 를 1차적으로 큐잉하기 위한 장소로 장소로서 TCP 송신버퍼로 I/O Request 가 넘겨지기 이전에 이전 시점에 1차 버퍼링을 위한 용도로 사용됩니다.

복제가 원할한 보통의 경우에는 req-buf 가 혼잡상황(full)에 놓일 일이 거의 없지만 어떤 요인으로 인해 시스템의 부하가 클 경우 복제 처리가 지연 될 수 있고 req-buf가 full 이 될 가능성이 있습니다.(이 정도의 복제 지연과 부하에 놓인 상태라면 ack 지연으로 인한 복제연결 단절이 발생할 수도 있습니다.) 이러한 상황에 대해 대비하기 위해 req-buf 를 여유있게 설정할 필요가 있습니다. 기본값은 리소스 당 100MB 바이트 입니다.

...

bsr 을 사용하는 응용 프로그램이 쓰기 위주이고 작은 크기의 쓰기를 쓰기가 자주 하는 발생하는 환경이라면 액티비티 로그 사이즈를 크게 잡는 것이 좋습니다. 그렇지 않으면 메타데이터의 업데이트가 자주 발생하여 쓰기 성능이 저하될 수 있습니다. 기본값은 6001 입니다.

resource <resource> {
  disk {
    al-extents 6001;
    ...
  }
  ...
}

지연시간

bsr의 지연지연시간(latency) 최적화에 대해 다룹니다. 지연시간을 최소화하기 위해 하드웨어 측면에서 검토하고 몇 가지 설정 옵션을 살펴보겠습니다.

...