若需要开启应用的预载入，只需要在unicorn的配置文件中添加一行：
preload_app true
2.3.2 在 Request 请求间的 GC
请谨记，GC 的处理时间最大会占到应用时间的50%。这个还不是唯一的问题。GC 通常是不可预知的，并且会在你不想它运行的时候触发运行。那么，你该怎么处理？
首先我们会想到，如果完全禁用 GC 会怎么样？这个似乎是个很糟糕的想法。你的应用很可能很快就占满 1G 的内存，而你还未能及时发现。如果你服务器还同时运行着几个 worker，那么你的应用将很快会出现内存不足，即使你的应用是在自托管的服务器。更不用说只有 512M 内存限制的 Heroku。
其实我们有更好的办法。那么如果我们无法回避GC，我们可以尝试让GC运行的时间点尽量的确定，并且在闲时运行。例如，在两个request之间，运行GC。这个很容易通过配置Unicorn实现。
对于Ruby 2.1以前的版本，有一个unicorn模块叫做OobGC:
require 'unicorn/oob_gc' use(Unicorn::OobGC, 1) # "1" 表示"强制GC在1个request后运行"
对于Ruby 2.1及以后的版本，最好使用gctools(https://github.com/tmm1/gctools):
require 'gctools/oobgc' use(GC::OOB::UnicornMiddleware)
但在request之间运行GC也有一些注意事项。最重要的是，这种优化技术是可感知的。也就是说，用户会明显感觉到性能的提升。但是服务器需要做更多的工作。不同于在需要时才运行GC，这种技术需要服务器频繁的运行GC. 所以，你要确定你的服务器有足够的资源来运行GC，并且在其他worker正在运行GC的过程中，有足够的worker来处理用户的请求。
2.4 有限的增长
我已经给你展示了一些应用会占用1G内存的例子。如果你的内存是足够的，那么占用这么一大块内存并不是个大问题。但是Ruby可能不会把这块内存返还给操作系统。接下来让我来阐述一下为什么。
Ruby通过两个堆来分配内存。所有Ruby的对象在存储在Ruby自己的堆当中。每个对象占用40字节（64位操作系统中）。当对象需要更多内存的时候，它就会在操作系统的堆中分配内存。当对象被垃圾回收并释放后，被占用的操作系统中的堆的内存将会返还给操作系统，但是Ruby自有的堆当中占用的内存只会简单的标记为free可用，并不会返还给操作系统。
这意味着，Ruby的堆只会增加不会减少。想象一下，如果你从数据库读取了1百万行记录，每行10个列。那么你需要至少分配1千万个对象来存储这些数据。通常Ruby worker在启动后占用100M内存。为了适应这么多数据，worker需要额外增加400M的内存（1千万个对象，每个对象占用40个字节）。即使这些对象最后被收回，这个worker仍然使用着500M的内存。
