☰

編輯 09/20/2012

tag-icon • tag-icon linux solaris disk-space-utilization xargs du
編輯 09/20/2012

編輯 09/20/2012

我之前把這個方法搞得太複雜了。我相信這些命令實際上是更簡單的方法，同時仍然可以很好地格式化所有內容。

    RHEL 5
    du -x / | sort -n |cut -d\/ -f1-2|sort -k2 -k1,1nr|uniq -f1|sort -n|tail -10|cut -f2|xargs du -sxh

    Solaris 10
    du -d / | sort -n |cut -d\/ -f1-2|sort -k2 -k1,1nr|uniq -f1|sort -n|tail -10|cut -f2|xargs du -sdh

編輯：指令已更新，可以分別在 RHEL5 或 Solaris 10 上正確使用 du -x 或 du -d。

RHEL5

du -x /|egrep -v "$(echo $(df|awk '{print $1 "\n" $5 "\n" $6}'|cut -d\/ -f2-5|egrep -v "[0-9]|^$|Filesystem|Use|Available|Mounted|blocks|vol|swap")|sed 's/ /\|/g')"|egrep -v "proc|sys|media|selinux|dev|platform|system|tmp|tmpfs|mnt|kernel"|cut -d\/ -f1-3|sort -k2 -k1,1nr|uniq -f1|sort -k1,1n|cut -f2|xargs du -sxh|egrep "G|[5-9][0-9]M|[1-9][0-9][0-9]M"|sed '$d'

索拉里斯

du -d /|egrep -v "$(echo $(df|awk '{print $1 "\n" $5 "\n" $6}'|cut -d\/ -f2-5|egrep -v "[0-9]|^$|Filesystem|Use|Available|Mounted|blocks|vol|swap")|sed 's/ /\|/g')"|egrep -v "proc|sys|media|selinux|dev|platform|system|tmp|tmpfs|mnt|kernel"|cut -d\/ -f1-3|sort -k2 -k1,1nr|uniq -f1|sort -k1,1n|cut -f2|xargs du -sdh|egrep "G|[5-9][0-9]M|[1-9][0-9][0-9]M"|sed '$d'

這將以升序、遞歸、人類可讀的格式在相當快的時間內傳回「/」檔案系統中超過 50mb 的目錄。

請求：你能幫忙讓這段話變得更有效、更快、更有效率嗎？更優雅一點怎麼樣？如果你了解我在那裡做了什麼，請繼續閱讀。

問題在於，很難快速辨別「/」目錄下包含的哪些目錄對「/」檔案系統容量有貢獻，因為所有其他檔案系統都屬於根目錄。

當在Solaris 10 或Red Hat el5 上執行du 時，這將排除所有非/ 檔案系統，方法是從第二個管道分隔的egrep正規表示式子shell排除中刪除一個egrepped df，該子shell自然會被第三個egrep進一步排除，我想參考被稱為「鯨魚」。 munge-fest 瘋狂地升級為一些 xargs du 回收，其中 du -x/-d 實際上很有用（請參閱底部評論），最後，無償的 egrep 吐出一系列相關的高容量目錄，這些目錄專門包含在“ /”檔案系統，但不在其他已安裝的檔案系統內。這是非常馬虎的。

Linux 平台範例：xargs du -shx

密碼 = /

du *|egrep -v "$(echo $(df|awk '{print $1 "\n" $5 "\n" $6}'|cut -d\/ -f2-5|egrep -v "[0-9]|^$|Filesystem|Use|Available|Mounted|blocks|vol|swap")|sed 's/ /\|/g')"|egrep -v "proc|sys|media|selinux|dev|platform|system|tmp|tmpfs|mnt|kernel"|cut -d\/ -f1-2|sort -k2 -k1,1nr|uniq -f1|sort -k1,1n|cut -f2|xargs du -shx|egrep "G|[5-9][0-9]M|[1-9][0-9][0-9]M"

