Оптимальный размер буфера для чтения/записи файла

← →
DevilDevil © (2013-01-25 12:38) [0]

Здравствуйте, уважаемые форумчане

Периодически сталкиваюсь с задачами потокового чтения/записи файлов. Выбираю разные подходы и размеры буферов. И в последнее время всё чаще возникала мысль написать что-то более-менее универсальное.

Так вот возникла подходящая задача, в рамках которой я напишу и буду использовать такую штукенцию. Остаётся открытым вопрос оптимального размера буфера для чтения/записи

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

будут ли другие мнения ?
оптимальный размер буфера на запись ?

p.s. сегодня попробовал прочитать файл размером 200мб через CreateFileMapping - скорость в 2 раза медленнее, чем с предварительной буферизацией в куче. Readonly. Обращение к памяти стабильно по возрастанию

← →
DevilDevil © (2013-01-25 12:50) [1]

кто то говорит 16кб, кто то говорит 32кб
в TCustomZlibStream (ZLib, Delphi 7) используется буфер в 64кб

← →
Sha © (2013-01-25 12:58) [2]

Зависит от алгоритма обработки считанных данных.
Если будешь обрабатывать данные очень быстро, то и 64k будет достаточно.

Что касается FileMapping, то даже размер мапы в 64k способен обеспечить примерно ту же производительность, что и IOCompletionPort.

← →
DevilDevil © (2013-01-25 13:07) [3]

> Sha © (25.01.13 12:58) [2]

допустим работа с файлами - самое слабое место алгоритма
меня интересует самый оптимальный подход в плане производительности

← →
QAZ10 (2013-01-25 13:08) [4]

> Rouse_ говорит, что для чтения оптимальный размер буфера 256кб

это зависит от диска, и размера файла
можеш сам затестить каким нить HD Tune pro и лучше на голом разделе без фрагментации
а так да, в основном 256 самый срост у него меньше всего провалов по скорости

← →
QAZ10 (2013-01-25 13:09) [5]

> допустим работа с файлами - самое слабое место алгоритма

заодно можеш сделать в 2 потока - пока читается второй блок с диска обрабатываешь первый и тд

← →
Sha © (2013-01-25 13:36) [6]

> DevilDevil © (25.01.13 13:07) [3]

блок 64k, IOCompletionPort

← →
Дмитрий С © (2013-01-25 13:38) [7]

> DevilDevil © (25.01.13 13:07) [3]
> > Sha © (25.01.13 12:58) [2]
> допустим работа с файлами - самое слабое место алгоритма
> меня интересует самый оптимальный подход в плане производительности

Для некоторых задач я загружал 100-200 метровые файлы полностью в память для обработки. От задачи зависит.

← →
Sha © (2013-01-25 13:43) [8]

> QAZ10 (25.01.13 13:08) [4]

Я правильно понял, мы говорим о работе с файлом, которого нет в кеше?
HD хранит в своем железном буфере данные, над которыми прошла головка.
Важно успевать их забирать, пока их не затерли новые данные.

Причем тут размер файла?

← →
Sha © (2013-01-25 13:45) [9]

> Дмитрий С © (25.01.13 13:38) [7]
> Для некоторых задач я загружал 100-200 метровые файлы полностью в память для обработки.

Ну и что?
Я полностью обрабатываю файлы за то же время.

← →
Дмитрий С © (2013-01-25 13:47) [10]

> Я полностью обрабатываю файлы за то же время.

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

← →
Sha © (2013-01-25 13:50) [11]

> Дмитрий С © (25.01.13 13:47) [10]

значит, твоя задача отличается от задачи автора вопроса

← →
QAZ10 (2013-01-25 13:50) [12]

> Причем тут размер файла?

вроде непричем, а есть :) а кроме железного буфера есть еще виндовый

← →
Sha © (2013-01-25 13:56) [13]

Мы ведь не файлах меньше железного буфера?
Ясен пень винда будет влиять. Но не это не первая скрипка.

← →
brother © (2013-01-25 14:07) [14]

имхо нужно учитывать геометрию диска...

← →
DevilDevil © (2013-01-25 14:15) [15]

> Sha © (25.01.13 13:36) [6]

вот ты говоришь 64кб
а Rouse_ и QAZ10 говорят 256кб
и что лучше ?

← →
Slym © (2013-01-25 14:23) [16]

буфера должны быть третьего размера! ну и геометрия чтоб тоже была :) С пиатницой Всех

← →
Sha © (2013-01-25 14:25) [17]

считаешь, есть магический размер, пригодный для любого алгоритма?

← →
DevilDevil © (2013-01-25 14:35) [18]

> Sha © (25.01.13 14:25) [17]

дело не в алгоритме, а оптимальности для железа/драйверов/ОС

← →
QAZ10 (2013-01-25 14:36) [19]

> и что лучше ?

нублин затесть и так и так и по другому

> Sha © (25.01.13 13:56) [13]

