У меня есть небольшое встроенное устройство, в котором всего 128 МБ ОЗУ.
к этому устройству подключен жесткий диск USB2 емкостью 2 ТБ
Я был очень доволен производительностью устройства до недавнего времени, когда количество файлов превышало пороговое значение емкости диска (я не уверен, что именно)
на диске много небольших файлов, из-за особенностей записи файлы приложений организованы в виде очень сбалансированный способ - ни в одном каталоге конечных узлов не более 200 файлов, а файлов чуть более 800 000.
Я надеюсь узнать что-нибудь о расследовании. Производительность диска значительно упала, устройство работало достаточно хорошо, а затем внезапно производительность упала как камень.
Я предполагаю, что организационная структура, которую я выбрал на диске для своих файлов, каким-то образом повлияла на способность кешей inode оставаться стабильной.
в качестве эксперимента размонтировал диск (прошивка кешей, проверил бесплатно). Затем из командной строки я вошел в структуру каталогов. Все сказали, что этот каталог (и его дочерние элементы) содержал только около 3200 файлов, и на данный момент 'free' показал> 117 МБ свободной памяти.
в этот момент я набрал команду "найти", а затем "бесплатно"
'find' показал около 3000 файлов, но использование памяти увеличилось с ~ 117 МБ до ~ 2 МБ
Я понимаю баланс кеша и свободной памяти и то, как ядро считает пустую страницу плохой страницей, однако 115 МБ кэшированного содержимого из каталога из 3000 файлов указывают на серьезный пробел в моем понимании. Я надеюсь, что кто-нибудь поможет мне понять, что происходит
Могу ли я предположить, что сбалансированное дерево - это способ иметь много файлов?
Очень хорошее описание проблемы.
Основываясь на том, что вы сказали, я думаю, что вы наблюдаете высокий рост использования плиты. Хорошим экспериментом было бы запустить cat /proc/meminfo и cat /proc/slabinfo с задержкой в 3 секунды, пока вы углубитесь в иерархию файловых систем и обнаружите 3000 файлов. По сути, происходит то, что ядро проходит структуру fs и просматривает отдельные файлы и их inode, и все они хранятся в памяти. Если вы проверите /proc/slabinfo вы увидите объект под названием ext4_inode_cache который сообщает вам, сколько памяти займет каждый индексный дескриптор. Умножьте это на количество объектов (obj_size * no_obj), и вы получите объем памяти, используемый объектом. Чем глубже вы войдете в иерархию fs, тем больше памяти будет потребляться, пока система не достигнет верхнего предела зоны памяти. В этот момент ядро начнет восстановление.
Если вы ткнетесь в meminfo и slabinfo, вы получите подробную информацию, которую ищете. Если хотите, чтобы я посмотрел, вставьте его;)