這是針對這些檔案系統運行的：

            Linux builtsowell 2.6.18-274.7.1.el5 #1 SMP Mon Oct 17 11:57:14 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

            df -kh

            Filesystem            Size  Used Avail Use% Mounted on
            /dev/mapper/mpath0p2  8.8G  8.7G  90M   99% /
            /dev/mapper/mpath0p6  2.0G   37M  1.9G   2% /tmp
            /dev/mapper/mpath0p3  5.9G  670M  4.9G  12% /var
            /dev/mapper/mpath0p1  494M   86M  384M  19% /boot
            /dev/mapper/mpath0p7  7.3G  187M  6.7G   3% /home
            tmpfs                  48G  6.2G   42G  14% /dev/shm
            /dev/mapper/o10g.bin   25G  7.4G   17G  32% /app/SIP/logs
            /dev/mapper/o11g.bin   25G   11G   14G  43% /o11g
            tmpfs                 4.0K     0  4.0K   0% /dev/vx
            lunmonster1q:/vol/oradb_backup/epmxs1q1
                                  686G  507G  180G  74% /rpmqa/backup
            lunmonster1q:/vol/oradb_redo/bisxs1q1
                                  4.0G  1.6G  2.5G  38% /bisxs1q/rdoctl1
            lunmonster1q:/vol/oradb_backup/bisxs1q1
                                  686G  507G  180G  74% /bisxs1q/backup
            lunmonster1q:/vol/oradb_exp/bisxs1q1
                                  2.0T  1.1T  984G  52% /bisxs1q/exp
            lunmonster2q:/vol/oradb_home/bisxs1q1
                                   10G  174M  9.9G   2% /bisxs1q/home
            lunmonster2q:/vol/oradb_data/bisxs1q1
                                   52G  5.2G   47G  10% /bisxs1q/oradata
            lunmonster1q:/vol/oradb_redo/bisxs1q2
                                  4.0G  1.6G  2.5G  38% /bisxs1q/rdoctl2
            ip-address1:/vol/oradb_home/cspxs1q1
                                   10G  184M  9.9G   2% /cspxs1q/home
            ip-address2:/vol/oradb_backup/cspxs1q1
                                  674G  314G  360G  47% /cspxs1q/backup
            ip-address2:/vol/oradb_redo/cspxs1q1
                                  4.0G  1.5G  2.6G  37% /cspxs1q/rdoctl1
            ip-address2:/vol/oradb_exp/cspxs1q1
                                  4.1T  1.5T  2.6T  37% /cspxs1q/exp
            ip-address2:/vol/oradb_redo/cspxs1q2
                                  4.0G  1.5G  2.6G  37% /cspxs1q/rdoctl2
            ip-address1:/vol/oradb_data/cspxs1q1
                                  160G   23G  138G  15% /cspxs1q/oradata
            lunmonster1q:/vol/oradb_exp/epmxs1q1
                                  2.0T  1.1T  984G  52% /epmxs1q/exp
            lunmonster2q:/vol/oradb_home/epmxs1q1
                                   10G   80M   10G   1% /epmxs1q/home
            lunmonster2q:/vol/oradb_data/epmxs1q1
                                  330G  249G   82G  76% /epmxs1q/oradata
            lunmonster1q:/vol/oradb_redo/epmxs1q2
                                  5.0G  609M  4.5G  12% /epmxs1q/rdoctl2
            lunmonster1q:/vol/oradb_redo/epmxs1q1
                                  5.0G  609M  4.5G  12% /epmxs1q/rdoctl1
            /dev/vx/dsk/slaxs1q/slaxs1q-vol1
                                  183G   17G  157G  10% /slaxs1q/backup
            /dev/vx/dsk/slaxs1q/slaxs1q-vol4
                                  173G   58G  106G  36% /slaxs1q/oradata
            /dev/vx/dsk/slaxs1q/slaxs1q-vol5
                                   75G  952M   71G   2% /slaxs1q/exp
            /dev/vx/dsk/slaxs1q/slaxs1q-vol2
                                  9.8G  381M  8.9G   5% /slaxs1q/home
            /dev/vx/dsk/slaxs1q/slaxs1q-vol6
                                  4.0G  1.6G  2.2G  42% /slaxs1q/rdoctl1
            /dev/vx/dsk/slaxs1q/slaxs1q-vol3
                                  4.0G  1.6G  2.2G  42% /slaxs1q/rdoctl2
            /dev/mapper/appoem     30G  1.3G   27G   5% /app/em

