Как устроить быстрое чтение рандомных участков в файле в 400 гб?

Question

[ruboss]

Нужно максимально быстро считывать с файла блоки байт заданного размера.

Я создал файл 400гб и записал в него 4 миллиарда записей по 100 байт.

Дальше пытаюсь рандомно доставать 100 байт из любого места файла.

SSD 400 gb, 56gb ram, linux ubuntu , ext4. Код минимальный на java.
Использовал RandomAccessFile класс. Но для seek он каждый раз делает его не от текущего места а от начала файла.

Результат - 1000 случайных чтений блоков по 100 байт за 7 секунд.

Как можно ускорить случайное чтение?

Answer 1

[nirvimel]

Автор должен был сразу указать, что речь идет не о физическом сервере, а о гипервизоре azure microsoft.
Это объясняет многое... Нет, это объясняет все!
И слово SSD будет лучше убрать, если вы этот "SSD" сами в руках не держали (и никто его в руках не держал, т.к. это просто виртуалка под гипервизором).

Comments

[ruboss]

это виртуальная машина, не знаю какая разница что vps что vds, ресурсы по идее одинаковые, в чем разница кроме "держал в руках" ?

[nirvimel]

ruboss: Это не SSD и не HDD, это виртуальный диск виртуальной машины под гипервизором. Безусловно, виртуальный диск backended by физический(ие) диск(и), но эта связь чисто программная, характер этой связи определяется гипервизором, где-то добавлен кеш (не зависимо от O_SYNC O_DIRECT в гостевой системе), где-то добавлены лимиты iops (чтобы одна vm в каком-нибудь burning test не положила весь кластер), где-то один логический том (физический для гостевой ОС) разнесен между множеством физических, как в lvm, где-то куча логических от разных виртуалок лежат на одном физическом... и еще сотня разных вариантов.

[ruboss]

nirvimel: вот бенчмарки посмотрите:

root@vtt9:/mnt# dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 0.731311 s, 1.5 GB/s
root@vtt9:/mnt#  sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"
root@vtt9:/mnt# dd if=./largefile of=/dev/null bs=4k
262144+0 records in
262144+0 records out
1073741824 bytes (1.1 GB) copied, 2.66522 s, 403 MB/s

как думаете, по скорости на много медленнее ssd?

[nirvimel]

ruboss: hdparm -t меряет линейную скорость чтения. В линейной скорости SSD не обязаны сильно превосходить HDD. Есть другая важная характеристика device access time (под этим понимается именно random access), вот она то у механических и немеханических дисков может различаться на 2 порядка.

Но вся эта физика (почти) не имеет смысла, когда разговор идет про виртуальные машины.

[nirvimel]

ruboss: dd - показывает тоже линейную скорость.
sync && echo 3 > /proc/sys/vm/drop_caches - под гипервизором имеет мало смысла.

[ruboss]

nirvimel: т.е. вы считаете, что на настоящем ssd скорость выборки должна быть значительно быстрее чем на облаках мелкософта?

[ruboss]

nirvimel: буду надеятся что так и есть =) а дальше разберусь, спасибо большое!

[ruboss]

Взял реальный ссд, поставил, прошивка так себе и диск не самый лучший - получил 500 мсек

Answer 2

[alexxandr]

Сменить язык на C

Comments

[ruboss]

Спасибо, сменю, есть ещё идеи?)

[Adamos]

Зачем сразу "сменить"? Для начала сесть и за полчаса написать тест, проверяющий скорость чтения того же файла на Сях.
Если разница критична - тогда уже задуматься, что не так в Джаве.

[alexxandr]

можно попробовать сменить используемый класс на FileReader, скорее всего он будет быстрее. Также потюнить GC не помешает

[ruboss]

Adamos: спасибо, так и хотел

[ruboss]

alexxandr: спасибо, проверю

[lega]

Скорее всего, проблема не в языке, а в железе, поэтому можно писать хоть на "PHP"

[ruboss]

lega: это сервер azure microsoft, странно что у них такие проблемы могут возникать, поделаю тесты на скорость зачит

[ruboss]

Запилил то же самое на си/си++ - почему-то вышло еще медленнее - за 9 секунд...

Answer 3

[lega]

Но для seek он каждый раз делает его не от текущего места а от начала файла

seek просто задает адрес и не делает io операций, поэтому это не влияет.

Скорее всего SSD тормозной, можете проверить его тулзами. Так же когда вы считываете всего 100 байт, с самого девайса считывается минимальный блок (4кб, 16кб, ...)

Comments

[ruboss]

Хм, на ssd тоже так.. Думал иначе устроено на них. Размер блоков зависит от диска или их можно настраивать в ФС?

[АртемЪ]

ruboss: Разумеется это зашито в диске.
А как еще может быть устроено на SSD?
Для каждого блока нужно посчитать контрольную сумму, на случай ошибок считывания, нужно хранить количество перезаписей, нужно держать запись в таблице соответствия с ФС.
Т.е там служебной информации на блок как раз те же 100байт, если не больше, поэтому сделать его меньше, или примерно равным по размеру нереально.

Answer 4

[Saboteur]

"Я создал файл 400гб и записал в него 4 миллиарда записей по 100 байт. "

Не очень понятна эта фраза. У вас просто бинарный файл, или база данных?
Если просто бинарный файл, то что означает "записал в него 4 млрд записей"?

Comments

[ruboss]

Всмысле 4 миллиарда блоков по 100 байт. Это хранилище, зная ключ я сразу достаю запись с нужного места. Key/value типа

[Saboteur]

ruboss: У вас взаимоисключающие параграфы. Что такое ключ?

С точки зрения random access к диску, вы должны считывать файл по его смещению, а не сперва искать ключ, затем по ключу искать value.

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

[Adamos]

Сергей: ключ - это смещение в файле, всего лишь. Очевидно же.

[ruboss]

Сергей: Adamos прав

Answer 5

[АртемЪ]

Но для seek он каждый раз делает его не от текущего места а от начала файла

Почему вы так решил? На основании какой информации, и почему считаете должно быть по другому?

Comments

[ruboss]

хм, особо не вникал, я думал есть разница в скорости перемеения т.е от начала файла до т. А - 1 гб , а от точки А до точки Б 1 мб, и перейти к чтению из т. Б будет гораздо быстрей чем из начала, это не так? про seek узнал docs.oracle.com/javase/7/docs/api/java/io/RandomAc...

[АртемЪ]

ruboss: Ну не совсем так, учитывая что у вас SSD.
Нет никакого перехода доступ ко всем блокам примерно одинаков по времени.
К тому же следует учитывать тот факт, что SSD хранит информацию не там куда указывает файловая система, у него свои принципы хранения.
Например если вы разобъете SSD на два логических диска и будете писать только в один - информация будет размазана по всему диску.

[АртемЪ]

А вообще чтобы повысить скорость есть мысли.
Как вы читаете? Одиночными чтениями, или формируете сразу кучу запросов?
Максимальная скорость будет при большой очереди.