Editar 20/09/2012
Hice esto demasiado complicado antes. Creo que estos comandos son en realidad la forma más sencilla, sin dejar de formatear todo bien.
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: el comando se ha actualizado para utilizar correctamente du -x o du -d en RHEL5 o 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'
Esto devolverá directorios de más de 50 MB dentro del sistema de archivos "/" en formato ascendente, recursivo, legible por humanos y en un período de tiempo razonablemente rápido.
Solicitud: ¿Puedes ayudar a que este resumen sea más eficaz, más rápido o más eficiente? ¿Qué tal más elegante? Si entiendes lo que hice allí, sigue leyendo.
El problema es que puede ser difícil discernir rápidamente qué directorios contenidos en el directorio "/" contribuyen a la capacidad del sistema de archivos "/" porque todos los demás sistemas de archivos se encuentran bajo la raíz.
Esto excluirá todos los sistemas de archivos que no sean / cuando se ejecute du en Solaris 10 o Red Hat el5 básicamente eliminando un df egrepped de una segunda exclusión de subcapa de expresiones regulares de egrep delimitada por tuberías que, naturalmente, se excluye aún más mediante un tercer egrep a lo que me gustaría referirme. conocida como "la ballena". El festival de munge se intensifica frenéticamente hasta convertirse en algunos xargs du reciclaje donde du -x/-d es realmente útil (ver comentarios inferiores), y un egrep final gratuito escupe una lista de directorios relevantes y de alta capacidad que están contenidos exclusivamente en el "/" sistema de archivos, pero no dentro de otros sistemas de archivos montados. Es muy descuidado.
Ejemplo de plataforma Linux: xargs du -shx
contraseña = /
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"
Esto se ejecuta en estos sistemas de archivos:
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 es el 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.
================================================
Ejemplo de plataforma Solaris: xargs du -shd
contraseña = /
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"
Esto se ejecuta en estos sistemas de archivos:
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 es el 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
===============
¿Cómo se podrían abordar de manera más efectiva los problemas completos del sistema de archivos "/", también conocido como "raíz", en múltiples plataformas que tienen una cantidad devastadora de montajes?
En Red Hat el5, du -x aparentemente evita el cruce a otros sistemas de archivos. Si bien esto puede ser así, no parece hacer nada si se ejecuta desde el directorio /.
En Solaris 10, la bandera equivalente es du -d, lo que aparentemente no trae sorpresas.
(Espero haberlo estado haciendo mal).
¿Adivina qué? Es muy lento.
Respuesta1
Tu problema, según tengo entendido, es quedu está descendiendo a otros sistemas de archivos (algunos de los cuales son montajes de red o SAN, y tardan mucho en contar su utilización).
Respetuosamente lo presento si está intentando monitorear la utilización del sistema de archivosdu es elequivocadoherramienta para el trabajo. que quieras df(que aparentemente conoces ya que incluiste su resultado).
Analizar el resultado dfpuede ayudarle a apuntar a sistemas de archivos específicos en los que debería ejecutar dupara determinar qué directorios están consumiendo todo su espacio (o si tiene suerte, el sistema de archivos completo tiene una parte responsable específica a quien puede decirle que lo resuelva). ellos mismos). En cualquier caso, al menos sabrá que un sistema de archivos se está llenando antes de que esté lleno (y la salida es más fácil de analizar).
En resumen: correrdf primero ejecuta, luegosi usted tiene queejecútelo duen cualquier sistema de archivos dfidentificado con una utilización superior (digamos) al 85% para obtener detalles más específicos.
Pasando a tu script, la razón dupor la que no se respeta tu -d(o -x) bandera es por la pregunta que estás haciendo:
# pwd
/
# du * (. . .etc. . .)
Estás solicitando duejecutar todo lo que aparece debajo /, du -x /bin /home /sbin /usr /tmp /varetc., y duluego estás haciendo exactamente lo que pediste (dándote el uso de cada una de esas cosas. Si uno de los argumentos resulta ser una raíz del sistema de archivosdu se supone que sabes lo que estás hacer y dar el uso deesosistema de archivos hasta el primer submontaje que encuentre.
Esto escríticamentediferente de du -x /("Cuéntame /e ignora cualquier submontaje").
Para arreglar tu script*no cden el directorio que está analizando; en su lugar, simplemente ejecute
du /path/to/full/disk | [whatever you want to feed the output through]
Esto (o cualquier otra sugerencia que pueda recibir) no resuelve sus dos problemas principales:
Su sistema de seguimiento es ad-hoc
Si quieres detectar problemas antes de que te piquen en los genitales,en realidadnecesidad de desplegar unplataforma de seguimiento decente. Si tiene problemas para lograr que su equipo de administración acepte esto, recuérdeles que un monitoreo adecuado le permite evitar el tiempo de inactividad.Tu entorno (como bien habrás supuesto) es un desastre
No hay mucho que hacer aquí excepto reconstruir la cosa - Essutrabajo como SA para levantarse y presentar un caso de negocios muy claro y muy RUIDOSO de por qué los sistemas deben ser desmantelados uno a la vez y reconstruidos con una estructura que pueda administrarse.
Parece que tiene un manejo bastante decente de lo que se debe hacer, pero si tiene preguntas, hágalas y trataremos de ayudarlo tanto como podamos (no podemos hacer su arquitectura por usted, pero Puede responder preguntas conceptuales o prácticas de tipo "¿Cómo hago Xcon la herramienta de monitoreo Y?"
Respuesta2
Respuesta simple: instale una herramienta de monitoreo de infraestructura (como ZenOSS, Zabixx, etc.).
Si está buscando algo personalizado, ¿quizás necesite algún tipo de capa de abstracción para manejar diferencias extrañas por máquina en lugar de administrarlas manualmente cada vez?
Respuesta3
Hago esta recomendación a menudo. La herramienta que recomiendo para los cálculos de uso de disco ad-hoc es lautilidad ncdu. Hay una --excludebandera que se puede especificar varias veces.
Hay versiones empaquetadas paraSolaris(CSWncdu), o puedes compilarlo desde el código fuente. Simplifica mucho de lo que estás haciendo.
Respuesta4
Creo que lo que buscas es algo comoncdu. Eso le permitirá dejar de recorrer directorios y al mismo tiempo podrá encontrar dónde se está consumiendo el disco.
Me haré eco de las otras respuestas diciendo que esta es la herramienta que utilizasdespuéssus sistemas de monitoreo han detectado un problema; no es el tipo de herramienta que le gustaría utilizar de forma no interactiva. De hecho, debido a que se basa en maldiciones, hacerlo sería una trampa. Cualquier administrador de sistemas que se precie le permitirá descargar una herramienta sencilla y examinada para evitar monstruosidades bash hambrientas de recursos y pirateadas como la que ha descrito. Utilizará mucha más memoria, muchas más E/S y será mucho más peligroso que ese software "prohibido".