편집을 취소할 수 있습니다. 이 편집을 되돌리려면 아래의 바뀐 내용을 확인한 후 게시해주세요.
| 최신판 | 당신의 편집 | ||
| 1번째 줄: | 1번째 줄: | ||
= | =메모리 관리= | ||
이를 위해 입력 플러그인이 | 특정 시나리오에서는 Fluent Bit가 사용할 수 있는 메모리 양을 추정하는 것이 이상적이며, 이는 메모리 제한이 필수인 컨테이너화된 환경에 매우 유용합니다. | ||
이를 위해 입력 플러그인이 Mem_Buf_Limit 옵션을 설정했다고 가정합니다(백프레셔 섹션에서 이에 대해 자세히 알아볼 수 있습니다). | |||
==추산== | ==추산== | ||
입력 플러그인은 독립적으로 데이터를 추가(append)하므로 추산을 위해서는 | 입력 플러그인은 독립적으로 데이터를 추가(append)하므로 추산을 위해서는 Mem_Buf_Limit 옵션을 통해 제한을 적용해야 합니다. 제한이 10MB로 설정된 경우 최악의 경우 출력 플러그인이 20MB를 사용할 수 있다고 추산해야 합니다. | ||
Fluent Bit에는 처리 중인 데이터에 대한 내부 바이너리 표현이 있지만, 이 데이터가 출력 플러그인에 도달하면 처리를 위해 새 메모리 버퍼에 자체적인 표현이 생성될 가능성이 높습니다. 가장 좋은 예시로 InfluxDB나 Elasticsearch 출력 플러그인이 있으며, 둘 다 백엔드 서버로 전송되기 전에 바이너리 표현을 커스텀 JSON 형식으로 변환해야 합니다. | Fluent Bit에는 처리 중인 데이터에 대한 내부 바이너리 표현이 있지만, 이 데이터가 출력 플러그인에 도달하면 처리를 위해 새 메모리 버퍼에 자체적인 표현이 생성될 가능성이 높습니다. 가장 좋은 예시로 InfluxDB나 Elasticsearch 출력 플러그인이 있으며, 둘 다 백엔드 서버로 전송되기 전에 바이너리 표현을 커스텀 JSON 형식으로 변환해야 합니다. | ||
| 14번째 줄: | 13번째 줄: | ||
==Glibc 및 메모리 파편화== | ==Glibc 및 메모리 파편화== | ||
메모리 할당이 대규모로 발생하는 집중적인 환경에서는 Glibc에서 제공하는 기본 메모리 할당자가 높은 파편화를 초래하여 서비스의 높은 메모리 사용량을 | 메모리 할당이 대규모로 발생하는 집중적인 환경에서는 Glibc에서 제공하는 기본 메모리 할당자가 높은 파편화를 초래하여 서비스의 높은 메모리 사용량을 보고할 수 있다는 것은 잘 알려져 있습니다. | ||
모든 프로덕션 환경에서 Fluent Bit은 jemalloc을 활성화하여 빌드해야 합니다 (예: -DFLB_JEMALLOC=On). Jemalloc은 무엇보다도 파편화를 줄여 성능을 향상할 수 있는 대체 메모리 할당자입니다. | 모든 프로덕션 환경에서 Fluent Bit은 jemalloc을 활성화하여 빌드해야 합니다 (예: -DFLB_JEMALLOC=On). Jemalloc은 무엇보다도 파편화를 줄여 성능을 향상할 수 있는 대체 메모리 할당자입니다. | ||