Linux

跨平台的、人類可讀的、真正忽略其他文件系統的根分區上的 du

  • September 20, 2012

編輯 2012 年 9 月 20 日

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

   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作為“鯨魚”。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,這顯然並不令人意外。

(我希望我只是做錯了。)

你猜怎麼了?它真的很慢。

據我了解,您的問題du是下降到其他文件系統(其中一些是網路或 SAN 安裝,並且需要很長時間才能計算使用率)。

我恭敬地提出,如果您試圖監視文件系統使用率,那麼該工作的工具du是*錯誤的。*你想要df(你顯然知道,因為你包含了它的輸出)。

解析輸出df可以幫助您定位您應該在其中執行的特定文件系統,du以確定哪些目錄正在佔用您的所有空間(或者如果您很幸運,完整的文件系統有一個特定的責任方,您可以告訴他找出它他們自己)。在任何一種情況下,至少您都會知道文件系統在它滿之前就被填滿了(並且輸出更容易解析)。

簡而言之:df首先執行,然後如果您必須du在任何df被辨識為使用率超過(例如)85% 的文件系統上執行以獲得更具體的詳細資訊。


繼續您的腳本,原因du是不尊重您的-d(or -x) 標誌是因為您要問的問題:

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

您要求在–等 –du下的所有內容上執行,然後完全按照您的要求執行(為您提供每項內容的用法。如果其中一個參數恰好是文件系統根目錄,則假設您知道自己在做什麼)做並將文件系統的使用直到它找到的第一個子掛載。/``du -x /bin /home /sbin /usr /tmp /var``du``du

這與(“告訴我有關並忽略任何子安裝”)截然不同du -x /``/

要修復您的腳本*不要 cd進入您正在分析的目錄 - 而只是執行

du /path/to/full/disk | [whatever you want to feed the output through]


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

  1. 您的監控系統是臨時的

如果您想在問題咬到您的生殖器之前發現問題,您真的需要部署一個體面的監控平台。如果您無法讓您的管理團隊接受這一點,請提醒他們適當的監控可以讓您避免停機。 2. 您的環境(正如您正確地推測的那樣)是一團糟

除了重建東西之外,這裡沒有太多工作要做 -作為 SA,您的工作是站出來並提出一個非常清晰、非常響亮的商業案例來說明為什麼系統需要一次取下一個,然後用可管理的結構重建。

您似乎對需要做的事情有相當不錯的把握,但是如果您有任何問題,一定要問他們,我們會盡力提供幫助(我們不能為您做架構,但我們可以回答概念性問題或實用的“我如何X使用監控工具Y?”類型的東西……

引用自:https://serverfault.com/questions/421739