Кроссплатформенный, читаемый человеком, корневой раздел, который действительно игнорирует другие файловые системы
Изменить 20.09.2012
Я сделал этот путь слишком сложным раньше. Я полагаю, что эти команды на самом деле проще, но при этом все красиво форматируют.
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
Редактировать: команда была обновлена для правильного использования du -x или du -d на RHEL5 или Solaris 10 соответственно.
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'
Это вернет каталоги размером более 50 Мб в файловой системе "/" в восходящем, рекурсивном, удобочитаемом формате и за достаточно короткий промежуток времени.
Запрос: Можете ли вы помочь сделать этот однострочник более эффективным, быстрым или эффективным? Как насчет более элегантного? Если вы понимаете, что я там делал, тогда, пожалуйста, продолжайте читать.
Проблема заключается в том, что может быть трудно быстро определить, какие каталоги, содержащиеся в каталоге "/", способствуют увеличению емкости файловой системы "/", поскольку все остальные файловые системы попадают под root.
Это исключит все не / файловые системы при запуске du на Solaris 10 или Red Hat el5, в основном, путём преобразования egrepped df из второго исключения subhell для регулярных выражений egrep с разделителями в виде трубы, которое, естественно, далее исключается третьим egrep в том, что я хотел бы сослаться как "кит". Munge-fest неистово перерастает в некоторые xargs du recycling, где du -x/-d действительно полезен (см. Нижние комментарии), и окончательный, бесплатный egrep выкладывает список соответствующих каталогов высокой емкости, которые содержатся исключительно в Файловая система "/", но не в других смонтированных файловых системах. Это очень небрежно.
Пример платформы 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"
Это работает против этих файловых систем:
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.
=============================================
Пример платформы 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"
Это работает против этих файловых систем:
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
Это результат:
Solaris:
63M etc
490M bb
570M root/cores.ric.20100415
1.7G oec/archive
1.1G root/packages
2.2G root
1.7G oec
==============
Как можно более эффективно справляться с проблемами "/" aka "root" файловой системы на нескольких платформах, которые имеют разрушительное количество монтирований?
В Red Hat el5 du -x, по-видимому, избегает обхода других файловых систем. Хотя это может быть и так, он, похоже, ничего не делает, если запускается из каталога /.
На Solaris 10 эквивалентным флагом является du -d, который, очевидно, не преподносит сюрпризов.
(Я надеюсь, что я просто делал это неправильно.)
Угадай, что? Это действительно медленно.
4 ответа
Ваша проблема, насколько я понимаю, в том, что 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. Есть --exclude флаг, который может быть указан несколько раз.
Существуют упакованные версии для Solaris (CSWncdu), или вы можете скомпилировать их из исходного кода. Это упрощает многое из того, что вы делаете.
Я думаю, что вы ищете что-то вроде ncdu. Это позволит вам не переходить в каталоги, и в то же время будет иметь возможность определить, где используется диск.
Я повторю другие ответы, сказав, что это инструмент, который вы используете после того, как ваши системы мониторинга обнаружили проблему - это не тот инструмент, который вы хотели бы использовать неинтерактивно. На самом деле, потому что это основано на ncurses, это будет просто клочком. Любой системный администратор, достойный всяческих усилий, позволит вам загрузить проверенный и простой инструмент для предотвращения жадных до ресурсов взломанных монстров, как вы описали. Он будет использовать гораздо больше памяти, гораздо больше операций ввода-вывода и будет гораздо более опасным, чем это "запрещенное" программное обеспечение.