Производительность EXT4 стала очень плохой в системе с большим количеством маленьких файлов

У меня есть небольшое встроенное устройство, которое имеет только 128 МБ оперативной памяти

к этому устройству подключен жесткий диск USB2 емкостью 2 ТБ

Я был очень доволен производительностью устройства до недавнего времени, когда число файлов пересекает пороговое значение, а емкость диска пересекает пороговое значение (я не уверен, какой именно)

На диске много маленьких файлов, из-за природы пишущих файлов приложения организованы очень сбалансированным образом - ни в одном листовом каталоге нет более 200 файлов, а в нем чуть более 800 000 файлов.

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

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

в качестве эксперимента я разобрал диск (очистка кешей, проверено на бесплатность). Затем из командной строки я углубился в структуру каталогов. Все сказали, что в этом каталоге (и его дочерних элементах) было всего около 3200 файлов, содержащихся под ним, и в этот момент «свободный» показал> 117 МБ свободной памяти.

в этот момент я набрал команду «найти», а затем «бесплатно»

'find' показал около 3000 файлов, но использование памяти изменилось с ~ 117MB до ~ 2MB

Я понимаю баланс между кешем и свободной памятью и то, как ядро ​​считает пустую страницу плохой страницей - однако 115 МБ кэшированного содержимого из каталога в 3000 файлов указывают на серьезный пробел в моем понимании. Я надеюсь, что кто-то поможет мне понять, что происходит

могу ли я предположить, что сбалансированное дерево - это способ иметь много файлов?

Очень хорошее описание проблемы.

Исходя из того, что вы сказали, я думаю, что вы видите, что использование плит будет высоким. Хороший эксперимент будет запустить cat /proc/meminfoи cat /proc/slabinfoчерез вторую задержку 3 , а вы идете вглубь иерархии фс и открыть 3000 файлов. По сути, происходит то, что ядро ​​пересекает структуру fs и сканирует отдельные файлы и их иноды, и все они хранятся в памяти. Если вы проверите, /proc/slabinfoвы увидите объект с именем, ext4_inode_cacheкоторый сообщает вам, сколько памяти займет каждый индекс. Умножьте это на количество объектов (obj_size * no_obj), и вы получите объем памяти, используемый объектом. Чем глубже вы углубляетесь в иерархию fs, тем больше памяти будет расходоваться, пока система не достигнет верхнего водяного знака зоны памяти. В этот момент ядро ​​начнет восстанавливать.

Если вы нажмете на meminfo и slabinfo, вы получите подробную информацию, которую вы ищете. Если вы хотите, чтобы я посмотрел, вставьте его;)