Fluent Bit 문서/메모리 관리

1 개요

Memory Management

메모리 관리

특정 시나리오에서는 Fluent Bit가 사용할 수 있는 메모리 양을 추산하는 것이 이상적이며, 이는 메모리 제한이 필수인 컨테이너화된 환경에 매우 유용합니다.

이를 위해 입력 플러그인이 Mem_Buf_Limit 옵션을 설정했다고 가정합니다(백프레셔 섹션에서 이에 대해 자세히 알아볼 수 있습니다).

2 추산

입력 플러그인은 독립적으로 데이터를 추가(append)하므로 추산을 위해서는 Mem_Buf_Limit 옵션을 통해 제한을 적용해야 합니다. 제한이 10MB로 설정된 경우 최악의 경우 출력 플러그인이 20MB를 사용할 수 있다고 추산해야 합니다.

Fluent Bit에는 처리 중인 데이터에 대한 내부 바이너리 표현이 있지만, 이 데이터가 출력 플러그인에 도달하면 처리를 위해 새 메모리 버퍼에 자체적인 표현이 생성될 가능성이 높습니다. 가장 좋은 예시로 InfluxDB나 Elasticsearch 출력 플러그인이 있으며, 둘 다 백엔드 서버로 전송되기 전에 바이너리 표현을 커스텀 JSON 형식으로 변환해야 합니다.

따라서 입력 플러그인에 10MB 제한을 적용하고 출력 플러그인이 20MB를 추가로 소비하는 최악의 시나리오를 고려한다면 최소한 (30MB x 1.2) = 36MB가 필요합니다.

3 Glibc 및 메모리 파편화

메모리 할당이 대규모로 발생하는 집중적인 환경에서는 Glibc에서 제공하는 기본 메모리 할당자가 높은 파편화를 초래하여 서비스의 높은 메모리 사용량을 보일 수 있다는 것은 잘 알려져 있습니다.

모든 프로덕션 환경에서 Fluent Bit은 jemalloc을 활성화하여 빌드해야 합니다 (예: -DFLB_JEMALLOC=On). Jemalloc은 무엇보다도 파편화를 줄여 성능을 향상할 수 있는 대체 메모리 할당자입니다.

다음 명령어를 사용하여 Fluent Bit가 Jemalloc으로 빌드되었는지 확인할 수 있습니다.

$ bin/fluent-bit -h | grep JEMALLOC

출력은 다음과 같습니다.

Build Flags =  JSMN_PARENT_LINKS JSMN_STRICT FLB_HAVE_TLS FLB_HAVE_SQLDB
FLB_HAVE_TRACE FLB_HAVE_FLUSH_LIBCO FLB_HAVE_VALGRIND FLB_HAVE_FORK
FLB_HAVE_PROXY_GO FLB_HAVE_JEMALLOC JEMALLOC_MANGLE FLB_HAVE_REGEX
FLB_HAVE_C_TLS FLB_HAVE_SETJMP FLB_HAVE_ACCEPT4 FLB_HAVE_INOTIFY

FLB_HAVE_JEMALLOC 옵션이 Build Flags 에 나열되어 있으면 모든 것이 정상입니다.

4 참고

• https://docs.fluentbit.io/manual/administration/memory-management