跨平台的、人類可讀的、真正忽略其他文件系統的根分區上的 du
編輯 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]
這(或您可能得到的任何其他建議)並不能解決您的兩個核心問題:
- 您的監控系統是臨時的
如果您想在問題咬到您的生殖器之前發現問題,您真的需要部署一個體面的監控平台。如果您無法讓您的管理團隊接受這一點,請提醒他們適當的監控可以讓您避免停機。 2. 您的環境(正如您正確地推測的那樣)是一團糟
除了重建東西之外,這裡沒有太多工作要做 -作為 SA,您的工作是站出來並提出一個非常清晰、非常響亮的商業案例來說明為什麼系統需要一次取下一個,然後用可管理的結構重建。
您似乎對需要做的事情有相當不錯的把握,但是如果您有任何問題,一定要問他們,我們會盡力提供幫助(我們不能為您做架構,但我們可以回答概念性問題或實用的“我如何
X
使用監控工具Y
?”類型的東西……