
Редактировать 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'
Солярис
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 regex subshell, разделенного конвейером, которое естественным образом дополнительно исключается третьим egrep в том, что я хотел бы назвать "китом". Праздник munge-fest неистово перерастает в некоторую переработку xargs du, где du -x/-d на самом деле полезен (см. комментарии внизу), и последний, беспричинный egrep выдает список соответствующих каталогов большой емкости, которые содержатся исключительно в файловой системе "/", но не в других смонтированных файловых системах. Это очень неряшливо.
Пример для платформы Linux: xargs du -shx
пароль = /
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
Вот результат:
Линукс:
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
пароль = /
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, что, по-видимому, не таит в себе никаких сюрпризов.
(Надеюсь, я просто делаю это неправильно.)
Угадайте что? Это очень медленно.
решение1
Насколько я понимаю, ваша проблема заключается в том, что она 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]
Это (или любое другое предложение, которое вы можете получить) не решит ваши две основные проблемы:
Ваша система мониторинга является специальной
Если вы хотите обнаружить проблемы до того, как они укусят вас за гениталии, вамДействительнонеобходимо развернутьдостойная платформа мониторинга. Если у вас возникли проблемы с тем, чтобы убедить свою команду менеджеров в необходимости этого, напомните им, что правильный мониторинг позволяет избежать простоев.Ваше окружение (как вы правильно предположили) находится в беспорядке
Здесь не так уж много дел, кроме как перестроить эту штуку.твойзадача как генерального прокурора — встать и очень четко, очень ГРОМКО обосновать, почему системы необходимо демонтировать по одной и перестроить с использованием структуры, которой можно управлять.
Похоже, вы довольно неплохо разбираетесь в том, что нужно сделать, но если у вас есть вопросы, обязательно задавайте их, и мы постараемся помочь, чем сможем (мы не можем сделать вашу архитектуру за вас, но можем ответить на концептуальные вопросы или практические вопросы типа «Как мне работать X
с инструментом мониторинга Y
?»).
решение2
Простой ответ: установите инструмент мониторинга инфраструктуры (например, ZenOSS, Zabixx и т. д.).
Если вы ищете что-то индивидуальное, возможно, вам нужен какой-то уровень абстракции для обработки странных различий между машинами, а не делать это каждый раз вручную?
решение3
Я часто даю эту рекомендацию. Инструмент, который я пропагандирую для специальных расчетов использования диска, этоутилита ncdu. Существует --exclude
флаг, который можно указать несколько раз.
Существуют упакованные версии дляСолярис(CSWncdu), или вы можете скомпилировать его из исходников. Это упрощает многое из того, что вы делаете.
решение4
Я думаю, что вы ищете что-то вроденкду. Это позволит вам избежать перемещения по каталогам, но при этом иметь возможность определить, где используется диск.
Я повторю другие ответы, сказав, что это инструмент, который вы используетепослеВаши системы мониторинга обнаружили проблему — это не тот инструмент, который вы хотели бы использовать неинтерактивно. Фактически, поскольку он основан на ncurses, делать это было бы муторно. Любой системный администратор, который стоит своих денег, позволит вам загрузить проверенный и простой инструмент для предотвращения ресурсоемких, хакнутых вместе чудовищ bash, подобных тому, что вы описали. Он будет использовать гораздо больше памяти, гораздо больше ввода-вывода и будет гораздо опаснее, чем это «запрещенное» ПО.