оптимизировать отчеты du для набора петабайтных данных?
231
Jules Kerssemakers
Я пытаюсь получить ежедневный отчет о размере файла из нескольких петабайт данных геномики. Наш текущий отчет использует несколько перекрывающихся duвызовов для достижения результата, но для его выполнения требуется более 24 часов. Я ищу способ сделать это более эффективно / быстро / "чисто".
В настоящее время мы делаем:
# broad overview of dozens of projects + grand total du -chd1 /petastorage/projects/ # detailed look at some 'special' projects, # each of these has huge sub-dirs we want to track individually du -hd1 /petastorage/projects/special_project_A/ du -hd1 /petastorage/projects/special_project_B/ du -hd1 /petastorage/projects/special_project_C/
Что меня беспокоит, так это то, что special_project_[ABC]сканируются дважды, один раз в общем обзоре, один раз для подробного просмотра. Поскольку на эти специальные проекты приходится большой объем данных, их обход в два раза, вероятно, (предупреждение: предположение) является важной частью времени выполнения. Кроме того, поскольку мы говорим о петабайтах, я не верю, что какой-либо уровень кэширования файловой системы ускорит повторные вызовы.
Я пытался «оптимизировать», du -d1 /petastorage/projects/ /petastorage/projects/special_project_[ABC]/ но, похоже, duдостаточно умен, чтобы понять, что специальные проекты являются дочерними каталогами первого каталога, и поэтому он «оптимизирует» их из отчетов. Г!
Кто-нибудь знает, как я могу убедить duсканировать свои петабайты только один раз, выводя как все проекты по отдельности, так и подробное представление (на один уровень глубже) трех «специальных проектов»
примечание: текущий вывод du уже пропущен через какую-то трубу sort / uniq, чтобы он отображался лучше и без дубликатов в отчете по электронной почте, поэтому приемлемы решения, связанные с постобработкой. Любая длительность постобработки равна нулю по сравнению с составлением петабайт вращающейся ржавчины.
Предыстория на случай, если это имеет значение: это монтирование NFSv3 к узлам хранения EMC-isilon, смонтированным в OpenSuse 11.4. Все проекты в настоящее время совместно используют один пул хранения на isilons, поэтому свободное пространство можно распределять между проектами. Перемещение «специальных» проектов в их собственные файловые системы, чтобы мы могли «обманывать», dfневозможно из-за их размера.
2 ответа на вопрос
0
Jules Kerssemakers
Потратив (объединенный) день или два на эту проблему, мы решили пойти легким путем, а не оптимизировать сейчас. В конце концов, время разработки обходится дороже, чем время выполнения скрипта.
Если / когда я вернусь к этой проблеме, я, вероятно, сделаю один duпрогон для подпроектов, второй duпрогон для больших папок (с --excludeвключенными проектами, охватываемыми первым), и вручную вычислю общий итог вместе в посте. -переработкой (judidicious использование awk, sedили grep | paste -sd'+' | bcдолжно хватить)
Если у кого-то есть идеи получше, я буду рад их услышать :-)
0
Jules Kerssemakers
Чтобы отчитаться, мы с тех пор пошли по «неиссякаемому» маршруту в рамках более масштабной реорганизации нашего хранилища.
Наши новые файловые серверы поддерживают квоту на подмонтирование, поэтому со временем мы извлекали проекты в субмонтирования вместо «обычных» папок в большой общей файловой системе / монтировании. Это был задний ход проекта миграции в течение нескольких недель / месяцев. Это позволило нам установить квоту на все нужные «папки».
Теперь мы запрашиваем статус квоты (который управляется в реальном времени и мгновенно файловыми серверами)