я когда тестил свои диски по отдельности а потом в рейде с разным размером стрипа
то например при файлах 128мб и выше практически линейная скорость при буферах от 64кб до 8мб а на файлах 64мб и ниже уже ёлочно-ступенчатая с пиком в районе кокраз 256 кб буфера

← →
картман © (2013-01-25 14:43) [20]

> нублин затесть и так и так и по другому

и собирай статистику, да программно подстраивай размер под текущие систему и задачи

← →
DevilDevil © (2013-01-25 14:52) [21]

> нублин затесть и так и так и по другому

зачем городить велосипеды, когда с такой задачей справлялись до меня уже сотни программистов. я хочу перенять опыт

← →
Sha © (2013-01-25 15:21) [22]

> DevilDevil © (25.01.13 14:35) [18]
> > Sha © (25.01.13 14:25) [17]дело не в алгоритме, а оптимальности
> для железа/драйверов/ОС

понятно, что есть зависимость
1. от железа, например, для рейда буфер должен быть больше, чем для отдельного диска,
2. от алгоритма и от используемых возможностей ОС

> я хочу перенять опыт

развернутый ответ в пятницу? )

← →
DevilDevil © (2013-01-25 15:54) [23]

короче беру размер 256 кб для чтения и 64 кб для записи
если кто считает, что выбраны не оптимальные цифры - с удовольствием выслушаю

← →
QAZ10 (2013-01-25 16:23) [24]

> DevilDevil © (25.01.13 15:54) [23]

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

← →
DevilDevil © (2013-01-25 16:49) [25]

> QAZ10

запись файла и чтение файла - это совершенно разные операции
нужно добиться максимально возможной производительности отдельно на каждой из них

← →
QAZ10 (2013-01-25 16:55) [26]

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

← →
DevilDevil © (2013-01-25 17:01) [27]

> QAZ10

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

← →
QAZ10 (2013-01-25 17:03) [28]

вот бери 256 и иди работай :)

← →
Павиа (2013-01-25 17:15) [29]

Бери 1 MByte на чтение и запись. И не парь мозги. На ближайшие лет 10 хватит.

> QAZ10 (25.01.13 17:03) [28]
> Павиа (25.01.13 17:15) [29]

берите во внимание, что большой буфер - тоже не всегда хорошо
ибо чем меньше буфер - тем проще его поместить в кэш какого-то там уровня

← →
QAZ10 (2013-01-25 18:18) [31]

> DevilDevil © (25.01.13 18:10) [30]

ну началось...
ты про кэшь проца чтоли? можеш про него забыть и теоретически и практически ибо он тебе неподвластен, также как и кэш самого диска
и вроде как речь шла о тормозах именно с диском а не с алгоритмом?

> QAZ10 (25.01.13 18:18) [31]

тебе говорит что нибудь такое понятие как "кэшмисс" ?
я к тому, что если выберешь большой буфер - то будут у тебя неоправданные кэшмисс

> берите во внимание, что большой буфер - тоже не всегда хорошоибо
> чем меньше буфер - тем проще его поместить в кэш какого-
> то там уровня

Я же тебе не 10-100 МБайт советую. Во вторых я же не с потолка взял, а после тестирования.

А разве сама ОС не закеширует какое-то количество файла при чтении или записи?

P.S. Может между делом кто-нибудь подскажет как во FreePascal сделать Flush записанному файлу (os linux)?

Я говорил про 256 Кб потому что делал тестирование на нескольких сотнях рабочих станций, выборка получилась достаточная ибо ОС, кол-во памяти на борту, сами хардешники и их комбинации с райдами сильно отличались. Данный размер буфера показал наибольшую производительность при чтении. Задача была проверить некий набор баз на их целостность через рассчет контрольной суммы файлов. Объем баз варьировался, но обычно был в районе 8-12 гигов. На запись не тестировал - не возникало такой задачи, поэтому тут ничего сказать не смогу.

> Rouse_ © (25.01.13 19:10) [35]
> На запись не тестировал - не возникало такой задачи, поэтому
> тут ничего сказать не смогу.

вот это жалко :)
но я попробую у себя в тестах и 64кб и 256кб

> Я говорил про 256 Кб потому что делал тестирование на нескольких
> сотнях рабочих станций,

Ключевое слово делал. Да было 256, сейчас чаще всего 512. А 1024 я посоветовал на будущее.

> Pavia © (25.01.13 19:42) [37]
>
> > Я говорил про 256 Кб потому что делал тестирование на
> нескольких
> > сотнях рабочих станций,
>
> Ключевое слово делал. Да было 256, сейчас чаще всего 512.
>

Ну если на последние два месяца что изменилось тогда ой :) Тестирование производилось от буфера в 2^12 (4 Кб) с изменением кратности до 2^25 (32 мегабайта). Пик производительности был на 2^18 (256 Кб), дальше производительность падала.

> дальше производительность падала.

Там падение не такое большое. А вот прирост может оказаться большим.

Оптимальный размер буфера для чтения/записи файла Найти похожие ветки