Редактировать 20.09.2012

Редактировать 20.09.2012

Редактировать 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]


Это (или любое другое предложение, которое вы можете получить) не решит ваши две основные проблемы:

  1. Ваша система мониторинга является специальной
    Если вы хотите обнаружить проблемы до того, как они укусят вас за гениталии, вамДействительнонеобходимо развернутьдостойная платформа мониторинга. Если у вас возникли проблемы с тем, чтобы убедить свою команду менеджеров в необходимости этого, напомните им, что правильный мониторинг позволяет избежать простоев.

  2. Ваше окружение (как вы правильно предположили) находится в беспорядке
    Здесь не так уж много дел, кроме как перестроить эту штуку.твойзадача как генерального прокурора — встать и очень четко, очень ГРОМКО обосновать, почему системы необходимо демонтировать по одной и перестроить с использованием структуры, которой можно управлять.

Похоже, вы довольно неплохо разбираетесь в том, что нужно сделать, но если у вас есть вопросы, обязательно задавайте их, и мы постараемся помочь, чем сможем (мы не можем сделать вашу архитектуру за вас, но можем ответить на концептуальные вопросы или практические вопросы типа «Как мне работать Xс инструментом мониторинга Y?»).

решение2

Простой ответ: установите инструмент мониторинга инфраструктуры (например, ZenOSS, Zabixx и т. д.).

Если вы ищете что-то индивидуальное, возможно, вам нужен какой-то уровень абстракции для обработки странных различий между машинами, а не делать это каждый раз вручную?

решение3

Я часто даю эту рекомендацию. Инструмент, который я пропагандирую для специальных расчетов использования диска, этоутилита ncdu. Существует --excludeфлаг, который можно указать несколько раз.

Существуют упакованные версии дляСолярис(CSWncdu), или вы можете скомпилировать его из исходников. Это упрощает многое из того, что вы делаете.

решение4

Я думаю, что вы ищете что-то вроденкду. Это позволит вам избежать перемещения по каталогам, но при этом иметь возможность определить, где используется диск.

Я повторю другие ответы, сказав, что это инструмент, который вы используетепослеВаши системы мониторинга обнаружили проблему — это не тот инструмент, который вы хотели бы использовать неинтерактивно. Фактически, поскольку он основан на ncurses, делать это было бы муторно. Любой системный администратор, который стоит своих денег, позволит вам загрузить проверенный и простой инструмент для предотвращения ресурсоемких, хакнутых вместе чудовищ bash, подобных тому, что вы описали. Он будет использовать гораздо больше памяти, гораздо больше ввода-вывода и будет гораздо опаснее, чем это «запрещенное» ПО.

Связанный контент