# 加快上传大容量实例的磁盘空间计算

**URL:** https://meta.discourse.org/t/faster-disk-space-calculation-for-upload-heavy-instances/318997
**Category:** Feature
**Tags:** performance, uploads, completed
**Created:** [2024年七月29日 11:17 UTC](https://meta.discourse.org/t/faster-disk-space-calculation-for-upload-heavy-instances/318997 "2024-07-29T11:17:03Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![Overgrow](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/overgrow/32/478189_2.png) [@Overgrow](https://meta.discourse.org/u/Overgrow)
#### Post date: [2024年七月29日 11:17 UTC](https://meta.discourse.org/t/faster-disk-space-calculation-for-upload-heavy-instances/318997/1 "2024-07-29T11:17:03Z")

</div>

`du` 命令用于检索上传占用的磁盘空间，它导致了我的管理仪表板性能问题。是的，我们有很多图片上传。我决定不完全禁用它（毕竟我们有 Grafana/Prometheus 仪表板），而是使用 `df` 来进行一个_非常粗略_的近似计算，以获得更快的速度。当然，管理员可以选择此更改，默认仍为 `du`。

我已经为此更改提交了一个 PR。这是我的第一个 PR，请对我温柔一点 :))

您可以在此处查看 PR：

> <https://github.com/discourse/discourse/pull/28113>
>
> This commit introduces the 'enable\_precise\_disk\_space\_calculation' feature that …allows admins to choose between using the 'du' command, which provides precise disk usage but is slower, and the 'df' command, which is faster but often inaccurate. This option is particularly useful for instances with 100,000+ uploads where the 'du' command can be detrimental.
> 
> The 'used' method now dynamically calculates disk usage based on the chosen option, ensuring accurate reporting of disk space on directories.

---

<div class="post-metadata">

### Author: ![tgxworld](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tgxworld/32/106117_2.png) [@tgxworld](https://meta.discourse.org/u/tgxworld)
#### Post date: [2024年八月8日 02:07 UTC](https://meta.discourse.org/t/faster-disk-space-calculation-for-upload-heavy-instances/318997/2 "2024-08-08T02:07:01Z")

</div>

> [@Overgrow](#):
>
> 导致我的管理员仪表板出现性能问题。

您对 `du` 命令花费了多长时间有大致的了解吗？我不太喜欢这种解决性能问题的方法，我认为有两种替代方案：

1. 仅使用 `Upload.sum(:filesize).to_i + OptimizedImage.sum(:filesize).to_i` 来确定 `uploads_used_bytes`，就像我们为外部存储所做的那样。
2. 引入一个后台作业，定期重新计算上传使用的字节数，并将其缓存到 Redis 中。

我个人更倾向于 (1)，因为它是一个更简单的解决方案。我们确实会损失一些准确性，但这里不需要 100% 的准确性。不过，这仍然比我们从 `df` 获得的近似值要好得多。

---

<div class="post-metadata">

### Author: ![Overgrow](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/overgrow/32/478189_2.png) [@Overgrow](https://meta.discourse.org/u/Overgrow)
#### Post date: [2024年八月10日 08:53 UTC](https://meta.discourse.org/t/faster-disk-space-calculation-for-upload-heavy-instances/318997/3 "2024-08-10T08:53:26Z")

</div>

感谢您的反馈。

`du` 在 HDD 上花费的时间超过一分钟，而在 SSD 上大约需要 20 秒。

我的理由是，如果您有一个依赖于上传的实例，就像我们的实例一样，您无论如何都会为上传设置一个专用分区。

但是，是的，您的解决方案 #1 看起来更简洁。我会研究一下并提交一个修改后的 PR。

---

<div class="post-metadata">

### Author: ![Overgrow](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/overgrow/32/478189_2.png) [@Overgrow](https://meta.discourse.org/u/Overgrow)
#### Post date: [2024年八月10日 10:05 UTC](https://meta.discourse.org/t/faster-disk-space-calculation-for-upload-heavy-instances/318997/4 "2024-08-10T10:05:49Z")

</div>

修改后的PR在此：

> <https://github.com/discourse/discourse/pull/28307>
>
> This commit enables the option to disable the use of the 'du' command, which can… be slow on Discourse instances with a high number of uploads. In such cases, the usage is calculated using the metadata stored in the SQL database.
> 
> This option is particularly useful for instances with 100,000+ uploads where the 'du' command can be detrimental.

感谢您的考虑。

---

<div class="post-metadata">

### Author: ![gerhard](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/gerhard/32/119479_2.png) [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [2024年十月24日 10:12 UTC](https://meta.discourse.org/t/faster-disk-space-calculation-for-upload-heavy-instances/318997/5 "2024-10-24T10:12:14Z")

</div>


