Мы создаем продукт, который может генерировать очень большие тома XFS, и я пытаюсь обнаружить узкие места масштабирования, с которыми мы, вероятно, столкнемся при данной архитектуре.
Когда мы манипулируем файлами, они помещаются в каталоги на томах XFS. Из-за количества файлов, которые мы обрабатываем, количество файлов определенно исчисляется десятками миллионов и, вероятно, достигнет сотен миллионов вскоре после выпуска. Мы знаем это, потому что наш текущий продукт ведет себя таким же образом, поэтому разумно ожидать, что наш следующий будет вести себя так же.
Следовательно, правильная ранняя инженерия в порядке.
На этой неделе файлы основаны на следующем приблизительном макете:
$ProjectID/$SubProjectID/[md5sum chunked into groups of 4]/file
Это дает каталоги, которые выглядят примерно так:
0123456/001/0e15/a644/8972/19ac/b4b5/97f6/51d6/9a4d/file
Причина разбиения md5sum на части состоит в том, чтобы избежать проблемы «большой кучи файлов / каталогов в одном каталоге». Из-за разбиения md5sum на части это означает, что 1 файл вызывает создание 8 каталогов. Это имеет довольно явное влияние на индексные дескрипторы, но я не понимаю, какими будут последствия для XFS, когда мы перейдем к масштабированию.
Какие воздействия?
Кстати, это с ядром 2.6.32, на данный момент CentOS 6.2 (при необходимости это можно изменить).
Во время тестирования я создал том xfs со значениями по умолчанию и не использую никаких параметров монтирования. Это для того, чтобы раньше выкурить проблемы. noatime это что-то очевидное, поскольку оно нам не нужно. Общая настройка XFS - еще одна проблема, которую мне нужно решить, но сейчас меня беспокоит эффект умножения метаданных, который мы разработали прямо сейчас.
Я уже знаю, какое решение будет лучше, я просто не знаю, есть ли у меня доводы, чтобы настаивать на изменении.
Поскольку md5sums существенно уникальны по первым цифрам, а отдельные подпроекты редко превышают 5 миллионов файлов, мне кажется, что нам нужны только первые два фрагмента. Что даст такие макеты:
0123456/001/0e15/a644/897219acb4b597f651d69a4d/file
Полностью полный первый и второй уровень будет иметь 216 каталоги первого уровня и 216 каталоги второго уровня в каждом каталоге первого уровня, всего 232 справочники на том.
Гипотетический подпроект с 5 миллионами файлов, следовательно, будет иметь 216 каталоги первого уровня, примерно 76 (+/- 2) каталогов второго уровня в каждом и один или два каталога третьего уровня в каждом каталоге второго уровня.
Этот макет намного более эффективен для метаданных. Я просто не знаю, стоит ли прилагать усилия, чтобы изменить то, как сейчас идут дела.
Никаких серьезных рекомендаций, кроме XFS должен масштабироваться до этого. Я начал использовать файловую систему в 2003 году, потому что мне нужно было работать с приложением, которое могло легко иметь 800 000 файлов в одном каталоге. ext2 и ext3 обычно не работают в этих файловых системах.
Во многом это зависит от вашего приложения и от того, как оно обращается к файлам (обход каталога и т. Д.).
Если это все на одном сервере, я бы посмотрел на внешние журналы SSD, исходя из ваших ожиданий большого количества операций с метаданными. Но вы знаете эту часть. Я бы все равно настаивал на реструктуризации, используя второй пример md5. Я имею в виду это является хорошее время для рефакторинга, не так ли?