☰

编辑 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，然后由第三个 egrep 进一步排除，我想称之为“鲸鱼”。混合过程疯狂升级为一些 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

我认为你正在寻找的是北卡罗莱纳大学。这样您就可以停止遍历目录，同时仍然能够找到磁盘被消耗的位置。

我会重复其他答案，说这是你使用的工具后您的监控系统检测到了问题 - 它不是您想要以非交互方式使用的工具。事实上，由于它基于 ncurses，因此这样做会很麻烦。任何称职的系统管理员都会让您下载经过审查的简单工具，以防止像您所描述的那样占用大量资源、被黑客攻击的 bash 怪物。它将使用更多的内存、更多的 I/O，并且比那个“被禁止”的软件危险得多。

相关内容