[Monitoring] Tuning RRDtool for performance

RRDtool은 순환버퍼를 사용하기 때문에 디스크에 쓰는 작업을 최소화합니다. RRDTool로 몇 백개의 rrd 파일을 처리하는 정도로는 rrd 파일을 업데이트 하는데 성능상 문제가 없을 것입니다.

다만 5만, 10만개 이상의 파일을 처리 할 경우에는 문제가 될 수도 있습니다.

 

Background Information

RRDtool의 성능 튜닝에 대해서 이해하려면 RRDtool 파일 형식에 대한 기본 정보와 OS(운영체제)가 디스크의 파일에 접근하는 방식에 대해서 알 필요가 있습니다.

 

RRDtool File Format

  +-------------------------------+

  | RRD Header                    |

  |-------------------------------|

  | DS Header (one per DS)        |

  |-------------------------------|

  | RRA Header (one per RRA)      |

  |===============================| < 1 kByte (normally)

  | RRA Data Area (first RRA)     |

  ................................. The bulk of the space

  | RRA Data Area (last RRA)      | 

  +-------------------------------+ 

rrd 파일은 작은 사이즈의 헤더 영역과 나머지를 차지하는 데이터 영역으로 구성되어 있습니다.

업데이트시 먼저 rrd 파일의 속성들을 가져오기 위해 헤더 영역을 읽은 후 헤더 영역에 갱신된 정보를 업데이트 합니다.

궁극적으로는 마지막 업데이트 이후 명시된 update interval이 지난 모든 RRA 데이터 영역이 업데이트 됩니다.

 

How the OS accesses the disk(OS가 디스크에 access 하는 방법)

 

운영체제에 있어서 디스크에 있는 파일들을 access 하는 일이 시간이 가장 많이 소비되는 작업(task) 중 하나입니다.

 OS는 디스크를 블록단위로 access합니다. 일반적으로 디스크의 블록은 4k 바이트 이므로 OS가 disk에 데이터를 기록 할 때도 4k 바이트 씩 기록하게 됩니다.

보통의 경우 RRDtool 업데이트시의 데이터는 4k바이트 보다 훨씬 작습니다. RRA를 한번 업데이트 할 때 필요한 데이터는 rrd에 정의된 DS(Data Source) 마다 고작 8바이트 밖에 되지 않습니다.

실제로 rrd 파일 업데이트 시 OS는 한번에 4k 바이트 단위로 write 하게 되므로  

1. 필요한 블록(변경하고자 하는 8byte가 포함된 4k바이트 블록)을 디스크에서 읽고,

2. 필요한 만큼의 데이터(8byte)만 변경 후, 종전에 읽었던 block 단위 데이터(4k 바이트)에 합쳐서 disk에 쓰게 됩니다.

이런 이유로 RRD 업데이트 시 디스크에 아주 적은 양의 정보만 변경하면 됨에도 불구하고 OS는 항상 4k 바이트 단위로 기록하게 됩니다.

설상가상으로 OS는 기본적으로 현재 access 하는 데이터 보다 더 많은 데이터를 필요로 할 것이라고 가정하므로 다음 번 요청을 준비하기 위해 더 많은 block을 읽습니다.

디스크에 접근하는 것이 이렇듯 고비용이므로 OS 디자이너들은 디스크 접근 횟수를 최소화 하기 위해 많은 방법을 생각 했습니다. 첫 번째는 디스크 캐쉬(disk cache)를 쓰는 것 입니다.

rrd 파일을 캐슁 할 수 있다는 것은 OS가 디스크로부터 읽을 필요가 없다는 것을 의미합니다. 그냥 기록 하기만 하면 됩니다.

 

 

Optimizing RRD Performance by Altering RRDtool(RRDtool을 변경 함으로써 RRD 성능 최적화 하기)

 

Suppressing Read-Ahead(미리 읽지 못하게 하기….)

OS가 파일을 access 할 때 보통 다음 몇 블록을 더 읽습니다. 애플리케이션이 다음 번 디스크 access 시를 대비해서 디스크를 re-access 할 필요 없이 미리 다음 블록들을 준비 해 놓는 것이 목적입니다.

rrd 업데이트 시에는 이 방법이 잘 먹히지 않습니다. 실제로 rrd 업데이트 시에는 rrd 파일의 시작점의 한 블록을 access 한 후 RRA 를 업데이트 하기 위해서 RRD 파일의 “어딘가의 몇 개”의 블록을 다시 access 해야 합니다.

즉, OS에게 file 블록을 “random” 한 순서로 access 할 것이라는 것을 알려줘야만 OS가 미리 block을 읽어 들이지 않을 것입니다. 아래의 두 가지 쓸만한 효과를 얻을 수 있습니다.

1.    읽을 byte 수가 작기 때문에 빨리 읽을 수 있다.

2. 파일 시스템 캐시가 사용되지 않을 데이터로 낭비되지 않음.

Dave Plonka 가  has developed a patch for RRDtool that uses posix_fadvise to tell the OS that we want to random access the file. The patch is in RRDtool 1.2.24 and 1.3.x.

Posix_fadvise를 사용해 OS가 file 접근을 random하게 할 수 있도록 개발된 patch가 있습니다. 이 패치는 1.2.24와 1.3.x에 포함되어 있습니다.(현재 저희가 사용하는 버전은 1.2.8입니다.)

 

