作者 主題: Linux关于查看目录大小命令du,对于特别大的目录用du查看时间特别长,怎么办  (閱讀 7211 次)

0 會員 與 1 訪客 正在閱讀本文。

lhr

  • 可愛的小學生
  • *
  • 文章數: 17
    • 檢視個人資料
在linux下有没有可以比du命令更快的查看目录大小的工具

dark

  • 俺是博士!
  • *****
  • 文章數: 1581
    • 檢視個人資料
執行兩次 ... 第二次就非常快囉 ..... 開個玩笑別生氣

這時如果您檔案的規劃無法從 df 磁區來判斷大小 , 恐怕也接近無解了
會這麼說是推測 ..
您檔案是數不完的小檔案 ... (通常搜尋引擎思維會如此)
ls , cp 等不少指令此時都會說 "引數過長" 而中止
若此時不靠 raid 也很難備份 (若真遇上 .. find 遞迴或 tar搭配管線 , 超久也得將就了)


一般如何規劃 , 小弟也不知道
或許不同 index 分散不同主機吧 ??

lhr

  • 可愛的小學生
  • *
  • 文章數: 17
    • 檢視個人資料
主要是为了去获取目录大小。而且是对不同的用户而言
查了好久确实也没什么好办法,除非有更优化的计算算法出现。

netman

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 17462
    • 檢視個人資料
    • http://www.study-area.org
每一個目錄都掛到獨立的LVM如何?
這樣 df -h 就很快... 但要扣除 metadata size...

hoyo

  • 榮譽博士
  • 俺是博士!
  • *****
  • 文章數: 4047
  • 性別: 男
  • 有需要的時候,學習就不會分階段。
    • 檢視個人資料
    • 樂咖黑電腦學習網
NAS 的作法是「定時算起來放」

所以看到的數字是先算好的,不是真實的

不過通常都有一個即時更新的按鈕可以使用
受人與魚,不如授人與漁
上海自來水來自海上;倫敦好奇人奇好敦倫

netman

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 17462
    • 檢視個人資料
    • http://www.study-area.org
NAS 的作法是「定時算起來放」

所以看到的數字是先算好的,不是真實的

不過通常都有一個即時更新的按鈕可以使用

這也是個方法,設個 crontab 來跑 du ?

lhr

  • 可愛的小學生
  • *
  • 文章數: 17
    • 檢視個人資料
crontab来跑du意义不大,用的时候目录大小无法确定其准确性。
每一個目錄都掛到獨立的LVM如何?
這樣 df -h 就很快... 但要扣除 metadata size...
这个是针对用户而言的,所以这个方法虽然可行,但是不现实,对用户要求太高

netman

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 17462
    • 檢視個人資料
    • http://www.study-area.org
crontab来跑du意义不大,用的时候目录大小无法确定其准确性。
每一個目錄都掛到獨立的LVM如何?
這樣 df -h 就很快... 但要扣除 metadata size...
这个是针对用户而言的,所以这个方法虽然可行,但是不现实,对用户要求太高

crontab 來跑過 du
下次跑 du 不知道會不會快些呢? 有沒有機會測試看看?

Yamaka

  • 俺是博士!
  • *****
  • 文章數: 4913
    • 檢視個人資料
    • http://www.ecmagic.com
應該不會每次 du 都要花很長時間吧
每次 du 後都會有 cache
除非是清 cache 或  ram 不夠

每次 du 排除不必要的資料夾啦、網路資料夾啦.....

gwstudy

  • 活潑的大學生
  • ***
  • 文章數: 205
    • 檢視個人資料
我在一個 ubuntu 12.04 的 server 跑一次 du, 花了一分多鐘,再做一次,時間差不多。
會嫌慢應該是像這樣,檔案太多,目錄太多,讓系統自己 cache 可能效用不大。
這種情況很可能大部份目錄是不變的,所以最好自己寫個程式把每個目錄 du 一次存起來,
下次再 du 只 du 有變動的目錄即可,這樣應該可以飛快地算出結果。

dark

  • 俺是博士!
  • *****
  • 文章數: 1581
    • 檢視個人資料
用戶要求 ... 您的用戶檔案都不放音樂影音的嗎 ?
如果是開發需求 , 該從 svn server 去設計架構才是
若是雲端 , 猜想應該用 md5 歸類避免重複
邏輯上也屬搜尋引擎 , 計算也是對照清單重新指向

小弟一些圖檔或數據的小檔案 , 倒是都使用 iso 儲存
歸類好 , 引用時自動掛載卸載

雖然不知您應用方向 , 但既然使用者相關
那是否思考 quota 方向 ?

若不想改變使用習慣 , 如樓上所說 .. 自己 ... ?? ... 耶 ? 不對阿 ...
應該是要請樓上 gwstudy 大大貼出來分享才是 ...  ;D



netman

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 17462
    • 檢視個人資料
    • http://www.study-area.org
1st run:
real   0m12.611s
user   0m0.697s
sys   0m3.788s

2nd run:
real   0m1.439s
user   0m0.428s
sys   0m1.011s

3rd run:
real   0m1.461s
user   0m0.415s
sys   0m1.041s

lhr

  • 可愛的小學生
  • *
  • 文章數: 17
    • 檢視個人資料
1st run:
real   0m12.611s
user   0m0.697s
sys   0m3.788s

2nd run:
real   0m1.439s
user   0m0.428s
sys   0m1.011s

3rd run:
real   0m1.461s
user   0m0.415s
sys   0m1.041s

我也测了下确实可行,但是还有一个问题是目录名无法知道,导致规则不好建

rainday

  • 鑽研的研究生
  • *****
  • 文章數: 738
  • 性別: 男
  • enhancing and optimizing
    • 檢視個人資料
du會實際計算每個block ,慢是在這裡,實際上只要寫個程式讀取每個檔案的file stat做Size加總,計算就變很快
利用檔案系統做quota計算也是種方法
<0  =_=  Don't learn to hack , hack to learn.

lhr

  • 可愛的小學生
  • *
  • 文章數: 17
    • 檢視個人資料
du會實際計算每個block ,慢是在這裡,實際上只要寫個程式讀取每個檔案的file stat做Size加總,計算就變很快
利用檔案系統做quota計算也是種方法
du遍历的是文件的大小统计的吧

netman

  • 管理員
  • 俺是博士!
  • *****
  • 文章數: 17462
    • 檢視個人資料
    • http://www.study-area.org
du會實際計算每個block ,慢是在這裡,實際上只要寫個程式讀取每個檔案的file stat做Size加總,計算就變很快
利用檔案系統做quota計算也是種方法
du遍历的是文件的大小统计的吧
重複推敲一下rainday大大的回覆?