Как кэшироваться или иначе ускорить 'du' сводки?

Только ради наличия множества опций, представленных на этой странице, Вот еще два пути:

1: октава

  • Октава GNU является высокоуровневым интерпретируемым языком, прежде всего, предназначенным для числовых вычислений. Это обеспечивает возможности числового решения линейных и нелинейных проблем, и для выполнения других числовых экспериментов.

Вот быстрый пример октавы.

octave -q --eval 'A=1:10;
  printf ("# %f\t%f\t%f\t%f\n", min(A), max(A), median(A), mean(A));'  
# 1.000000        10.000000       5.500000        5.500000

2: колотите + специализированные инструменты.

Чтобы удар обработал числа с плавающей запятой, этот сценарий использование numprocess и numaverage от пакета num-utils.

PS. У меня также был разумный взгляд на bc, но для этого конкретного задания, это ничего не предлагает вне какой awk делает. Это - (как 'c' в 'до н.э' состояниях) калькулятор — калькулятор, который требует большого программирования как awk и этот сценарий удара...


arr=($(sort -n "LIST" |tee >(numaverage 2>/dev/null >stats.avg) ))
cnt=${#arr[@]}; ((cnt==0)) && { echo -e "0\t0\t0\t0\t0"; exit; }
mid=$((cnt/2)); 
if [[ ${cnt#${cnt%?}} == [02468] ]] 
   then med=$( echo -n "${arr[mid-1]}" |numprocess /+${arr[mid]},%2/ )
   else med=${arr[mid]}; 
fi     #  count   min       max           median        average
echo -ne "$cnt\t${arr[0]}\t${arr[cnt-1]}\t$med\t"; cat stats.avg 

33
02.03.2011, 19:35
8 ответов

Что Вы видите, когда Вы повторно выполняетесь, команда du является эффектом дисковой буферизации. После того как Вы читаете блок, которым его дисковый буфер сохранен в кэш-буфере, пока тот блок не необходим. Для du необходимо прочитать каталог и inode для каждого файла в каталоге. Результаты du не кэшируются в этом случае, но могут быть получены с намного меньшим количеством диска IO.

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

Сам каталог понятия не имеет, насколько большой файл, таким образом, к inode каждого файла нужно получить доступ. Для хранения кэшируемого значения актуальным каждый раз, когда файл изменил размер, кэшируемое значение должно будет быть обновлено. Поскольку файл может быть перечислен в 0 или больше каталогах, которые это потребовало бы, чтобы inode каждого файла знал, в каких каталогах он перечислен. Это значительно усложнило бы inode структуру и уменьшило бы производительность IO. Также, поскольку du позволяет Вам получать результаты, принимающие различные размеры блока, данные, требуемые в кэше, должны были бы увеличить или постепенно уменьшить кэшируемое значение для каждого возможного размера блока, далее замедляющего производительность.

21
27.01.2020, 19:37

Если можно принять меры, чтобы различные иерархии файлов принадлежали различным группам, можно настроить выделенные дисковые пространства. Не давайте верхний предел (или делайте его размером диска), если Вы не хотите тот. Вы все еще сможете сказать немедленно, сколько из (эффективно бесконечный) квота использует группа.

Это действительно требует, чтобы Ваша файловая система поддерживала квоты на группу. Расширение Linux [234] и Солярис / zfs *BSD/Linux делает. Было бы хорошо для Вашего варианта использования, если бы квоты группы приняли ACLs во внимание, но я не думаю, что они делают.

7
27.01.2020, 19:37

Я предпочитаю использовать agedu

Agedu является частью программного обеспечения, которое пытается найти старые и нерегулярно используемые файлы на предположении, что эти файлы наиболее вероятны не требоваться. (например, Загрузки, которые были только просмотрены однажды.)

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

7
27.01.2020, 19:37
  • 1
    Не отвечает на вопрос, но все еще +1. Хорошая подсказка. –  0xC0000022L 07.05.2011, 02:15

У меня есть cronjob, настроенный для выполнения updatedb каждые 10 минут. Сохраняет все буферы файловой системы хорошими и новыми. Мог бы также использовать ту дешевую RAM для чего-то хорошего. Используйте slabtop, см. 'прежде' и 'после'.

2
27.01.2020, 19:37
  • 1
    , который я не понимаю, как Ваш ответ касается вопроса. updatedb не говорит ничто об использовании диска. При выполнении его только для пересечения диска, Вы собираетесь повредить общую производительность. вздох –  Gilles 'SO- stop being evil' 06.05.2011, 00:54
  • 2
    Подсчет размеров файла для du является медленным, потому что необходимо получить доступ к метаданным потенциально большого количества файлов, рассеянных вокруг диска. При выполнении updatedb настойчиво метаданные для всех файлов вынуждены быть сохраненными в RAM. В следующий раз Вы выполняете любую другую тяжелую метаданными операцию, вместо того, чтобы делать тысячи ищет через диски, Вы используете кэш. Обычно у Вас есть маленький шанс наличия что конкретная часть кэшируемых метаданных дерева. С моим 'воспламенением кэша метаданных' очень вероятно, что данные, которые Вы хотите, недавно кэшируются. Никакой медосмотр не ищет == FAST. –  Marcin 06.05.2011, 13:33

Как упомянуто SHW, agedu действительно созданный индекс. Я думал, что совместно использую другой способ создать индекс после чтения о locatedb. Можно создать собственную версию a locatedb от du вывод:

du | awk '{print $2,$1}' | /usr/lib/locate/frcode > du.locatedb

awk перестраивает вывод du, чтобы иметь имена файлов сначала, так, чтобы frcode работает правильно. Затем используйте locate с этой базой данных для быстрого создания отчетов об использовании диска:

locate --database=du.locatedb pingus

Можно развернуть это для удовлетворения потребностям. Я думаю, что это - хорошее использование locatedb.

5
27.01.2020, 19:37

Если вам нужно знать только размер каталога, вы можете значительно ускорить процесс, просто не записывая информацию на экран. Поскольку общий итог является последней строкой команды du, вы можете просто передать его в tail.

du -hc | tail -n 1

Структура каталогов размером 2 ГБ занимает более секунды для полного списка, но менее 5-й части этого времени при использовании данной формы.

2
27.01.2020, 19:37

Обычное использование du можно значительно ускорить, используя ncdu.

ncdu - NCurses Disk Usage

выполняет du, кэширует результаты и показывает их в удобном интерфейсе командной строки, несколько сравнимом с du -hc -d 1 | sort -h. Начальная индексация занимает столько же времени, сколько и du, но поиск фактического "виновника", заполняющего драгоценное пространство, ускоряется, поскольку все подкаталоги имеют изначально кэшированную информацию du.

При необходимости подкаталоги можно обновить, нажав [r], а файлы/папки можно удалить, нажав [d]; при этом обновляется статистика для всех родительских каталогов. При удалении запрашивается подтверждение.

Если необходимо, дальнейшего ускорения можно добиться, предварительно кэшируя ncdu -1xo- / | gzip >export.gz в cronjob и позже обращаясь к нему с помощью zcat export.gz | ncdu -f-, но это, очевидно, дает более устаревшую информацию.

7
27.01.2020, 19:37
duc

(см.https://duc.zevv.nl)может быть тем, что вы ищете.

Duc сохраняет данные об использовании диска в оптимизированной базе данных, что обеспечивает быстрый пользовательский интерфейс. Нет времени ожидания после завершения индекса.

Обновление индекса у меня происходит очень быстро (менее 10 секунд. около 950 тыс. файлов в 121 тыс. каталогов, 2,8 ТБ ). Имеет графический интерфейс и пользовательский интерфейс ncurses.

Использование, например.:

duc index /usr
duc ui /usr

С сайта:

Duc is built to scale to huge filesystems: it will index and display hundreds of millions of files on petabytes of storage without problems.

15
27.01.2020, 19:37

Теги

Похожие вопросы