Раньше я делал этот способ слишком сложным. Я считаю, что эти команды на самом деле являются более простым способом, но при этом все хорошо форматируют.
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
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 МБ в файловой системе «/» в восходящем, рекурсивном, удобочитаемом формате и за достаточно короткий промежуток времени.
Просьба: вы можете помочь сделать это однострочное письмо более эффективным, быстрым или эффективным? Как насчет более элегантного? Если вы понимаете, что я там делал, продолжайте читать.
Проблема в том, что бывает трудно быстро определить, какие каталоги, содержащиеся в каталоге «/», способствуют увеличению емкости файловой системы «/», поскольку все остальные файловые системы относятся к корневому каталогу.
Это исключит все файловые системы, отличные от /, при запуске du в Solaris 10 или Red Hat el5, в основном изменяя egrepped df из второго исключения подоболочки регулярного выражения egrep с разделителями, которое, естественно, дополнительно исключается третьим egrep в том, на что я хотел бы сослаться как "кит". Munge-fest лихорадочно перерастает в некий xargs du recycling, где du -x / -d действительно полезен (см. Нижние комментарии), а последний, беспричинный egrep выплевывает список релевантных каталогов высокой емкости, которые содержатся исключительно в каталоге Файловая система "/", но не в других смонтированных файловых системах. Это очень небрежно.
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"
Это работает с этими файловыми системами:
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
Вот результат:
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.
=============================================
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"
Это работает с этими файловыми системами:
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, что явно не преподносит сюрпризов.
(Надеюсь, я просто делал это неправильно.)
Угадай, что? Это очень медленно.
Ваша проблема, насколько я понимаю, в том, что du спускается в другие файловые системы (некоторые из которых монтируются по сети или SAN, и для подсчета их использования требуется много времени).
Я с уважением заявляю, что если вы пытаетесь контролировать использование файловой системы du это неправильно инструмент для работы. Вы хотите df (о чем вы, по-видимому, знаете, так как включили его вывод).
Разбор вывода из df может помочь вам нацелиться на определенные файловые системы, в которых вы должны работать du чтобы определить, какие каталоги занимают все ваше пространство (или, если вам повезет, у полной файловой системы есть конкретная ответственная сторона, которой вы можете сказать, чтобы она сама во всем разобралась). В любом случае, по крайней мере, вы будете знать, что файловая система заполняется до того, как она заполнится (и вывод легче анализировать).
Вкратце: беги df будет первый если тебе нужно бегать du в любой файловой системе df определены как имеющие коэффициент использования (скажем) более 85%, чтобы получить более подробную информацию.
Переходя к вашему сценарию, причина du не уважает ваш -d (или -x) флаг связан с вопросом, который вы задаете:
# pwd
/
# du * (. . .etc. . .)
Вы спрашиваете du бегать по всему под / - du -x /bin /home /sbin /usr /tmp /var и т.д. -- du затем делает именно то, что вы просили (давая вам возможность использовать каждую из этих вещей. Если один из аргументов является корнем файловой системы du предполагает, что вы знаете, что делаете, и используете который файловая система до первого найденного подмонтирования.
Это критически отличный от du -x / ("Расскажи мне про / и игнорируйте любые вспомогательные крепления ").
Чтобы исправить ваш сценарий * не cd в каталог, который вы анализируете - вместо этого просто запустите
du /path/to/full/disk | [whatever you want to feed the output through]
Это (или любое другое предложение, которое вы можете получить) не решает двух ваших основных проблем:
Ваша система мониторинга является специальной
Если вы хотите поймать проблемы до того, как они укусят вас за гениталии, вы действительно необходимо развернуть достойная платформа для мониторинга. Если у вас возникли проблемы с привлечением вашей управленческой команды к этому, напомните им, что надлежащий мониторинг позволяет избежать простоев.
Ваше окружение (как вы правильно догадались) в беспорядке
Здесь особо нечего делать, кроме как перестроить вещь. ваш Работа в качестве SA, чтобы встать и сделать очень ясное, очень ГРОМКО экономическое обоснование того, почему системы необходимо демонтировать по одной и перестраивать с помощью структуры, которой можно управлять.
Вы, кажется, неплохо разбираетесь в том, что нужно сделать, но если у вас есть вопросы, непременно задавайте их, и мы постараемся помочь, насколько это возможно (мы не можем сделать вашу архитектуру за вас, но мы может ответить на концептуальные вопросы или практические вопросы: «Как мне сделать X с инструментом мониторинга Y? "типа вещи ...
Простой ответ: установите инструмент мониторинга инфраструктуры (например, ZenOSS, Zabixx и т. Д.).
Если вы ищете что-то нестандартное, возможно, вам нужен какой-то уровень абстракции для обработки странных различий между машинами, а не для управления этим каждый раз вручную?
Я думаю, что вы ищете что-то вроде ncdu. Это позволит вам перестать перемещаться по каталогам, сохранив при этом возможность определять, где используется диск.
Я повторю другие ответы, сказав, что это инструмент, который вы используете после ваши системы мониторинга обнаружили проблему - это не тот инструмент, который вы бы хотели использовать в неинтерактивном режиме. Фактически, поскольку он основан на ncurses, это было бы путаницей. Любой достойный системный администратор позволит вам загрузить проверенный и простой инструмент для предотвращения ресурсоемких, собранных вместе чудовищ, подобных тому, что вы описали. Он будет использовать гораздо больше памяти, гораздо больше операций ввода-вывода и будет намного опаснее, чем это «запрещенное» программное обеспечение.
Я часто даю эту рекомендацию. Инструмент, который я рекомендую для специальных расчетов использования диска, - это утилита ncdu. Есть --exclude флаг, который можно указывать несколько раз.
Есть упакованные версии для Солярис (CSWncdu), или вы можете скомпилировать его из исходников. Это упрощает многое из того, что вы делаете.