当从Ruby 1.8.6升级到Ruby Enterprise 1.8.7 p334时，内存大小几乎翻了一倍。我们升级的五台Fedora 8服务器都出现了这种情况。我们使用Passenger 3.0.4运行Rails 1.2.6。
Munin通过将$ ps axo pid，comm，pmem，vsz，rsz列相加来获取每个进程的内存大小。（虚拟内存大小和常驻内存大小都增加了同样的数量）
我意识到这些列通常会夸大进程实际使用的内存量，但如果用它来测量1.8.6，然后是1.8.7 REE，它们应该同样臃肿，因此仍然可比较。
此外，机器的承诺内存（在/proc/memstat中列出）现在经常超额承诺，这是新的。承诺的内存量已显着增加，看起来我们现在进入了交换空间。
我们还没有调整垃圾收集，但我不知道这会如何影响整体内存占用。
我已打开Phusion FAQ建议的GC.copy_on_write_friendly变量。
这100％内存使用率增加的解释是什么，我该如何解决？欢迎任何有关如何修复或甚至更好地监视/调试的想法。
谢谢。
---更新
为了检查性能，我将运行实例的数量（PassengerMaxPoolSize）从12减少到10个。在另一个服务器上，我将PassengerPoolIdleTime提高到15分钟。我有第三个作为控制。
我正在考虑在服务器上安装非企业版本1.8.7p334，以查看是1.8.7还是企业版。
其他人有这种问题的经验吗？
查看各个Rails进程，它们在1.8.6中每个进程约为120MB，在REE 1.8.7中每个进程约为175MB，如passenger-memory-stats所述。
---更新2
我在服务器上放置了MRI 1.8.7，以与REE 1.8.7进行比较。结果更糟糕，包括更高的内存常驻大小数字和passenger-memory-stats。当然，开始交换。
这让我相信1.8.7的占用空间比1.8.6大。
---更新3
我在一台服务器上放置了MRI 1.8.7，它的内存使用情况比MRI 1.8.6更糟糕，因此我立即回到了MRI 1.86。
Munin通过将$ ps axo pid，comm，pmem，vsz，rsz列相加来获取每个进程的内存大小。（虚拟内存大小和常驻内存大小都增加了同样的数量）
我意识到这些列通常会夸大进程实际使用的内存量，但如果用它来测量1.8.6，然后是1.8.7 REE，它们应该同样臃肿，因此仍然可比较。
此外，机器的承诺内存（在/proc/memstat中列出）现在经常超额承诺，这是新的。承诺的内存量已显着增加，看起来我们现在进入了交换空间。
我们还没有调整垃圾收集，但我不知道这会如何影响整体内存占用。
我已打开Phusion FAQ建议的GC.copy_on_write_friendly变量。
这100％内存使用率增加的解释是什么，我该如何解决？欢迎任何有关如何修复或甚至更好地监视/调试的想法。
谢谢。
---更新
为了检查性能，我将运行实例的数量（PassengerMaxPoolSize）从12减少到10个。在另一个服务器上，我将PassengerPoolIdleTime提高到15分钟。我有第三个作为控制。
我正在考虑在服务器上安装非企业版本1.8.7p334，以查看是1.8.7还是企业版。
其他人有这种问题的经验吗？
查看各个Rails进程，它们在1.8.6中每个进程约为120MB，在REE 1.8.7中每个进程约为175MB，如passenger-memory-stats所述。
---更新2
我在服务器上放置了MRI 1.8.7，以与REE 1.8.7进行比较。结果更糟糕，包括更高的内存常驻大小数字和passenger-memory-stats。当然，开始交换。
这让我相信1.8.7的占用空间比1.8.6大。
---更新3
我在一台服务器上放置了MRI 1.8.7，它的内存使用情况比MRI 1.8.6更糟糕，因此我立即回到了MRI 1.86。
我运行了平均 Rails 进程大小，如 passenger-memory-stats 所列。REE 1.8.7 进程大了 73 MB，这似乎相当大。
这意味着我需要运行更少的进程才能适应相同的内存占用。
将尝试使用更少的进程来测试性能。同时，我也开始进行 GC 调整。
---更新 4
看起来 Ruby 1.8.7 不支持 Rails 1.2.6。官方支持的第一个版本是 1.8.7 的 Rails 2.1。升级后我们就会知道是否是问题的根源。