Java-buildpack: 调整 Glibc 环境变量（例如 MALLOC_ARENA_MAX）

这是我们讨论过的另一个问题@nebhale。

最近一直在研究一些 Java 内存问题，我从 Heroku 看到了以下两篇文章（我应该称它们为“无法命名的那些”吗？:P）：

调整 glibc 内存行为
测试 Cedar-14 内存使用

这表明调整MALLOC_ARENA_MAX可以帮助解决应用程序中的内存问题。 似乎它也给Hadoop带来了问题，尽管这可能是他们自己监控 VMEM 的错误（说真的，伙计们，为什么？！）。

在我自己的测试中，我注意到设置MALLOC_ARENA_MAX似乎有助于减缓内存增长，尽管它_不_完全阻止它。

设置MALLOC_ARENA_MAX会对性能产生影响（我一直将其设置为2 ，正如 Heroku 所建议的那样），但结果如下：

• 新线程创建，要求一个竞技场
• 如果 < MALLOC_ARENA_MAX块正在使用中（默认为8 * cpu_count ），则获取一个。
• 如果 >，分享一个现有的
• malloc ing新内存时，如果独占一个arena，不需要加锁。
• 如果是共享的，就得加锁，从而造成内存争用。 在glibc引入 arenas 之前，所有线程都在争夺相同的内存。
• 当线程退出时， glibc将竞技场标记为“空闲”，但不会_不_将其返回给操作系统。

无论如何，这是我的理解。 所以我认为CF上的大部分Java应用基本不受影响，原因如下：

• 有限的线程抖动。 如果一个主要问题，可以将容器配置为具有min_threads = max_threads 。 大多数线程都是长期存在的，并且会处理大量请求。
• Java 不会在每个线程的基础上执行malloc - 它在启动时mallocs堆空间，然后根据需要写入它。 据我所知，一旦线程运行，就不需要执行操作系统级别的malloc ，这意味着我们永远不会有操作系统级别的内存争用（这已被拉入 Java 运行时）。
  
  
  
  • NIO 和ByteBuffer之类的东西可能会导致malloc调用-对此不确定。
  
  

综上所述，在深入研究之后，似乎设置MALLOC_ARENA_MAX可能只是隐藏了一个更深层次的问题，我不确定我是否会建议默认设置它。 它似乎并没有对性能产生负面影响，但是我测试的两个应用程序在设计上实际上都是非性能的，所以不要把它当作福音。

我最初认为这里可能存在内存问题，但我不再那么确定了。 我认为如果发生内存泄漏，会发生以下情况：

无限MALLOC_ARENAS_MAX

• 线程要求竞技场
• 线程获取竞技场
• 线程填满竞技场，从不释放内存
• 线程要求新的竞技场
• 重复直到cgroup OOM 杀死他。

MALLOC_ARENAS_MAX设置为2

• 线程要求竞技场
• 线程获取竞技场
• 线程填满竞技场，从不释放内存
• 线程要求新的竞技场，但没有更多可用的。
• 线程改为写入“主”竞技场（或本例中的本机程序堆），这是无界的。 如果有足够的时间， cgroup OOM 杀手锏。

（实际的分配决策要复杂得多——这已大大简化。请参阅了解 glibc malloc以获得深入的解释）。

这可以解释为什么我看到pmap报告的堆空间（它_不是_Java堆！）在我的一次测试运行中上升和上升 ​​- 本机代码的某处存在内存泄漏，竞技场得到了填满了，一旦它们满了，它就不得不回退到使用本机堆。

尽管如此，可能应该为各个线程使用的本机内存留出一些余量。 如果它足够小，它可能会留在计算器的“原生”部分。 否则，由于它与使用的线程数有关，因此可能需要以某种方式计算。

不管设置它的决定如何，我_do_ 认为记录它会非常有用（以及它与 Java 的关系等），就像提供指向其他glibc配置环境变量的链接一样。 查找这些信息并不像我希望的那样容易。 我认为这也应该记录在其他构建包中——尤其是 Ruby 和 Go，更有可能看到内存领域的问题——请注意，Heroku 示例都谈到了 Ruby。