обработка большого количества временных маленьких файлов

Question

У меня есть веб-сервер, который сохраняет файлы кэша и хранит их в течение 7 дней. Имена файлов представляют собой хеши md5, то есть ровно 32 шестнадцатеричных символа, и хранятся в древовидной структуре, которая выглядит следующим образом:

00/
  00/
    00000ae9355e59a3d8a314a5470753d8
    .
    .
00/
  01/

Вы поняли.

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

find cache/ -mtime +7 -type f -delete

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

Стандартным решением для LRU-кеша является какая-то куча. Есть ли способ масштабировать это до уровня файловой системы? Есть ли другой способ реализовать это таким образом, чтобы упростить управление?

Вот идеи, которые я рассмотрел:

1. Создайте 7 главных каталогов, по одному на каждый день недели, и очищайте по одному каталогу каждый день. Это увеличивает время поиска файла кэша в 7 раз, усложняет процесс перезаписи файла, и я не уверен, что он будет делать со временем удаления.
2. Сохраните файлы в виде больших двоичных объектов в таблице MySQL с индексами по имени и дате. Это казалось многообещающим, но на практике это всегда было намного медленнее, чем FS. Может быть, я делаю это неправильно.

Есть идеи?

Answer 1

Когда вы сохраняете файл, сделайте символическую ссылку на вторую структуру каталогов, которая организована по дате, а не по имени.

Получите ваши файлы, используя структуру "name", удалите их, используя структуру "date".

Answer 2

Предполагая, что это ext2 / 3, вы пытались добавить в проиндексированные каталоги? Когда у вас есть большое количество файлов в любом конкретном каталоге, поиск будет мучительно медленным, чтобы что-то удалить.
используйте tune2fs -o dir_index, чтобы включить параметр dir_index.
При монтировании файловой системы обязательно используйте параметр noatime, который не позволяет ОС обновлять информацию о времени доступа для каталогов (по-прежнему необходимо их изменять).
Глядя на оригинальный пост, кажется, что у вас есть только 2 уровня косвенного обращения к файлам, что означает, что вы можете иметь огромное количество файлов в конечных каталогах. Если в них более миллиона записей, вы обнаружите, что поиск и изменения очень медленные. Альтернативой является использование более глубокой иерархии каталогов, сокращая количество элементов в любом конкретном каталоге, и, следовательно, снижая стоимость поиска и обновлений для конкретного отдельного каталога.

Answer 3

Как насчет этого:

• Пусть другая папка называется, скажем, "ToDelete"
• Когда вы добавляете новый элемент, получите сегодняшнюю дату и найдите подпапку в «ToDelete», имя которой указывает на текущую дату
• Если его там нет, создайте его
• Добавить символическую ссылку на элемент, который вы создали в сегодняшней папке
• Создайте задание cron, которое отправляется в папку «ToDelete» с правильной датой, и удалите все связанные папки.
• Удалить папку, в которой содержались все ссылки.

Answer 4

Reiserfs относительно эффективен при обработке небольших файлов. Вы пробовали разные файловые системы Linux ? Я не уверен насчет производительности удаления - вы можете рассматривать форматирование (mkfs) как замену отдельного удаления файла. Например, вы можете создавать разные файловые системы (cache1, cache2, ...) для каждого дня недели.

Answer 5

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