Preserving Buffer Cache(버퍼 캐쉬 사용하기)

파일에서 블록 데이터를 읽으면 결과적으로 buffer cache라고도 불리는 file system cache에 도착하게 됩니다.

일반적으로 Buffer cache의 크기기 작기 때문에 OS는 오래된 데이터 블록을 cache에서 제외시키고 새로운 블록을 받아들일 준비를 해야 합니다.

RRDtool의 퍼포먼스를 향상시키려면 rrd 파일의 모든 hot 블록(지속적으로 요구되는 블록)들을 buffer cache에 머무르도록 유지해야 합니다.

끊임없이 rrdtool 업데이트 프로세스가 실행되고 있다면 위에서 언급한 random access 방법과 이 방법(hot 블록을buffer cache에 보관하는 방법)을 결합시키면 좋은 결과를 볼 수 있을 것이라고 생각합니다.

새로운 rrd 파일을 만들 때, 혹은 그래프를 그릴 때, 많은 양의 데이터가 disk와 메모리를 오갑니다. 이 데이터들은 나중에 사용하기 위해 buffer cache에 저장 될 수 있습니다.

Buffer cache의 사이즈가 제한되어 있기 때문에 OS는 공간을 확보하기 위해 다른 데이터들을 내보내야 합니다.  즉, 한번에 많은 RRD file에 대한 정보를 가지고 있을 수 없게 됩니다.

하지만 OS가 header 부분과 현재 사용하고 있는 RRA 블록을 제외한 rrd 데이터를 cache에 저장하지 않도록 함으로써  작업 대상이 되는 다른 RRD 파일들을 cache에 저장 할 수 있을 만큼 충분한 공간을 확보 할 수 있습니다.

(즉, 한 파일당 전체 RRD 파일이 아닌 header 부분과 RRA 블록만 필요함으로, cache에 불필요한 rrd 파일 block을 저장하지 않도록 한다는 말입니다.)

1.3.x 이상에서는 OS에게 RRD file에서 어떤 데이터(block)가 불필요한 지를 알려주는 Patch가 포함되어 있습니다.

시스템을 공유하고 있는 다른 애플리케이션 역사 buffer cache에 영향을 미칠 수 있습니다. 특히나 많은 양의 데이터에 대한 IO가 이루어지고 있다면 buffer cache의 공간을 확보하기가 쉽지 않을 겁니다.

이러한 문제를 해결 해주는 patch역시 fadvise를 사용해 개발 되어 있습니다.

 

Using Memory Mapped IO(매모리-맵드 IO 사용하기)

POSIX 같은 운영체제는 낮은 비용으로 문제를 해결 할 수 있는 memory mapped IO라고 불리는 방법을 제공합니다. RRDtool이 update 기능에 이 방법을 사용한지는 꽤 되었습니다.

최근에는 update 기능만이 아닌 모든 RRDtool 기능을  Memory mapped IO로 구현한 버전도 소개되어 있습니다.

 여기서는 fadvise(file advise)대신 madvise(memory advise)를 사용해 OS에 어떤 데이터 블록을 캐시해야 하며, 캐시에서 제외해야 할지를 알려줍니다.

이 기능은 1.3.x trunk 버전에서 추가 되었습니다.

 

 

OS based Optimization of RRD Performance(OS 기반의 RDD 성능 최적화)

Memory Sizing(메모리 사이징)

위에서 설명한 바와 같이 RRDtool은 buffer cache에서 모든 hot block을 유지하고 있을 때 가장 좋은 성능을 냅니다. 이것은 시스템의 메모리 사이즈가 RRDtool의 성능에 중요한 역할을 한다는 것을 의미합니다.

메모리 내의 헤더(4k) + 사용하고 있는 RRA block(4k)을 유지하기 위해서는 RRD 파일당 8k 바이트가 필요합니다. 10만개의 RRD 파일을 위해서는 최소 800메가 바이트의 디스크 캐시가 필요합니다.

100'000 * RRD당 8kByte ~ 800 MByte Buffer Cache

Use a Separate File System and possibly block device for RRD Files ¶

RRD file을 위해 분리된 파일 시스템 혹은 블록 디바이스를 사용하해야 합니다.

RRD만을 위한  분리된 파일 시스템이나 블록 디바이스 공간을 확보하면 전체 파일 시스템이나 장치 단위로 최적화 방법을 적용 할 수 있습니다.

Files System Level Optimization(파일 시스템 레벨 최적화)

• Ext3 파일시스템을 마운팅 할 때 Noatime과 nodiratime 옵션을 사용하면 디렉토리 블록과 inode에 대한 access time을 업데이트 하지 않으므로 file IO 성능 향상에 큰 도움을 줍니다.

• Ex3 파일시스템 마운팅 시 data=writeback 옵션을 사용하면 파티션 손상 발생시에 복구가 힘들어지는 반면 엄청난 성능 향상을 가져다 줍니다.(데이터 저널링을 전혀 수행하지 않습니다.)

• 디렉토리 인덱싱을 사용하는 파일시스템(ext3 에서 dir_index 옵션 on) 을 사용하고, 모든 rrd 파일을 한 디렉토리에 넣습니다.

출처 :  http://oss.oetiker.ch/rrdtool-trac/wiki/TuningRRD : 원문입니다.

          http://knifenomad.tistory.com/16