這是結果：

Linux：

            54M     etc/gconf
            61M     opt/quest
            77M     opt
            118M    usr/  ##===\
            149M    etc
            154M    root
            303M    lib/modules
            313M    usr/java  ##====\
            331M    lib
            357M    usr/lib64  ##=====\
            433M    usr/lib  ##========\
            1.1G    usr/share  ##=======\
            3.2G    usr/local  ##========\
            5.4G    usr   ##<=============Ascending order to parent
            94M     app/SIP   ##<==\
            94M     app   ##<=======Were reported as 7gb and then corrected by second du with -x.

===============================================

Solaris 平台範例：xargs du -shd

密碼 = /

du *|egrep -v "$(echo $(df|awk '{print $1 "\n" $5 "\n" $6}'|cut -d\/ -f2-5|egrep -v "[0-9]|^$|Filesystem|Use|Available|Mounted|blocks|vol|swap")|sed 's/ /\|/g')"|egrep -v "proc|sys|media|selinux|dev|platform|system|tmp|tmpfs|mnt|kernel"|cut -d\/ -f1-2|sort -k2 -k1,1nr|uniq -f1|sort -k1,1n|cut -f2|xargs du -sh|egrep "G|[5-9][0-9]M|[1-9][0-9][0-9]M"

這是針對這些檔案系統運行的：

            SunOS solarious 5.10 Generic_147440-19 sun4u sparc SUNW,SPARC-Enterprise

            Filesystem             size   used  avail capacity  Mounted on
             kiddie001Q_rpool/ROOT/s10s_u8wos_08a  8G   7.7G    1.3G    96%    / 
            /devices                 0K     0K     0K     0%    /devices
            ctfs                     0K     0K     0K     0%    /system/contract
            proc                     0K     0K     0K     0%    /proc
            mnttab                   0K     0K     0K     0%    /etc/mnttab
            swap                    15G   1.8M    15G     1%    /etc/svc/volatile
            objfs                    0K     0K     0K     0%    /system/object
            sharefs                  0K     0K     0K     0%    /etc/dfs/sharetab
            fd                       0K     0K     0K     0%    /dev/fd
            kiddie001Q_rpool/ROOT/s10s_u8wos_08a/var    31G   8.3G   6.6G    56%    /var
            swap                   512M   4.6M   507M     1%    /tmp
            swap                    15G    88K    15G     1%    /var/run
            swap                    15G     0K    15G     0%    /dev/vx/dmp
            swap                    15G     0K    15G     0%    /dev/vx/rdmp
            /dev/dsk/c3t4d4s0   3   20G   279G    41G    88%    /fs_storage
            /dev/vx/dsk/oracle/ora10g-vol1  292G   214G    73G    75%     /o10g
            /dev/vx/dsk/oec/oec-vol1    64G    33G    31G    52%    /oec/runway
            /dev/vx/dsk/oracle/ora9i-vol1   64G    33G    31G   59%    /o9i
            /dev/vx/dsk/home     23G    18G   4.7G    80%    /export/home
            /dev/vx/dsk/dbwork/dbwork-vol1 292G   214G    73G    92%    /db03/wk01
            /dev/vx/dsk/oradg/ebusredovol   2.0G   475M   1.5G    24%    /u21
            /dev/vx/dsk/oradg/ebusbckupvol   200G    32G   166G    17%    /u31
            /dev/vx/dsk/oradg/ebuscrtlvol   2.0G   475M   1.5G    24%    /u20
            kiddie001Q_rpool       31G    97K   6.6G     1%    /kiddie001Q_rpool
            monsterfiler002q:/vol/ebiz_patches_nfs/NSA0304   203G   173G    29G    86%    /oracle/patches
            /dev/odm                 0K     0K     0K     0%    /dev/odm

這是結果：

索拉里斯：

            63M     etc
            490M    bb
            570M    root/cores.ric.20100415
            1.7G    oec/archive
            1.1G    root/packages
            2.2G    root
            1.7G    oec

