Какая иерархия каталогов будет лучшей / самой быстрой?

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

Что произойдет, если вы будете использовать каталоги меньшего размера с более глубокой иерархией? Чтобы найти запись в каталоге, нужно прочитать меньше данных, но возможно (если запись этого каталога в его родительском элементе больше не кэшируется). Предположим, размер записи каталога составляет 50 байтов. Это 15 КБ для всего каталога с 300 файлами. При последовательном чтении ваш диск, вероятно, доставляет 150+ МБ / с. Таким образом, разница между чтением 300 или 600 файлов составляет 0,1 миллисекунды. Время позиционирования составляет в лучшем случае 4 мс (если это не SSD). Т.е. для каждого сохраненного поиска в каталоге вы можете прочитать записи как минимум 12000 файлов. Это заставляет меня предположить, что ваши каталоги довольно маленькие. Но, возможно, все записи вашего каталога находятся в кеше (я не знаю, как это отслеживать, хотя было бы интересно), поэтому этот расчет не имеет значения. Возможно, это помогает сохранить сценарий в фоновом режиме, который обращается ко всем каталогам каждые несколько секунд, чтобы ни один из них не был выброшен из кеша.

Я предполагаю, что проблема не во времени поиска inode файла. Вероятно, многие процессы пытаются одновременно выполнять ввод-вывод. Если это приводит к тому, что файлы читаются в несколько этапов, производительность, конечно, мертва. То же самое и с фрагментацией файлов. Посмотри на filefrag и ваши файлы кеша. И посмотри на blockdev --setra. Вы должны отрегулировать это в соответствии со средним размером файла (или размером более 90% ваших файлов) и проверить, имеет ли это какое-либо влияние. Я также нашел подсказку (хотя и несколько лет назад) установить это значение на ноль для всех устройств, кроме самого верхнего:

/dev/sdx -> ra=0
/dev/mdx -> ra=0
/dev/lvm/ -> ra=xxxx 

Я не знаю, сколько вы готовы сделать, но я могу представить, что модуль FUSE поможет в вашем случае (в зависимости от размера файла и эффективности упреждающего чтения): этот модуль должен будет убедиться, что файлы читаются в один шаг и чтобы (в пределах пользовательского пространства) эти обращения не прерывались. Следующим шагом будет сортировка обращений к файлам по положению на диске, т. Е. Выполнение на уровне файла того, что ядро ​​(и сам диск) делает с отдельными операциями ввода-вывода. Вместо того, чтобы иметь большую файловую систему с каталогами, вы можете создавать меньшие LV. Таким образом, вы можете отсортировать обращения к файлам по имени и получить доступ, отсортированный по области диска.

Если вы хотите сменить оборудование, это может быть интересно: Размещение только метаданных на SSD. И вы должны попытаться получить доступ для записи с ваших кэш-дисков. В основном это могут быть файлы журналов. Обычно они не очень важны, поэтому может помочь поместить их в файловую систему с большим временем фиксации и data=writeback.

Если (некоторые из) ваши данные кэша статичны (и вам не нужен ACL), вы можете проверить производительность, переместив их с ext4 на squashfs (сжатая файловая система только для чтения). Даже прозрачное сжатие (FUSE) в ext4 может помочь, если проблема заключается в чтении файла в несколько этапов. При упреждающем чтении файловой системы (и внутреннего диска) будет получена большая часть файла (если он сжимается).