Multiplataforma, legível por humanos, du na partição raiz que realmente ignora outros sistemas de arquivos

Question

Editar 20/09/2012

Eu fiz isso muito complicado antes. Acredito que esses comandos são, na verdade, o modo mais simples, enquanto ainda formatamos tudo bem.

    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

Edit: O comando foi atualizado para usar corretamente du -x ou du -d no RHEL5 ou no Solaris 10, respectivamente.

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'

Solaris

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'

Isto retornará diretórios acima de 50mb dentro do sistema de arquivos "/" em formato ascendente, reutilizável e legível por humanos, e em um tempo razoavelmente rápido.

Solicitação: Você pode ajudar a tornar esse recurso mais eficaz, mais rápido ou eficiente? Que tal mais elegante? Se você entendeu o que eu fiz lá, por favor, continue lendo.

O problema é que pode ser difícil discernir rapidamente quais diretórios contidos sob o diretório "/" estão contribuindo para a capacidade do sistema de arquivos "/" porque todos os outros sistemas de arquivos estão no root.

Isso excluirá todos os non / filesystems quando executando du no Solaris 10 ou Red Hat el5 basicamente usando uma df egrepped de uma segunda exclusão de subshell egrep regex delimitada por pipe que é naturalmente excluída por um terceiro egrep no que eu faria gostaria de se referir como "a baleia". O munge-fest se expande freneticamente em alguns momentos da reciclagem, onde du-x / -d é realmente útil (veja os comentários abaixo), e um egrep final e gratuito apresenta uma lista de diretórios relevantes e de alta capacidade que estão contidos exclusivamente dentro do "/" sistema de arquivos, mas não dentro de outros sistemas de arquivos montados. É muito desleixado.

Exemplo da plataforma Linux: xargs du -shx

pwd = /

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"

Isso está sendo executado nesses sistemas de arquivos:

            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

Este é o resultado:

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.

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

Exemplo da plataforma Solaris: xargs du -shd

pwd = /

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"

Isso está sendo executado nesses sistemas de arquivos:

            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

Este é o resultado:

Solaris:

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

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

Como alguém poderia lidar mais efetivamente com os problemas completos do sistema de arquivos "/" aka "root" em várias plataformas que possuem um número devastador de montagens?

No Red Hat el5, du -x aparentemente evita a travessia para outros sistemas de arquivos. Embora isso possa ser verdade, ele não parece fazer nada se for executado no diretório /.

No Solaris 10, a bandeira equivalente é du-d, que aparentemente não traz surpresas.

(Eu estou esperando que eu esteja fazendo errado.)

Adivinha o que? É muito lento.

    

Answer 1

O seu problema, pelo que entendi, é que du está descendo para outros sistemas de arquivos (alguns dos quais são montagens de rede ou SAN e levam muito tempo para contar a utilização).

Eu respeitosamente submeto que se você está tentando monitorar a utilização do sistema de arquivos du é a ferramenta errada para o trabalho. Você quer df (que aparentemente você conhece desde que incluiu sua saída).

A análise da saída de df pode ajudá-lo a direcionar sistemas de arquivos específicos nos quais você deve executar du para determinar quais diretórios estão destruindo todo o seu espaço (ou se tiver sorte, o sistema de arquivos completo tem uma parte responsável específica quem você pode dizer para descobrir por si mesmos). Em qualquer caso, pelo menos você saberá que um sistema de arquivos está sendo preenchido antes de estar cheio (e a saída é mais fácil de analisar).

Resumindo: Execute df primeiro, depois se tiver que executar du em qualquer sistema de arquivos df identificado como tendo uma utilização acima de (digamos) 85% para obter detalhes mais específicos.

Passando para seu script, o motivo du não está respeitando seu sinal -d (ou -x ) é devido à pergunta que você está fazendo:

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

Você está pedindo para o du executar tudo em / - du -x /bin /home /sbin /usr /tmp /var etc. - du está fazendo exatamente o que você pediu (dando a você o uso de cada uma dessas coisas. os argumentos passam a ser uma raiz do sistema de arquivos du assume que você sabe o que está fazendo e dá o uso do esse sistema de arquivos até a primeira submontagem encontrada.

Isso é criticamente diferente de du -x / ("Fale-me sobre / e ignore quaisquer submontagens").

Para corrigir seu script * não cd no diretório que você está analisando, execute apenas du /path/to/full/disk | [whatever you want to feed the output through]

Isso (ou qualquer outra sugestão que você possa ter) não resolve seus dois principais problemas:

1. Seu sistema de monitoramento é ad-hoc
   Se você quer pegar os problemas antes que eles o mordam nos órgãos genitais, você realmente precisa implantar uma plataforma de monitoramento decente . Se você está tendo problemas para incluir sua equipe de gerenciamento, lembre-os de que o monitoramento adequado permite evitar o tempo de inatividade.

2. Seu ambiente (como você supôs corretamente) é uma bagunça
   Não há muito a ser feito aqui, exceto reconstruir a coisa - é o seu trabalho como o SA para se levantar e fazer um caso muito claro, muito alto para por que os sistemas precisam ser retirados um de cada vez. e reconstruído com uma estrutura que pode ser gerenciada.

Você parece ter um controle decente sobre o que precisa ser feito, mas se você tiver dúvidas, pergunte a todos e tentaremos ajudar o máximo que pudermos (não podemos fazer sua arquitetura para você , mas podemos responder a perguntas conceituais ou práticas "Como faço X com a ferramenta de monitoramento Y ?" digite coisas ...

    

Answer 2

Resposta simples: instale uma ferramenta de monitoramento de infraestrutura (como ZenOSS, Zabixx, etc.).

Se você está procurando por algo personalizado, talvez você precise de algum tipo de camada de abstração para lidar com diferenças estranhas por máquina em vez de gerenciar isso manualmente a cada vez?

    

Answer 3

Eu faço essa recomendação com frequência. A ferramenta que defendo para cálculos de uso de disco ad-hoc é o utilitário ncdu . Há um sinalizador --exclude que pode ser especificado várias vezes.

Existem versões empacotadas para o Solaris (CSWncdu), ou você pode compilá-lo a partir do código-fonte. Simplifica muito do que você está fazendo.

    

Answer 4

Acho que o que você está procurando é algo como ncdu . Isso permitirá que você pare de percorrer diretórios e, ao mesmo tempo, consiga descobrir onde o disco está sendo consumido.

Eu vou repetir as outras respostas dizendo que esta é a ferramenta que você usa após seus sistemas de monitoramento detectaram um problema - não é o tipo de ferramenta que você gostaria de usar não-interativamente. Na verdade, porque é baseado em ncurses, isso seria um cludge. Qualquer administrador de sistemas que se preze, permitirá que você faça o download de uma ferramenta simples e bem-sucedida para evitar monstruosidades com fome de recursos e hackeadas, como a que você descreveu. Ele usará muito mais memória, muito mais E / S e será muito mais perigoso do que o software "proibido".