=============

如何更有效地處理具有大量掛載的多個平台上的“/”（又稱“根”）檔案系統完整問題？

在 Red Hat el5 上，du -x 顯然避免了遍歷其他檔案系統。雖然可能是這樣，但如果從 / 目錄運行，它似乎不會執行任何操作。

在 Solaris 10 上，等效標誌是 du -d，這顯然並不令人驚訝。

（我希望我剛才做錯了。）

你猜怎麼了？真的很慢。

答案1

據我了解，您的問題是，它du正在下降到其他檔案系統（其中一些是網路或 SAN 安裝，並且需要很長時間來計算利用率）。

我恭敬地提出，如果您想監視檔案系統的使用率du，那麼錯誤的工作的工具。你想要df（你顯然知道，因為你包含了它的輸出）。

解析輸出df可以幫助您定位應該在其中運行的特定文件系統，du以確定哪些目錄正在佔用您的所有空間（或者如果您幸運的話，整個文件系統有一個特定的負責方，您可以告訴他來解決這個問題他們自己）。在任何一種情況下，至少您都會知道檔案系統在填滿之前就已經填滿了（而且輸出更容易解析）。

簡而言之：先跑df，然後如果你必須du在任何標識df為利用率超過（例如）85% 的檔案系統上運行，以獲得更具體的詳細資訊。

繼續進入您的腳本，du不尊重您的-d(或-x) 標誌的原因是您提出的問題：

 # pwd   
 /
 # du * (. . .etc. . .)

您要求在-等等 -du下的所有內容上運行，然後完全按照您的要求進行操作（為您提供每一項的用法。如果其中一個參數恰好是文件系統根，則假設您知道自己在做什麼做並給出用法/du -x /bin /home /sbin /usr /tmp /vardudu那檔案系統直到它找到的第一個子安裝。

這是批判地du -x /與（“告訴我/並忽略任何子安裝”）不同。

修復你的腳本*不 cd進入您正在分析的目錄 - 而只是運行
du /path/to/full/disk | [whatever you want to feed the output through]

這個（或您可能得到的任何其他建議）並不能解決您的兩個核心問題：

  1. 您的監控系統是臨時的
    如果您想在問題咬到您的生殖器之前發現它們，您可以真的需要部署一個體面的監控平台。如果您無法讓管理團隊接受這一點，請提醒他們適當的監控可以讓您避免停機。

  2. 你的環境（正如你正確地猜測的那樣）一團糟
    除了重建這個東西之外，這裡沒什麼可做的——它是你的作為 SA 的工作是站出來提出一個非常清晰、非常響亮的業務案例，說明為什麼需要一次拆除一個系統並使用可管理的結構進行重建。

您似乎對需要完成的工作有相當不錯的把握，但如果您有任何疑問，請務必詢問他們，我們將盡力提供協助（我們無法為您完成您的架構，但我們可以回答概念性問題或實際問題“我如何使用X監控工具Y？”

答案2

簡單答案：安裝基礎設施監控工具（例如ZenOSS、Zabixx等）。

如果您正在尋找自訂的東西，也許您需要某種抽象層來處理奇怪的每台機器差異，而不是每次都手動管理？

答案3

我經常提出這個建議。我提倡的用於臨時磁碟使用計算的工具是NCDU實用程式。有一個--exclude可以指定多次的標誌。

有打包版本索拉里斯(CSWncdu)，或者您可以從原始程式碼編譯它。它簡化了您正在做的很多事情。

答案4

我認為你正在尋找的是類似的東西NCDU。這將使您停止遍歷目錄，同時仍能找到正在消耗磁碟的位置。

我會回應其他答案，說這是你使用的工具後您的監控系統偵測到問題 - 這不是您想要以非互動方式使用的工具。事實上，因為它是基於 ncurses 的，所以這樣做會很麻煩。任何稱職的系統管理員都會讓您下載一個經過審查的簡單工具，以防止像您所描述的那樣消耗資源、駭客攻擊在一起的 bash 怪物。它將使用更多的記憶體、更多的 I/O，並且比「禁止」軟體更危險。

相關內容