Обход файлов в распределенной файловой системе - PullRequest
1 голос
/ 05 августа 2011

У меня есть файловая система с несколькими сотнями миллионов файлов (несколько петабайт), и я хочу получить почти все, что вернет stat, и сохранить его в какой-то базе данных. Прямо сейчас у нас есть программа MPI, которая подает имена каталогов из центральной очереди и рабочие узлы, которые прерывают NFS (которая может справиться с этим, не слишком стараясь) с помощью вызовов stat. Затем рабочие узлы нажимают на postgres для сохранения результатов.

Хотя это работает, но очень медленно. Один запуск займет более 24 часов в современном кластере с 30 узлами.

Есть ли у кого-нибудь идеи разбить структуру каталогов вместо централизованной очереди (у меня сложилось впечатление, что точные алгоритмы для этого являются NP сложными)? Кроме того, я рассматривал вопрос о замене postgres чем-то вроде автосохранения MongoDB с несколькими маршрутизаторами (поскольку postgres в настоящее время является огромным узким местом).

Я в основном просто ищу идеи о том, как можно улучшить эту настройку.

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

Если это имеет значение, каждая машина (несколько тысяч), использующая эту файловую систему, работает под управлением Linux 2.6.x.

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

Ответы [ 2 ]

1 голос
/ 05 августа 2011

Расширение моих комментариев.

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

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

С другой стороны, запись в базу данных может быть оптимизирована путем изменения вашего механизма БД.Как и предполагалось в комментариях, модель Redis ключ-значение лучше подходит для такой задачи (да, она довольно быстрая ): вы можете использовать ее тип хеша для сохранения результата вызова stat с использованием полного пути в качестве ключа.

Кроме того, redis также будет поддерживать кластеризацию в ближайшем будущем.

0 голосов
/ 12 октября 2011

В итоге мы создали собственное решение для этого (используя redis).Мы сократили время с 24 часов до 2,5 часов.

...