編集 2012/09/20

編集 2012/09/20

編集 2012/09/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'

これにより、「/」ファイルシステム内の 50 MB を超えるディレクトリが、昇順、再帰的、人間が読める形式で、かなり高速に返されます。

リクエスト: このワンライナーをより効果的、高速、効率的にするのを手伝ってもらえませんか? もっとエレガントにするのはどうでしょうか? 私が何をしたのか理解できたら、読み進めてください。

問題は、他のすべてのファイルシステムがルートの下にあるため、「/」ディレクトリの下にあるどのディレクトリが「/」ファイルシステムの容量に貢献しているかをすぐに判別することが難しい場合があることです。

これにより、Solaris 10 または Red Hat el5 で du を実行するときに、/ 以外のすべてのファイルシステムが除外されます。これは、基本的に、2 番目のパイプ区切りの egrep 正規表現サブシェル除外から egrepped df を変更することによって行われます。このサブシェル除外は、当然のことながら、私が「クジラ」と呼びたい 3 番目の 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

結果は次のとおりです。

リナックス:

            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まず走り、そして必要ならより具体的な詳細を取得するには、使用率が (たとえば) 85% を超えていると特定された任意のduファイルシステムで実行します。df


スクリプトに移ると、あなたの(または) フラグduが尊重されない理由は、あなたが尋ねている質問のためです:-d-x

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

--など、du以下にあるすべてのものを実行するように要求しています。 --は、要求したとおりに動作します(それぞれの使用方法を示します)。引数の 1 つがファイルシステムのルートである場合は、何をしているかわかっていると想定して、使用方法を示します。/du -x /bin /home /sbin /usr /tmp /varduduそれ最初に見つかったサブマウントまでのファイルシステム。

これは批判的にdu -x /(「サブマウントについて説明し/、サブマウントを無視する」)とは異なります。

スクリプトを修正するには*しないでください cd分析するディレクトリに、代わりに
du /path/to/full/disk | [whatever you want to feed the output through]


これ (またはあなたが得る他の提案) では、次の 2 つの主要な問題は解決されません。

  1. 監視システムはアドホックです
    性器に問題が起こる前に対処したいなら本当に展開する必要がある適切な監視プラットフォーム経営陣にこのことに納得してもらうのが難しい場合は、適切な監視によってダウンタイムを回避できることを経営陣に思い出させてください。

  2. あなたの環境は(あなたが正しく推測したように)めちゃくちゃです
    再建する以外にここでできることはあまりない - それはあなたのSA としての仕事は、立ち上がって、システムを 1 つずつ削除し、管理可能な構造で再構築する必要がある理由について、非常に明確で大声でビジネス ケースを作成することです。

何をすべきかについては、かなりよく理解されているようですが、質問がある場合は、ぜひ質問してください。私たちはできる限りお手伝いします (アーキテクチャについては対応できませんが、概念的な質問や「X監視ツールで何をすればよいですかY?」といった実用的な質問には回答できます)。

答え2

簡単な答え: インフラストラクチャ監視ツール (ZenOSS、Zabixx など) をインストールします。

何かカスタムのものを探している場合、毎回手動で管理するのではなく、マシンごとの奇妙な違いを処理するための何らかの抽象化レイヤーが必要になるかもしれません。

答え3

私はよくこのことを勧めます。アドホックなディスク使用量の計算に私が推奨するツールはncdu ユーティリティ--exclude複数回指定できるフラグがあります。

パッケージ版もありますソラリス(CSWncdu)、またはソースからコンパイルすることもできます。これにより、作業が大幅に簡素化されます。

答え4

あなたが探しているのは次のようなものだと思いますNCDUこれにより、ディレクトリのトラバースを停止しながらも、ディスクが消費されている場所を見つけることができます。

他の回答と同様に、これはあなたが使用するツールです監視システムが問題を検出しました。これは非対話的に使用したい種類のツールではありません。実際、これは ncurses ベースなので、そうすることは不便です。有能なシステム管理者であれば、あなたが説明したようなリソースを大量に消費する、寄せ集めの bash 怪物を防ぐために、検証済みのシンプルなツールをダウンロードすることを許可するでしょう。これは、その「禁止」ソフトウェアよりもはるかに多くのメモリと I/O を使用し、はるかに危険です。

関連情報