Intereting Posts
Сравнение нескольких строк в одном сценарии оболочки оператора if с использованием ИЛИ gate Исправлена ​​ошибка установки операционной системы FreeBSD pkg Почему запись без номера отображается после «0» при сортировке? Почему backports называют backports? Распределения Linux для процессоров ARM TPM (идентификатор устройства 0x0, rev-id 78) Как загрузить последнюю версию cmake с помощью tar xzf? Почему следующая последовательность оболочек заканчивается так быстро? Есть ли html-поиск / поисковик документов, например, служебная информация для информационных файлов? Не могу изменить раскладку клавиатуры внутри vncserver Получение и AMD Catalyst и Touchpad для работы на ноутбуке Samsung (NP730U3E) Сохранить пароль как hash в wpa_supplicant.conf? Gnome-manual-duplex в Gnome 3 на Arch Linux Название файла печати, измененная дата и размер с заголовком зарезервировать ресурсы для консоли администратора

Хранение тысяч файлов в одном каталоге

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

Я понимаю, что это нехорошо и что I / O будет деградировать, и я также слышал о потенциальной проблеме inode.

И я знаю, как исправить код кеширования, но дело в том, что на этом этапе исправление будет очень дорогостоящим.

Вопрос : что такое худший вариант, если я живу так, как сейчас? Что произойдет с веб-сайтом? (прямо сейчас этот единственный каталог кеша имеет 400K файлов)

Я новичок в Ubuntu. И я понимаю, что это может быть не по теме. Но я думаю, что это «системный» вопрос, и он не относится к «программированию» части stackoverflow.

Благодаря!

UPDATE: файловая система UFS

Ситуация несколько удивительна. UFS – необычная файловая система для установки Linux. UFS-доступ для записи под Linux обычно должен быть явно включен в ядре, поскольку он уже много лет считается экспериментальным :

CONFIG_UFS_FS_WRITE: поддержка записи в файловой системе UFS (ОПАСНО)

Скажите Y здесь, если вы хотите попробовать писать разделы UFS. Это экспериментально, поэтому вам необходимо заранее создать резервные копии своих разделов UFS.

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

Насколько мне известно, поддержка UFS под Linux не использует Dirhash. Таким образом, вы можете ожидать повышения производительности, поскольку количество файлов в вашем каталоге растет. Что касается последовательного доступа, то 400K-файлов много, и вы можете ожидать значительного повышения производительности.

Разделение файлов между подкаталогами эффективно управляет проблемой последовательного доступа. Кроме того, вы можете перейти к файловой системе, которая поддерживает более сложную структуру хранения файлов. Например, XFS реализует быстрый доступ к файлам для больших каталогов с помощью деревьев B + .

Ваша вторая забота была о инодах. Как правило, число inodes в вашей файловой системе исправлено, и обычно это функция объема пространства, доступного в момент создания файловой системы. Например, /etc/mke2fs.conf содержит коэффициент inode по умолчанию (количество inodes per x bytes) для файловых систем ext.

Обычно это число намного больше, чем количество файлов, которые вы, вероятно, создаете, и не вызывает беспокойства. Однако вы можете проверить использование inode с помощью df -i . Если на самом деле недостатки inode могут быть проблемой, беспорядок с каталогами не поможет вам, поскольку inodes – это концепция, основанная на файловой системе, независимо от каталога. В этом случае вам придется заново создать файловую систему, соответствующим образом настроив параметр inode ( -i ) на mkfs .

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

Обычные проблемы с описанным вами подходом:

  • файловые системы используют хэши или древовидные структуры данных для поиска в каталогах, чтобы ускорить поиск и создание, тем больше файлов у вас в одном каталоге медленнее. С хешированием это замедление может быть довольно выраженным, поскольку происходят столкновения.
  • типичные команды unix имеют проблемы (в частности, сортировка ls и расширение оболочки glob), хотя обычно задолго до замедления файловой системы.
  • поскольку каталог получает новые файлы, выделяется больше блоков, он становится все более фрагментированным, что требует большего доступа к IO для доступа к диску.

Более современные файловые системы (ext3 / 4) используют структуры данных типа B-tree, чтобы сортировать каталоги, как часть данных на диске. Я считаю, что реализация UFS использует хэширование в памяти (на основе использования FreeBSD и документации, у меня нет большого опыта работы с UFS в Linux), поскольку формат на диске не использует хеши.

У этого есть хорошая информация UFS и ссылки: https://serverfault.com/questions/53416/max-total-files-in-a-directory-in-freebsd-6-ufs

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

Я рекомендую вам отслеживать (и график) время вашей системы в iowait и узнать iotop и slabtop если вы этого еще не сделали.

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