Sidekiq导致Rails应用中的内存膨胀

如何解决Sidekiq导致Rails应用中的内存膨胀

我有一个Rails应用，其中有sidekiq工人在后台执行流程，最初有大约30个线程来执行任务。我们发现这导致了高内存使用率，并且减少了工作人员的线程数，从而减少了内存膨胀，但是我不明白为什么。谁能解释一下？

解决方法

从一个快速的google听起来好像您正在经历内存碎片，这对于Sidekiq来说是很正常的。您是否正在使用类变量？您的代码在执行期间是否需要类？您要执行多少个AR查询？许多AR查询会创建数千个（甚至数百万个）对象并将其丢弃。 您的代码是线程安全的吗？根据Sidekiq作者的this post，我们可以看到多线程应用程序中的大量内存区域都发生了内存膨胀。该文章中有解决方案的一些细节，甚至是Sidekiq存储库的自述文件都非常有用，但是可能值得概述一下因果关系，以了解为什么在“ rails / ruby​​”中发生内存膨胀。

Ruby中的内存分配涉及三层：解释器，OS内存分配器库和内核。 Ruby在称为Ruby heap pages的内存区域中组织对象，并将ruby堆页面划分为相等大小的插槽，其中一个对象占据一个插槽。这些插槽被占用或空闲，并且当Ruby分配新对象时，它将尝试占用空闲插槽。如果没有可用的插槽，它将分配一个新的堆页面。每个插槽都有一个字节限制，如果一个对象高于该字节限制，则会在堆页面中放置一个指向该对象的指针。

内存碎片是指这些分配发生的时间，并且在高线程应用程序中非常常见。进行垃圾收集时，堆页面会将已清除的插槽标记为空闲，并允许该插槽被重用。如果堆页面中的所有对象都标记为空闲，那么堆页面将被释放回内存分配器，甚至可能释放给内核。 Ruby不会保证对所有对象进行垃圾回收，那么当不是所有可用插槽都没有释放并且大量堆页面被部分填充时会发生什么情况？堆页面具有可供Ruby分配的可用插槽，但是内存分配器仍认为它们已分配了内存。内存分配器不会立即释放整个OS堆，而是可以释放任何单独的OS页面，而只需释放该页面的所有分配。

因此，由于每个线程都试图同时从同一OS堆分配内存，因此线程争用了访问权。一次只能有一个线程可以执行分配，这会降低多线程内存分配性能。内存分配器试图通过创建多个OS堆来优化性能，并尝试为其自己的OS堆分配不同的线程。

如果您可以使用ruby 2.7，可以致电GC.compact来解决这个问题。它提供了一种方法来查找可以在Ruby中移动的对象，并压缩它们并减少使用的堆页面数量。通过消耗的插槽之间的GC释放的空插槽现在可以被冷凝。例如，假设您有一个带有四个插槽的堆页面，并且只有插槽1、2和4分配了一个对象。紧凑调用将评估对象4是否为可移动对象，并将其分配给插槽3和与该对象关联的所有引用，然后重定向到插槽3。现在，插槽4放置了一个T_MOVED对象，最终的GC用T_MOVED替换了T_EMPTY对象，准备分配。

就我个人而言，我不会仅仅依靠GC.compact，而您可以做一个简单的MALLOC_ARENA_MAX技巧，但是请阅读原始文档，您应该找到一个合适的解决方案。