nixp.ru v3.0

26 мая 2017,
пятница,
16:10:19 MSK

DevOps с компанией «Флант»
imbolc написал 24 декабря 2009 года в 17:25 (738 просмотров) Ведет себя неопределенно; открыл 1 тему в форуме.

Задача перемещаться в большом файле и читать информацию. Пробовал Ext3 и JFS, при определённом размере файла начинаются жуткие тормоза. Этот размер зависит от объёма оперативки. Видимо, кончается дисковый кэш.

Возможно, есть ФС, не нуждающиеся в подобном кэшировании для смещений, например, записывающие файлы строго последовательно? Или есть другие способы решение проблемы. Буду рад любому совету :)

myst

Строго последовательно будет быстро только если ты читаешь строго последовательно. Насколько большой файл? Я на работе юзаю XFS для БД размером 3-6 ГБ. Относительно быстро получается. Правда там ещё RAID из 5 SASов…

sendmoreinfo

google обошел эту проблему, читая raw device:

http://lwn.net/Articles/357658/

Google would like a way to pin filesystem metadata in memory. The problem here is being able to bound the time required to service I/O requests. The time required to read a block from disk is known, but if the relevant metadata is not in memory, more than one disk I/O operation may be required. That slows things down in undesirable ways. Google is currently getting around this by reading file data directly from raw disk devices in user space, but they would like to stop doing that.

myst

Не стоит забывать, что у них кластер с избыточностью на котором практически напрямую рабтает GoogleFS. И совсем другие объёмы. Тут это явно будет overkill.

Дмитрий Шурупов

Да, обычно в таких случаях советуют XFS…