Editar 20/09/2012
Eu fiz isso muito complicado antes. Acredito que esses comandos são na verdade a maneira mais simples, ao mesmo tempo que formatam tudo muito 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
Editar: o comando foi atualizado para usar corretamente du -x ou du -d no RHEL5 ou 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'
Isso retornará diretórios com mais de 50 MB no sistema de arquivos "/" em formato ascendente, reursivo e legível por humanos e em um período de tempo razoavelmente rápido.
Pedido: Você pode ajudar a tornar este one-liner mais eficaz, mais rápido ou eficiente? Que tal mais elegante? Se você entendeu o que eu fiz lá, continue lendo.
O problema é que pode ser difícil discernir rapidamente quais diretórios contidos no diretório "/" estão contribuindo para a capacidade do sistema de arquivos "/" porque todos os outros sistemas de arquivos estão sob a raiz.
Isso excluirá todos os sistemas de arquivos não / ao executar du no Solaris 10 ou Red Hat el5 basicamente removendo um egrepped df de uma segunda exclusão de subshell egrep regex delimitada por pipe que é naturalmente excluída por um terceiro egrep no que eu gostaria de referir como "a baleia". O munge-fest se transforma freneticamente em alguns xargs du recicl onde du -x/-d é realmente útil (veja os comentários inferiores), e um egrep final gratuito cospe uma lista de diretórios relevantes e de alta capacidade que estão contidos exclusivamente dentro do sistema de arquivos "/", mas não em outros sistemas de arquivos montados. É muito desleixado.
Exemplo de plataforma Linux: xargs du -shx
senha = /
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 nestes 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
senha = /
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 nestes 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 de forma mais eficaz com problemas completos do sistema de arquivos "/" também conhecido como "root" em múltiplas plataformas que possuem um número devastador de montagens?
No Red Hat el5, du -x aparentemente evita a passagem para outros sistemas de arquivos. Embora possa ser assim, ele não parece fazer nada se for executado a partir do diretório /.
No Solaris 10, o sinalizador equivalente é du -d, o que aparentemente não traz surpresas.
(Espero estar fazendo errado.)
Adivinha? É muito lento.
Responder1
Seu problema, pelo que entendi, é que ele duestá descendo para outros sistemas de arquivos (alguns dos quais são montagens de rede ou SAN e demoram muito para contar a utilização).
Eu respeitosamente afirmo que se você está tentando monitorar a utilização do sistema de arquivos dué oerradoferramenta para o trabalho. Você deseja df(o que aparentemente você conhece desde que incluiu sua saída).
Analisar a saída de dfpode ajudá-lo a direcionar sistemas de arquivos específicos nos quais você deveria estar executando dupara determinar quais diretórios estão ocupando todo o seu espaço (ou se você tiver sorte, o sistema de arquivos completo tem uma parte responsável específica a quem você pode informar para descobrir isso. eles mesmos). Em ambos os casos, pelo menos você saberá que um sistema de arquivos está sendo preenchido antes de ficar cheio (e a saída é mais fácil de analisar).
Resumindo: corra dfprimeiro, depoisse você tiver queexecute duem qualquer sistema de arquivos dfidentificado como tendo utilização superior a (digamos) 85% para obter detalhes mais específicos.
Passando para o seu script, o motivo dude não respeitar o seu -d(or -x) sinalizador é a pergunta que você está fazendo:
# pwd
/
# du * (. . .etc. . .)
Você está pedindo dupara executar tudo em /- du -x /bin /home /sbin /usr /tmp /varetc. - duentão está fazendo exatamente o que você pediu (dando a você o uso de cada uma dessas coisas. Se um dos argumentos for uma raiz do sistema de arquivos, duassume que você sabe o que está fazendo e dando o uso dequesistema de arquivos até a primeira submontagem que encontrar.
Isso écriticamentediferente de du -x /("Conte-me /e ignore quaisquer submontagens").
Para corrigir seu script*não cdno diretório que você está analisando - em vez disso, basta executar
du /path/to/full/disk | [whatever you want to feed the output through]
Esta (ou qualquer outra sugestão que você possa receber) não resolve seus dois problemas principais:
Seu sistema de monitoramento é ad-hoc
Se você quiser pegar problemas antes que eles te mordam nos órgãos genitais, vocêrealmentepreciso implantar umplataforma de monitoramento decente. Se você estiver tendo problemas para convencer sua equipe de gerenciamento a aceitar isso, lembre-os de que o monitoramento adequado permite evitar tempo de inatividade.Seu ambiente (como você supôs corretamente) está uma bagunça
Não há muito a ser feito aqui, exceto reconstruir a coisa - éseutrabalho como SA para se levantar e apresentar um caso de negócios muito claro e ALTO sobre por que os sistemas precisam ser desativados um de cada vez e reconstruídos com uma estrutura que possa ser gerenciada.
Você parece ter um controle bastante decente sobre o que precisa ser feito, mas se tiver dúvidas, pergunte-lhes e tentaremos ajudar o máximo que pudermos (não podemos fazer sua arquitetura para você, mas nós pode responder questões conceituais ou práticas "Como faço Xcom Ycoisas do tipo ferramenta de monitoramento?"
Responder2
Resposta simples: instale uma ferramenta de monitoramento de infraestrutura (como ZenOSS, Zabixx, etc.).
Se você está procurando algo personalizado, talvez precise de algum tipo de camada de abstração para lidar com diferenças estranhas por máquina, em vez de gerenciar isso sempre manualmente?
Responder3
Faço essa recomendação com frequência. A ferramenta que defendo para cálculos ad-hoc de uso de disco é autilitário ncdu. Existe um --excludesinalizador que pode ser especificado várias vezes.
Existem versões empacotadas paraSolaris(CSWncdu), ou você pode compilá-lo a partir do código-fonte. Isso simplifica muito do que você está fazendo.
Responder4
Acho que o que você está procurando é algo comoncdu. Isso permitirá que você pare de navegar pelos diretórios e ainda consiga descobrir onde o disco está sendo consumido.
Vou repetir as outras respostas dizendo que esta é a ferramenta que você usadepoisseus sistemas de monitoramento detectaram um problema - não é o tipo de ferramenta que você gostaria de usar de forma não interativa. Na verdade, por ser baseado em ncurses, fazer isso seria um obstáculo. Qualquer administrador de sistemas que se preze permitirá que você baixe uma ferramenta simples e testada para evitar monstruosidades hackeadas e que consomem muitos recursos, como a que você descreveu. Ele usará muito mais memória, muito mais E/S e será muito mais perigoso do que aquele software "proibido".