内存管理

在某些情况下,理想的方法是估计 Fluent Bit 可以使用多少内存,这对于必须限制内存的容器化环境非常有用。

为了进行估算,我们将假定输入插件已设置 Mem_Buf_Limit 选项(您可以在积压部分了解更多信息)。

估算

输入插件无限制地追加数据,因此为了进行估算,应通过 Mem_Buf_Limit 选项施加限制。如果限制设置为 10MB,我们需要估计在最坏的情况下,输出插件可能会使用 20MB

Fluent Bit 具有用于处理数据的内部二进制表示形式,但是当此数据到达输出插件时,该插件可能会在新的内存缓冲区中创建自己的表示形式以进行处理。最好的例子是 InfluxDBElasticsearch 输出插件,在与后端服务器通信之前,它们都需要将二进制表示形式转换为各自的自定义 JSON 格式。

因此,如果我们对输入插件施加 10MB 的限制,并考虑输出插件消耗 20MB 的最坏情况,则至少需要(30MB x 1.2=)36MB

Glibc 与内存碎片

众所周知,在密集型环境中,内存分配按数量级进行,Glibc 提供的默认内存分配器可能会导致碎片过多,从而导致服务占用大量内存。

强烈建议在任何生产环境,都应启用 jemalloc(如 -DFLB_JEMALLOC=On) 的情况下构建 Fluent Bit。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 选项,一切都会很好。

Last updated