улучшение времени чтения небольших файлов с подключенным USB2 томом ext2

Question

Я более опытный программист Windows, чем программист Linux. Извиняюсь, если я упускаю что-то очевидное.

Мне нужно прочитать> 10 000 небольших файлов (~ 2-> 10 КБ) на томе ext2, подключенном через USB2, под управлением Linux. Дистрибутив является пользовательским и работает с busybox.

Я надеюсь на советы по улучшению этих записей. Я делаю следующее

handle = open(O_CREAT|O_RDWR)
read(handle, 2kBuffer)
close(handle);

, так как мои чтения малы, этот read () стремится выполнить работу за один вызов

Что я могу сделать, чтобы улучшить производительность? поскольку это нестандартный дистрибутив Linux, работающий на USB2 (съемном) диске, есть какие-нибудь очевидные настройки ядра или опции монтирования, которые я могу пропустить?

спасибо!

Answer 1

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

Помимо этого, вы пытались выполнять несколько операций параллельно?Это ускоряет вещи?Какую работу вы фактически делаете с данными, прочитанными из файлов?Другая работа занимает много времени?

Профилировали ли вы свою заявку?

Answer 2

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

Рассмотрим ext4? Параметр dir_index в ext3 является стандартным в ext4 и ускоряет работу с большим количеством файлов в одном каталоге. Он размещает метаданные, каталоги и файловые блоки гораздо более последовательно на диске и значительно уменьшает количество блоков, не относящихся к данным, необходимых для отслеживания каждого блока данных (хотя это имеет большее значение для больших файлов, чем для маленьких). Есть предложение вставить данные небольшого файла в его inode, но я не думаю, что это в восходящем потоке.

Если вы ограничены поиском (в отличие от полосы пропускания), это может помочь вызвать fadvise(FADV_WILLNEED) для набора файлов перед чтением из любого из них. Ядро воспринимает это как подсказку для чтения в файловый кеш. Тем не менее, будьте осторожны: чтение вперед больше, чем может вместить кэш, расточительно и медленнее. Есть предложение добавить fincore, чтобы определить, когда ваши файлы были выселены, но я не думаю, что это еще и апстрим.

Если окажется, что вы ограничены пропускной способностью, сжатие файлов с помощью LZO или gzip может помочь. Процессор по-прежнему должен быстрее распаковываться, чем диск читает с этими методами сжатия (в отличие от LZMA или bzip2).

Answer 3

монтирование устройства с отключенным « atime » (вам действительно не нужен каждый вызов read (), чтобы вызвать запись метаданных).Смотрите опцию noatime mount.Вызов open () также принимает флаг O_NOATIME, который делает то же самое для каждого файла.

(хотя многие ядра / дистрибутивы уже некоторое время используют опцию "relaytime" по умолчанию, получая в основном те же данныеускорения)

Answer 4

Большинство дистрибутивов ужасны из-за слишком низкого уровня кэширования на уровне блоков. Попробуйте установить

blockdev -setra 8192 /dev/yourdatasdev

он будет использовать немного больше оперативной памяти, но дополнительное кэширование хорошо работает практически в любых ситуациях. Если у вас много ОЗУ, используйте большие значения, я пока не вижу недостатка в этом, пропускная способность и задержка становятся все лучше и лучше с выделением большего объема ОЗУ. Конечно, есть уровень «насыщенности», но стандартные настройки настолько низки (512), что любое улучшение может иметь драматический эффект без выделения слишком большого количества памяти для этих буферов.

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