Bearbeiten 20.09.2012
Ich habe das vorher viel zu kompliziert gemacht. Ich glaube, dass diese Befehle eigentlich der einfachere Weg sind und trotzdem alles schön formatieren.
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
Bearbeiten: Der Befehl wurde aktualisiert, um du -x oder du -d unter RHEL5 bzw. Solaris 10 richtig zu nutzen.
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'
Dadurch werden Verzeichnisse über 50 MB innerhalb des "/"-Dateisystems in aufsteigender, reursiver, für Menschen lesbarer Reihenfolge und in angemessen kurzer Zeit zurückgegeben.
Bitte: Können Sie helfen, diesen Einzeiler effektiver, schneller oder effizienter zu machen? Wie wäre es mit eleganter? Wenn Sie verstehen, was ich da gemacht habe, lesen Sie bitte weiter.
Das Problem besteht darin, dass es schwierig sein kann, schnell zu erkennen, welche Verzeichnisse im Verzeichnis "/" zur Kapazität des Dateisystems "/" beitragen, da alle anderen Dateisysteme unter das Stammverzeichnis fallen.
Dadurch werden alle Dateisysteme außer / ausgeschlossen, wenn du unter Solaris 10 oder Red Hat el5 ausgeführt wird, indem im Grunde ein egrepped df aus einem zweiten durch Pipes getrennten egrep-Regex-Subshell-Ausschluss manipuliert wird, der natürlich durch einen dritten egrep in dem, was ich als „den Wal“ bezeichnen möchte, weiter ausgeschlossen wird. Das Mange-Fest eskaliert hektisch zu einigen xargs du-Recycling, wo du -x/-d tatsächlich nützlich ist (siehe Kommentare unten), und ein abschließender, unnötiger egrep spuckt eine Liste relevanter Verzeichnisse mit hoher Kapazität aus, die ausschließlich im „/“-Dateisystem enthalten sind, aber nicht in anderen gemounteten Dateisystemen. Es ist sehr schlampig.
Beispiel für die Linux-Plattform: 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"
Dies läuft auf diesen Dateisystemen:
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
Dies ist das Ergebnis:
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.
=============================================
Beispiel für die Solaris-Plattform: 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"
Dies läuft auf diesen Dateisystemen:
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
Dies ist das Ergebnis:
Solaris:
63M etc
490M bb
570M root/cores.ric.20100415
1.7G oec/archive
1.1G root/packages
2.2G root
1.7G oec
==============
Wie könnte man das Problem des vollen "/"-Dateisystems bzw. des "Root"-Dateisystems auf mehreren Plattformen mit einer erschreckenden Anzahl von Mounts effektiver lösen?
Unter Red Hat el5 vermeidet du -x anscheinend den Durchlauf in andere Dateisysteme. Das mag zwar so sein, aber es scheint nichts zu bewirken, wenn es aus dem /-Verzeichnis ausgeführt wird.
Unter Solaris 10 lautet das entsprechende Flag „du -d“, das anscheinend keine Überraschungen bereithält.
(Ich hoffe, ich habe es einfach falsch gemacht.)
Und wissen Sie was? Es ist wirklich langsam.
Antwort1
Ihr Problem besteht, so wie ich es verstehe, darin, dass es duin andere Dateisysteme abdriftet (einige davon sind Netzwerk- oder SAN-Mounts, und das Zählen der Auslastung dauert lange).
Ich möchte respektvoll anmerken, dass, wenn Sie versuchen, die Dateisystemauslastung zu überwachen du, diefalschWerkzeug für die gewünschte Aufgabe df(Sie wissen es offensichtlich, da Sie die Ausgabe mit aufgenommen haben).
Durch das Parsen der Ausgabe dfkönnen Sie bestimmte Dateisysteme anvisieren, in denen Sie arbeiten sollten, duum zu ermitteln, welche Verzeichnisse Ihren gesamten Speicherplatz beanspruchen (oder wenn Sie Glück haben, gibt es für das gesamte Dateisystem eine bestimmte verantwortliche Partei, die Sie anweisen können, dies selbst herauszufinden). In beiden Fällen wissen Sie zumindest, dass ein Dateisystem voll wird, bevor es voll ist (und die Ausgabe ist einfacher zu parsen).
Kurz gesagt: dfErst laufen, dannwenn du musstFühren Sie es duauf jedem Dateisystem aus df, bei dem eine Auslastung von über (sagen wir) 85 % festgestellt wurde, um genauere Details zu erhalten.
Wenn wir uns Ihr Skript ansehen, liegt der Grund dafür du, dass Ihr -d(oder -x)-Flag nicht beachtet wird, in der Frage, die Sie stellen:
# pwd
/
# du * (. . .etc. . .)
Sie fordern, alles unter -- usw. duauszuführen , und tun dann genau das, was Sie gefragt haben (und geben Ihnen die Verwendung jedes dieser Dinge an). Wenn eines der Argumente zufällig ein Dateisystem-Root ist, wird davon ausgegangen, dass Sie wissen, was Sie tun, und die Verwendung von/du -x /bin /home /sbin /usr /tmp /varduduDasDateisystem bis zum ersten gefundenen Submount.
Das istkritischunterscheidet sich von du -x /(„Informieren Sie mich über /etwaige Untermounts und ignorieren Sie diese“).
So reparieren Sie Ihr Skript*nicht cdin das Verzeichnis, das Sie analysieren -- führen Sie stattdessen einfach
du /path/to/full/disk | [whatever you want to feed the output through]
Dies (oder jeder andere Vorschlag, den Sie erhalten) löst Ihre beiden Kernprobleme nicht:
Ihr Überwachungssystem ist ad hoc
Wenn Sie Probleme erkennen möchten, bevor sie Sie in die Genitalien beißen,Wirklichmüssen Sie einenanständige Überwachungsplattform. Wenn Sie Schwierigkeiten haben, Ihr Managementteam davon zu überzeugen, erinnern Sie es daran, dass Sie Ausfallzeiten durch eine ordnungsgemäße Überwachung vermeiden können.Ihre Umgebung (wie Sie richtig vermutet haben) ist ein Chaos
Hier gibt es nicht viel zu tun, außer das Ding wieder aufzubauen - Es istdeinMeine Aufgabe als SA besteht darin, aufzustehen und sehr deutlich und lautstark darzulegen, warum die Systeme nach und nach abgebaut und mit einer verwaltbaren Struktur neu aufgebaut werden müssen.
Sie scheinen ganz gut zu wissen, was zu tun ist, aber wenn Sie Fragen haben, stellen Sie diese auf jeden Fall und wir werden versuchen, Ihnen so gut zu helfen, wie wir können (wir können Ihre Architektur nicht für Sie erstellen, aber wir können konzeptionelle Fragen oder praktische Dinge wie „Wie gehe ich Xmit dem Überwachungstool um Y?“ beantworten …
Antwort2
Einfache Antwort: Installieren Sie ein Tool zur Infrastrukturüberwachung (z. B. ZenOSS, Zabixx usw.).
Wenn Sie nach etwas Benutzerdefiniertem suchen, benötigen Sie vielleicht eine Art Abstraktionsschicht, um seltsame Unterschiede zwischen den Maschinen zu verarbeiten, anstatt dies jedes Mal manuell zu verwalten?
Antwort3
Ich gebe diese Empfehlung oft ab. Das Tool, das ich für Ad-hoc-Berechnungen der Festplattennutzung empfehle, ist dasncdu-Dienstprogramm. Es gibt ein --excludeFlag, das mehrfach angegeben werden kann.
Es gibt verpackte Versionen fürSolaris(CSWncdu), oder Sie können es aus dem Quellcode kompilieren. Das vereinfacht vieles von dem, was Sie tun.
Antwort4
Ich glaube, was Sie suchen, ist so etwas wiencdu. Dadurch können Sie das Navigieren in Verzeichnissen verhindern und dennoch feststellen, wo die Festplatte belegt ist.
Ich schließe mich den anderen Antworten an und sage, dass dies das Werkzeug ist, das Sie verwendennachIhre Überwachungssysteme haben ein Problem erkannt – es ist nicht die Art von Tool, die Sie nicht interaktiv verwenden möchten. Da es auf Ncurses basiert, wäre dies tatsächlich ein Plackerei. Jeder Systemadministrator, der etwas auf sich hält, wird Ihnen erlauben, ein geprüftes und einfaches Tool herunterzuladen, um ressourcenhungrige, zusammengehackte Bash-Monstrositäten wie die von Ihnen beschriebene zu verhindern. Es wird viel mehr Speicher und viel mehr I/O verbrauchen und viel gefährlicher sein als diese „verbotene“ Software.