1 개요
- 메모리 관리
특정 시나리오에서는 Fluent Bit가 사용할 수 있는 메모리 양을 추정하는 것이 이상적이며, 이는 메모리 제한이 필수인 컨테이너화된 환경에 매우 유용합니다.
이를 위해 입력 플러그인이 Mem_Buf_Limit 옵션을 설정했다고 가정합니다(BackPressure 섹션 에서 이에 대해 자세히 알아볼 수 있습니다).
2 추정
입력 플러그인은 독립적으로 데이터를 추가하므로 추정을 위해서는 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_JEMAALLOC 옵션이 Build Flags 에 나열되어 있으면 모든 것이 정상입니다.
4 참고
-
{{comment.page_title}} ―{{comment.name}}