Миллионы маленьких графических файлов и как преодолеть медленный доступ к файловой системе в XP - PullRequest
Новая
       24

Миллионы маленьких графических файлов и как преодолеть медленный доступ к файловой системе в XP

4 голосов
/ 28 октября 2009

Я рендерил миллионы плиток, которые будут отображаться как наложение на Картах Google. Файлы создаются GMapCreator из Центра расширенного пространственного анализа при Университетском колледже Лондона. Приложение отображает файлы в одну папку за раз, в некоторых случаях мне нужно создать около 4,2 миллиона плиток. Я запускаю его в Windows XP, используя файловую систему NTFS, диск имеет размер 500 ГБ и отформатирован с использованием параметров операционной системы по умолчанию.

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

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

Спасибо

Барри.

Обновление:

Спасибо всем за предложения. Возможное решение заключалось в написании фрагмента кода, который отслеживал выходную папку GMapCreator, перемещая файлы в иерархию каталогов на основе их имен файлов; поэтому файл с именем abcdefg.gif будет перемещен в \ a \ b \ c \ d \ e \ f \ g.gif. Запуск этого в то же время, когда GMapCreator преодолел проблемы с производительностью файловой системы. Намек на генерацию имен файлов DOS 8.3 также был очень полезен - как отмечалось ниже, я был поражен, насколько это изменилось. Приветствия: -)

Ответы [ 5 ]

5 голосов
/ 28 октября 2009

Есть несколько вещей, которые вы могли бы / должны сделать

  • Отключить автоматическую генерацию коротких имен файлов NTFS (Google it)

  • Или ограничьте имена файлов для использования шаблона 8.3 (например, i0000001.jpg, ...)

  • В любом случае попробуйте сделать первые шесть символов имени файла максимально уникальными / разными

  • Если вы снова используете одну и ту же папку и (скажем, добавление файла, удаление файла, чтение файлов, ...)

    • Используйте contig , чтобы индексный файл каталога был как можно менее фрагментированным (проверьте это для объяснения)
    • Особенно при удалении многих файлов рекомендуется использовать трюк удаления папки , чтобы уменьшить размер файла индекса Direcotry

  • Как уже упоминалось, рассмотрите возможность разделения файлов на несколько каталогов.

.e.g. вместо 

directory/abc.jpg
directory/acc.jpg
directory/acd.jpg
directory/adc.jpg
directory/aec.jpg

использование 

directory/b/c/abc.jpg
directory/c/c/acc.jpg
directory/c/d/acd.jpg
directory/d/c/adc.jpg
directory/e/c/aec.jpg
1 голос
/ 28 октября 2009

Используйте больше папок и ограничьте количество записей в любой данной папке. Время перечисления количества записей в каталоге увеличивается (экспоненциально? Я не уверен в этом) с количеством записей, и если у вас есть миллионы маленьких файлов в одном каталоге, даже если вы делаете что-то вроде dir folder_with_millions_of_files может занять минуты. Переключение на другую ФС или ОС не решит проблему --- Linux работает аналогично, когда я проверял последний раз.

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

1 голос
/ 28 октября 2009

Вы можете попробовать SSD ....

http://www.crucial.com/promo/index.aspx?prog=ssd

0 голосов
/ 02 ноября 2009

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

Haystack представляет общее хранилище объектов на основе HTTP, содержащее иглы, которые отображаются на сохраненные непрозрачные объекты. Хранение фотографий в виде иголок в стоге сена устраняет накладные расходы метаданных, объединяя сотни тысяч изображений в одном файле хранилища стога сена. Это уменьшает накладные расходы метаданных и позволяет нам сохранять местоположение каждой иглы в файле хранилища в индексе в памяти. Это позволяет извлекать данные изображения за минимальное количество операций ввода-вывода, устраняя все ненужные издержки метаданных.

0 голосов
/ 28 октября 2009

Решение, скорее всего, ограничит количество файлов в каталоге.

У меня была очень похожая проблема с финансовыми данными, хранящимися в ~ 200 000 плоских файлов. Мы решили это, сохранив файлы в каталогах на основе их имени. например, 

gbp97m.xls

был сохранен в 

g/b/p97m.xls

Это работает нормально, если ваши файлы имеют правильные имена (у нас было много символов для работы). Таким образом, итоговое дерево каталогов и файлов не было оптимальным с точки зрения распределения, но оно работало достаточно хорошо, чтобы сократить каждый каталог до 100 файлов и освободить узкое место на диске.

...