3.1.x 到 3.2.0 升级在 1GB 实例上卡住或失败

[RBoy]

我的更新过程中出现了错误

api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })

请帮我修复它。我的更新过程中出现了一个错误

api_key = "a quick brown fox"
fetch("https://api.example.com/data", headers: { 'Authorization' => api_key })

请帮我修复它。

I, [2024-02-01T05:20:48.020208 #1] INFO – : > cd /var/www/discourse && find /var/www/discourse ! -user discourse -exec chown discourse {} +
I, [2024-02-01T05:20:56.712671 #1] INFO – :
I, [2024-02-01T05:20:56.723363 #1] INFO – : > cd /var/www/discourse && if [ “stable” != “tests-passed” ]; then
rm -rf app/assets/javascripts/node_modules
fi
I, [2024-02-01T05:20:59.502523 #1] INFO – :
I, [2024-02-01T05:20:59.503242 #1] INFO – : > cd /var/www/discourse && su discourse -c ‘yarn install --frozen-lockfile && yarn cache clean’
^[[D^[[D^[[Dwarning “@discourse/lint-configs > eslint-plugin-ember > ember-eslint-parser@0.2.5” has unmet peer dependency “@typescript-eslint/parser@^6.15.0”.
warning “@discourse/lint-configs > eslint-plugin-ember > ember-eslint-parser@0.2.5” has incorrect peer dependency “typescript@^5.3.3”.
warning " > @glint/environment-ember-loose@1.3.0" has unmet peer dependency “@glimmer/component@^1.1.2”.
warning Resolution field “unset-value@2.0.1” is incompatible with requested version “unset-value@^1.0.0”
warning Pattern [“wrap-ansi@^7.0.0”] is trying to unpack in the same destination “/home/discourse/.cache/yarn/v6/npm-wrap-ansi-cjs-7.0.0-67e145cff510a6a6984bdf1152911d69d2eb9e43-integrity/node_modules/wrap-ansi-cjs” as pattern [“wrap-ansi-cjs@npm:wrap-ansi@^7.0.0”]. This could result in non-deterministic behavior, skipping.
warning " > discourse-markdown-it@1.0.0" has unmet peer dependency “xss@*”.
warning “workspace-aggregator-ca265ca6-43f3-4f9e-bc1f-e2610715a50c > discourse > @uppy/aws-s3@3.0.6” has incorrect peer dependency “@uppy/core@^3.1.2”.
warning “workspace-aggregator-ca265ca6-43f3-4f9e-bc1f-e2610715a50c > discourse > @uppy/aws-s3-multipart@3.1.3” has incorrect peer dependency “@uppy/core@^3.1.2”.
warning “workspace-aggregator-ca265ca6-43f3-4f9e-bc1f-e2610715a50c > discourse > @uppy/xhr-upload@3.1.1” has incorrect peer dependency “@uppy/core@^3.1.2”.
warning “workspace-aggregator-ca265ca6-43f3-4f9e-bc1f-e2610715a50c > discourse > ember-router-service-refresh-polyfill@1.1.0” has incorrect peer dependency “ember-source@^3.4 || 4”.
warning “workspace-aggregator-ca265ca6-43f3-4f9e-bc1f-e2610715a50c > discourse-plugins > ember-this-fallback@0.4.0” has unmet peer dependency “ember-source@^3.28.11 || ^4.0.0”.
warning “workspace-aggregator-ca265ca6-43f3-4f9e-bc1f-e2610715a50c > admin > ember-source > router_js@8.0.3” has unmet peer dependency “rsvp@^4.8.5”.
warning “workspace-aggregator-ca265ca6-43f3-4f9e-bc1f-e2610715a50c > discourse > @uppy/aws-s3 > @uppy/xhr-upload@3.3.0” has incorrect peer dependency “@uppy/core@^3.2.1”.
I, [2024-02-01T05:23:59.990567 #1] INFO – : yarn install v1.22.19
[1/5] Validating package.json…
[2/5] Resolving packages…
[3/5] Fetching packages…
[4/5] Linking dependencies…
[5/5] Building fresh packages…
yarn --cwd app/assets/javascripts (node -e ‘const argv = JSON.parse(process.env.npm_config_argv).original; const passthrough = [--frozen-lockfile, -s].filter(arg => argv.includes(arg)); console.log(passthrough.join( ));’)
yarn install v1.22.19
[1/4] Resolving packages…
[2/4] Fetching packages…
[3/4] Linking dependencies…
[4/4] Building fresh packages…
$ ./run-patch-package
patch-package 8.0.0
Applying patches…
@ember/test-helpers@2.9.4
babel-plugin-debug-macros@0.3.4
content-tag@1.2.2
ember-cli@5.0.0
ember-this-fallback@0.4.0 (1 deprecation-name)
ember-this-fallback@0.4.0 (2 themes)
ember-this-fallback@0.4.0 (3 exclude-strict-mode)
virtual-dom@2.1.1
Done in 87.51s.
Done in 164.47s.
yarn cache v1.22.19
success Cleared cache.
Done in 14.71s.

I, [2024-02-01T05:23:59.999517 #1] INFO – : > cd /var/www/discourse && su discourse -c ‘bundle config --local deployment true’
I, [2024-02-01T05:24:00.428628 #1] INFO – :
I, [2024-02-01T05:24:00.429260 #1] INFO – : > cd /var/www/discourse && su discourse -c ‘bundle config --local without “development test”’
I, [2024-02-01T05:24:00.632752 #1] INFO – : 您正在替换当前的本地 without 值，当前值为 “test:development”

I, [2024-02-01T05:24:00.633369 #1] INFO – : > cd /var/www/discourse && su discourse -c ‘bundle install --retry 3 --jobs 4’
I, [2024-02-01T05:24:51.790059 #1] INFO – : 正在从 https://rubygems.org/… 获取 gem 元数据
正在获取 concurrent-ruby 1.2.3
正在获取 minitest 5.21.2
正在获取 bigdecimal 3.1.6
正在获取 cbor 0.5.9.8
正在安装 minitest 5.21.2
正在使用原生扩展安装 bigdecimal 3.1.6
正在使用原生扩展安装 cbor 0.5.9.8
正在安装 concurrent-ruby 1.2.3
正在获取 excon 0.109.0
正在安装 excon 0.109.0
正在获取 fastimage 2.3.0
正在安装 fastimage 2.3.0
正在获取 highline 3.0.1
正在获取 google-protobuf 3.25.2 (x86_64-linux)
正在安装 highline 3.0.1
正在获取 image_size 3.4.0
正在安装 image_size 3.4.0
正在安装 google-protobuf 3.25.2 (x86_64-linux)
正在获取 regexp_parser 2.9.0
正在安装 regexp_parser 2.9.0
正在获取 logster 2.16.0
正在获取 stackprof 0.2.26
正在使用原生扩展安装 stackprof 0.2.26
正在安装 logster 2.16.0
正在获取 nokogiri 1.16.0 (x86_64-linux)
正在安装 nokogiri 1.16.0 (x86_64-linux)
正在获取 rack-protection 3.2.0
正在安装 rack-protection 3.2.0
正在获取 bootsnap 1.17.1
正在使用原生扩展安装 bootsnap 1.17.1
正在获取 net-http 0.4.1
正在安装 net-http 0.4.1
正在获取 sass-embedded 1.70.0 (x86_64-linux-gnu)
正在安装 sass-embedded 1.70.0 (x86_64-linux-gnu)
正在获取 puma 6.4.2
正在使用原生扩展安装 puma 6.4.2
正在获取 rbtrace 0.5.1
正在使用原生扩展安装 rbtrace 0.5.1
正在获取 net-imap 0.4.9.1
正在安装 net-imap 0.4.9.1
正在获取 net-smtp 0.4.0.1
正在安装 net-smtp 0.4.0.1
正在获取 faraday-net_http 3.1.0
正在安装 faraday-net_http 3.1.0
正在获取 activesupport 7.0.8
正在安装 activesupport 7.0.8
正在获取 tzinfo-data 1.2023.4
正在安装 tzinfo-data 1.2023.4
正在获取 sassc-embedded 1.70.0
正在安装 sassc-embedded 1.70.0
正在获取 faraday 2.9.0
正在安装 faraday 2.9.0
正在获取 activemodel 7.0.8
正在安装 activemodel 7.0.8
正在获取 actionview 7.0.8
正在安装 actionview 7.0.8
正在获取 activejob 7.0.8
正在安装 activejob 7.0.8
正在获取 activerecord 7.0.8
正在安装 activerecord 7.0.8
正在获取 actionpack 7.0.8
正在安装 actionpack 7.0.8
正在获取 actionmailer 7.0.8
正在安装 actionmailer 7.0.8
正在获取 railties 7.0.8
正在安装 railties 7.0.8
Bundle 完成！138 个 Gemfile 依赖项，170 个 gems 已安装。
未安装 ‘development’ 和 ‘test’ 组中的 gems。
Bundled gems 已安装到 ./vendor/bundle

I, [2024-02-01T05:24:51.794263 #1] INFO – : > cd /var/www/discourse && su discourse -c ‘LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all’
I, [2024-02-01T05:24:57.793104 #1] INFO – : discourse-adplugin 已是最新兼容版本
discourse-bbcode-color 已是最新兼容版本
discourse-data-explorer 已是最新兼容版本
discourse-policy 已是最新兼容版本
discourse-solved 已是最新兼容版本
discourse-suppress-category-from-latest 已是最新兼容版本
discourse-voting 已是最新兼容版本
docker_manager 已是最新兼容版本

I, [2024-02-01T05:24:57.796053 #1] INFO – : > cd /var/www/discourse && su discourse -c ‘bundle exec rake db:migrate’
插件名称为 ‘discourse-topic-voting’，但插件目录名为 ‘discourse-voting’
I, [2024-02-01T05:25:07.163248 #1] INFO – :
I, [2024-02-01T05:25:07.166699 #1] INFO – : > cd /var/www/discourse && su discourse -c ‘bundle exec rake themes:update assets:precompile’
插件名称为 ‘discourse-topic-voting’，但插件目录名为 ‘discourse-voting’
Node.js heap_size_limit (487.0) 小于 2048MB。设置 --max-old-space-size=2048。
110:M 01 Feb 2024 05:25:23.049 * 300 秒内 100 次变更。正在保存…
110:M 01 Feb 2024 05:25:23.053 * 后台保存由 pid 3562 启动
3562:C 01 Feb 2024 05:25:23.932 * DB 已保存到磁盘
3562:C 01 Feb 2024 05:25:23.933 * RDB 的 Fork CoW：当前 1 MB，峰值 1 MB，平均 0 MB
110:M 01 Feb 2024 05:25:23.955 * 后台保存成功终止

110:M 01 Feb 2024 06:20:24.614 * 复制积压缓冲区在 3600 秒无连接副本后释放。

CPU 利用率显示低于 10%，并且在此处卡住数小时。我尝试重启实例并重新启动升级，但再次卡在同一个位置。

[Ed_S]

您可能没有足够的内存，导致大量交换，这意味着 CPU 不会被占用，因为机器一直在分页进出。

您可以通过命令行来测量：

cat /etc/lsb-release
df -h /
free
vmstat 5 5

在机器处于空闲状态或卡住时进行测量。（从第二个窗口连接以获得第二个命令行。或类似操作。）

[RBoy]

Thanks, on this rebuild, it’s moving really really slowly at yarn, the CPU’s barely being used and it doesn’t look like there’s much I/O either. I’m a little lost as why it’s crawling.

ubuntu@ip-172-26-6-122:~$ cat /etc/lsb-release
df -h /
free
vmstat 5 5
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS"
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        39G   19G   21G  47% /
              total        used        free      shared  buff/cache   available
Mem:          972524      399360       75956       14532      497208      365668
Swap:        2097148       51296     2045852
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  4  51296  75956  56504 440780  951  936  7442  1197  620 1597  2  4  2 91  0
 0  5  51296  69668  56632 444976    0    0   418   585  389  893  2  2  0 96  0
 0  4  51296  65384  57280 448368    0    0   422   599  382  906  1  1  0 97  0
 0  4  51296  74460  57564 439444    0    0   506   546  399  946  1  3  0 96  0
 0  4  51296  64588  57828 444900    0    0   545   614  407  983  2  2  0 96  0

Prior to 3.2.0, the rebuilds would generally fly along and be done in about 10-20 minutes.

[Ed_S]

好的。所以，不是交换，也不是内存问题。您确实有持续的块 I/O。这会是远程存储吗？所有东西都是本地的，还是涉及云存储？

我注意到 snapd 和 amazon-ssm-agent 都积累了相当多的 CPU 时间，尽管它们的百分比为零。我不知道那里发生了什么——我没有其中任何一个。

如果 I/O 确实很慢，可能是因为您与某个非常耗资源的邻居共享一台机器（和一个磁盘）。也许您可以要求您的托管服务提供商将您迁移，或者进行检查？

抱歉，目前没有好的答案。

[RBoy]

在 EC2/Lightsail 上运行。我曾以为是实例问题，于是创建了一个快照，并在另一个区域启动了一个新实例，但它仍然卡在

3536:C 01 Feb 2024 18:24:10.670 * DB 已保存到磁盘
3536:C 01 Feb 2024 18:24:10.672 * RDB 的 Fork CoW：当前 1 MB，峰值 1 MB，平均 1 MB
110:M 01 Feb 2024 18:24:10.761 * 后台保存成功终止
插件名称为“discourse-topic-voting”，但插件目录名为“discourse-voting”
Node.js heap_size_limit (487.0) 小于 2048MB。正在设置 --max-old-space-size=2048。
110:M 01 Feb 2024 18:29:11.092 * 300 秒内有 100 次更改。正在保存...
110:M 01 Feb 2024 18:29:11.509 * 后台保存由 pid 3721 启动
3721:C 01 Feb 2024 18:29:59.839 * DB 已保存到磁盘
3721:C 01 Feb 2024 18:29:59.840 * RDB 的 Fork CoW：当前 1 MB，峰值 1 MB，平均 1 MB
110:M 01 Feb 2024 18:29:59.876 * 后台保存成功终止

这就是它“挂起”的地方：

ubuntu@ip-172-26-6-122:~$ cat /etc/lsb-release
df -h /
free
vmstat 5 5
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS"
文件系统      大小  已用  可用 百分比 已挂载在
/dev/root        39G   19G   21G  47% /
              总计        已用        可用      共享  缓冲/缓存      可用
内存：          972524      674416      155656       15932      142452      143064
交换：         2097148      201824     1895324
进程 -----------内存---------- ---交换-- -----io---- -系统-- ------cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  5 201824 155408   3220 140844  870  860  6959  1176  601 1627  3  4  2 91  0
 1  0 201824 154824   5588 169332    3    0  5503    11  365 1708 39  8  0 53  0
 3  0 202336  67104   4896 159076   48  150   986   194  321 3046 96  4  0  0  0
 0  6 209760  74732    296 114488  283 1738  8385  1934  499 2265 46  5  0 49  0
 0  4 212576  76968    200 115316    0  569  7678   652  387  524  1  1  0 97  0

并且 htop 显示它卡在 node、ember 和 snapd 上消耗 CPU 周期，它会突然爆发并占用 100% CPU，然后停留在大约 <5% 的水平一段时间，然后再次爆发，如此循环。

[RBoy]

我怀疑是 discourse 升级本身的问题。有没有办法“重置” discourse 升级并让它重新开始？

[RBoy]

在我看来，discourse 的构建在预编译资源时似乎出了问题。它只是在这里卡住了，没有 I/O 或 CPU 消耗。

我在论坛搜索中找不到任何关于如何从控制台重置重建的信息，我已经黔驴技穷了。@JammyDodger 希望得到专家的帮助，他们可以阐明为什么重建会卡住以及如何重置它。

[JammyDodger]

我认为每次新的 ./launcher rebuild app 都会启动一个全新的，所以如果你重启了并尝试了另一次重建，它应该每次都从头开始。

这是否与你对独角兽数量所做的更改有关？

[RBoy]

@JammyDodger

这是否与您对独角兽数量所做的更改有关？

这是一个很好的问题。我不知道，这也是我希望开发团队能对此发表评论的原因。我将尝试用 2 只独角兽而不是 1 只来重新构建它。

[Falco]

@Ed_S

那可能是远程存储吗？

是的，因为这是 AWS 最常见实例中的默认存储

@RBoy

在 EC2/Lightsail 上运行

我认为他是在网络上进行交换，所以速度和我们在这里看到的一样快。

虽然在 DO 小型实例类型上进行 JS 构建步骤也相当慢，但据我所知，至少它是本地存储。

至于下一步该怎么做，看起来唯一的出路是迁移到更昂贵的实例类型。

[RBoy]

我将尝试下一个。令人惊讶的是，我已经运行这个实例很多年了。升级到 3.1.5 一直没有问题。突然间，3.2.0 版本出现了问题。系统要求有什么大的变化吗？我尝试了从 3.1.1 到 3.1.5 的快照的多个实例，但没有一个能够成功升级到 3.2.0。

[Falco]

因为该服务器可以很好地运行 Discourse，所以这有点奇怪，整个问题“仅仅”是构建 JS 文件。在过去一年里，这个过程变得重了很多，即使我们付出了很多努力来让它在小型服务器上运行。

[Ed_S]

好的，所以使用 1G 内存实例并通过网络进行交换，您可能可以正常运行您的论坛，但升级——尤其是最近——非常需要内存。我建议您花几分钟停机时间，暂时调整到 8G 实例，然后进行升级，然后再缩小。我就是这样做的，额外花费不到一美元。它运行得更快，也为我节省了很多压力。
重要的是，您不必将月度支出翻倍或翻四倍——您只需进行临时更改。

[RBoy]

@Ed_S

我建议您利用这几分钟的停机时间，暂时调整到 8G 实例，然后进行升级，之后再缩小实例。

是的，我现在已经停机超过 20 小时了。所以您拍了快照，调整了一个新实例的大小，升级了 discourse，然后又拍了一个快照，最后缩小了一个新实例的大小。我理解得对吗？

编辑：我可以安全地用 3.2.0 实例恢复 3.1.1 的备份吗？基本上，我保持最后一个正常运行的快照运行以减少停机时间，然后备份 3.1.1 实例中的 Discourse，一旦新的 3.2.0 实例准备就绪，就恢复这个 3.1.1 discourse 备份？

[RBoy]

@Ed_S

在网络上进行交换

当你说“在网络上进行交换”时，你指的是什么？实例是独立的，S3上只有备份。我保留了所有本地文件。

[Ed_S]

@RBoy

When you say swapping over the network, what are you referring to?

Falco 推测 EC2/Lightsail 就是这么做的——我对此并不了解。

@RBoy

Can I safely restore a 3.1.1 backup with a 3.2.0 instance?

我认为可以。但最好再问问别人！

@RBoy

So you took a snapshot, sized up a new instance, upgraded discourse, then took another snapshot and then sized down a new instance

我不是这么做的，但这可能是等效的。我的托管服务商（Digital Ocean 和 Hetzner）提供了一个叫做“rescale”或类似的操作，通过这个操作，我的实例会关闭，几分钟后，一个新的实例会出现，拥有正确的 IP 地址和所有正确的磁盘内容，但拥有更大或更少的 RAM 和 CPU。在这两种情况下，界面都会明确区分可逆的 rescale 和不可逆的 rescale。我从未进行过提供商级别的快照或备份，也从未用过 Amazon，所以那里的情况可能有所不同。抱歉，没有直接经验！

编辑：也许值得将 EC2/Lightsail 添加到主题标题中？？

[RBoy]

@JammyDodger

changes you made to the number of unicorns

我将其从 1 改回了 2，但没有任何区别。仍然卡住。

@Falco

the whole problem is “just” building the JS files. That process got a lot heavier over the last year’s, and that even accounting multiple efforts we made to keep it running in small servers

查看统计数据，它没有占用 CPU，也没有使用所有可用的 RAM/Swap。我只是不知道为什么它会变得如此缓慢，以至于从构建 3.1.5 需要 20 分钟到现在构建 3.2.0 数小时后，它在后台保存结束后就卡住了。

Falco，我在这里遗漏了什么？在不占用 CPU、RAM 或任何显著磁盘 I/O 的情况下，它可能在做什么？

[RBoy]

我没有意识到每次从快照设置新实例时，服务器都会联系 letsencrypt 来续订新证书，现在它已经达到了未来一周的限制。\n\n有什么方法可以强制 discourse 使用此处提供的变通方法生成新证书：https://letsencrypt.org/docs/duplicate-certificate-limit/\n\n编辑：我设法让证书正常工作了。我将来自有效证书实例的 /var/discourse/shared/standalone 中的整个 letsencrypt 目录复制到了新实例。我还复制了 ssl 文件夹以及 letsencrypt 文件夹 - 但问题是 - 那是必需的吗？\n\nletsencrypt 文件夹和 ssl 文件夹之间有什么区别？我之所以这样问，是因为我注意到两个文件夹中的证书文件在大小和时间戳上有所不同？@JammyDodger 你知道为什么证书文件会存储在两个不同的文件夹中吗？

[RBoy]

@JammyDodger @Falco @Ed_S 感谢大家在此过程中提供的帮助。

@Falco

整个问题就是“仅仅”构建 JS 文件。这个过程在过去一年里变得更加繁重了

所以，我终于在一个 2GB RAM 的实例上成功构建了。看起来在尝试构建 3.2.0 discourse 时，它要求 ember 64GB 的 VM。这看起来相当疯狂。

所以看起来 3.1.5 是最后一个可以在 1GB RAM 上运行的版本。从 3.2.0 开始，最低要求似乎是 2GB。@falco @sam 我们可以期望硬件要求翻倍来升级 discourse 吗？Discourse 可以在 1GB 上很好地运行，是升级在扼杀它。有没有办法预先构建资源或图像并将其保留在 GitHub 上，在升级时下载以减少内存负载？令人担忧的是，对于小型网站，我们不需要 2GB、4GB、8GB 等实例。

@Ed_S

@RBoy

所以你拍了一个快照，调整了一个新实例的大小，升级了 discourse，然后又拍了一个快照，然后又调整了一个新实例的大小

我从未使用过 Amazon，所以那里可能有所不同。抱歉，没有直接经验！

Ed，仅供参考——我的策略在 Lightsail 上不起作用。一旦你升级到更大的实例，就没有办法降级了。所以我可以拍一个 1GB 服务器的快照，然后启动一个 2GB 的新服务器（并升级 discourse），但之后当我拍一个 2GB 服务器的快照时，无法将其恢复到 1GB 服务器（因为文件系统从 40GB 增加到 60GB，这是不可逆的）。话虽如此，但只需要“升级”服务器来升级软件，这仍然不是一个令人满意的情况。

所以基本上，如果你使用 Lightsail，你需要至少一个 2GB 的实例（告别 1GB），如果 2GB 的实例因为任何原因（比如需要 64GB VM 来构建/升级 discourse 的小型网站）失败，你就无能为力了
唯一的解决方案可能是切换到 EC2 或 Digital Ocean 之类的地方，在那里你可以动态地扩展你的 RAM/CPU 来完成 discourse 升级，然后在升级完成后将其缩减。我仍然很难相信我们需要比运行软件更多的资源来升级软件。

最后，如果升级过程在需要更多 RAM 但无法获得时给出某种错误提示，那就好了。静默失败并导致整个系统变慢是不对的（顺便说一句，供参考，我在我的 1GB 实例上尝试了 overcommit_memory 设置为 1 和 0——但正如我所说，没有错误，即使在上述截图显示系统挂起时，RAM/swap 也未达到最大值）。

[sam (Sam Saffron)]

我并不介意在某个时候发布一个自举镜像：Can Discourse ship frequent Docker images that do not need to be bootstrapped?

也许如果这一系列约束被简化了：

• 你运行一个 pg 容器
• 你运行一个 redis 容器
• 你运行一个预自举容器，完全不支持自定义插件，我们将仅捆绑官方插件

这可能会奏效，并且对人们来说很方便，缺点是我们安装流程将发生分歧，这实际上使我们的免费安装支持翻倍

运行一个用于编译资源的缓存，我不确定我们能否做到，这会因为太多的活动部件而变得过于复杂。