我有一个非常接近slug大小限制（300mb）的 Ruby on Rails 应用程序。我使用.slugignore尽可能地减小了尺寸，但还没有得到我想要的结果。
我一时兴起尝试创建一个新的 Heroku 应用程序，并为其部署了相同的git存储库。瞧，它远远低于（仅 80mb vs 208mb ）。当访问bash并检查每台服务器上的大小时，我注意到服务器之间存在一些差异：
du -hs *
130M (old) vs 1.4M (new) public
23M (old) vs 5.3M (new) tmp
...
是什么给出的？在Heroku上，用户是否希望在足够的部署通过后销毁并重新创建应用程序？我查看了公共目录，它保留了各种旧的删除资产和垃圾。如何清除我现有的应用程序而不破坏它并从头开始？
答案 0 :(得分：10)
这可能与Rail试图在部署期间避免问题有关。目标是在部署期间避免停机和/或错误。您的代码不会立即部署到所有服务器。 Rails解决方案是允许多个版本的资产同时存在。典型的过程是：
%> rake assets:precompile # To build new assets
%> rake assets:clean # Remove old assets
Rails keeps 2 previous versions资产（默认情况下）。根据应用程序，您可能需要一段时间的旧资产。例如，如果您有一个繁重的JavaScript应用程序一次获取资源，那么通过XHR动态更新。在客户端中运行的旧代码可以引用其他旧资源。即使使用非客户端繁重的应用程序，您可能需要几秒钟，其中一些节点指的是旧资产，有些节点指的是新资产。
这可以解释您的旧应用中公众规模较大的一些原因。它基本上有三个版本的所有资产，而新部署只有一个版本。听起来好像必须弄乱你的构建环境，因为即使你的新应用程序中所有资产占用1.4MB，这个大小的三倍应该只有5MB而不是旧应用程序中的130MB。
除了有三个版本的资产外，tmp目录中还有一些累积。资产编译过程会在tmp目录中缓存一些信息。 Rails有一个rake tmp:cache:clear你可以定期运行以消除那里的残缺。
Heroku automatically runs rake assets:clean。所以这应该只保留三个版本的资产。但是Heroku并没有真正运行rake tmp:cache:clear。相反，他们have some custom code删除缓存文件，直到缓存数据低于50MB。我假设他们这样做是为了保留尽可能多的缓存信息，同时仍然限制事物。保留尽可能多的缓存数据可能会确保资产编译快速运行。这意味着您的tmp目录将继续增长，直到达到50MB。
如果您的tmp目录中的公共/资产目录增长超过3个版本或50MB，那么创建新应用程序是一个很好的清除方法。你也可以create a custom slug。只需在heroku控制台上运行rake assets:clean或rake tmp:cache:clear即可。这只会清理dyno上的东西，而不是你的slu ..因此，当创建新的dyno时，您的清洁将被丢弃。