Задача перемещаться в большом файле и читать информацию. Пробовал Ext3 и JFS, при определённом размере файла начинаются жуткие тормоза. Этот размер зависит от объёма оперативки. Видимо, кончается дисковый кэш.
Возможно, есть ФС, не нуждающиеся в подобном кэшировании для смещений, например, записывающие файлы строго последовательно? Или есть другие способы решение проблемы. Буду рад любому совету :)
Последние комментарии
-
OlegL, 17 декабря 2023 года в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
Строго последовательно будет быстро только если ты читаешь строго последовательно. Насколько большой файл? Я на работе юзаю XFS для БД размером 3-6 ГБ. Относительно быстро получается. Правда там ещё RAID из 5 SASов…
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.
Не стоит забывать, что у них кластер с избыточностью на котором практически напрямую рабтает GoogleFS. И совсем другие объёмы. Тут это явно будет overkill.
Да, обычно в таких случаях советуют XFS…