アップロードによって使用されるディスクスペースを取得するために使用される du コマンドは、管理ダッシュボードのパフォーマンスの問題を引き起こしていました。はい、画像アップロードは大量にあります。これを完全に無効にするのではなく(結局のところ、grafana/prometheus ダッシュボードがあります)、df を使用したはるかに高速な 非常に大まかな 近似値に置き換えることにしました。この変更は、もちろん管理者によって選択可能であり、デフォルトは du です。
この変更のために PR を提出しました。初めての PR なので、お手柔らかにお願いします :))
PR はこちらで確認できます。
main ← overgrow:disk_space
opened 11:06AM - 29 Jul 24 UTC
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.
tgxworld
(Alan Tan)
2024 年 8 月 8 日午前 2:07
2
du にどれくらいの時間がかかっていたか、おおよその目安はありますか?このアプローチでパフォーマンスの問題を解決することにはあまり乗り気ではなく、2つの代替案があると思います。
uploads_used_bytes を決定するために、外部ストアで行っているように、単に Upload.sum(:filesize).to_i + OptimizedImage.sum(:filesize).to_i を使用します。
アップロードによって使用されたバイトを定期的に再計算し、Redis にキャッシュするバックグラウンドジョブを導入します。
個人的には、(1) の方がはるかに簡単なソリューションなので、こちらの方が乗り気です。精度は多少失われますが、ここでは 100% の精度は必要ありません。それでも、df から得られる近似値よりもはるかに良くなるはずです。
「いいね!」 2
フィードバックありがとうございます。
du は HDD では 1 分以上かかっていましたが、SSD では約 20 秒でした。
アップロードに依存するインスタンスがある場合、いずれにせよアップロード専用のパーティションがあるというのが私の考えです。
しかし、はい、あなたのソリューション #1 の方がエレガントに見えます。それを調べて、変更した PR を提出します。