Какой размер буфера журнала выбрать

Здравствуйте, уважаемые форумчанеПериодически сталкиваюсь с задачами потокового чтения/записи файлов. Выбираю разные подходы и размеры буферов. И в последнее время всё чаще возникала мысль написать что-то более-менее универсальное.Так вот возникла подходящая задача, в рамках которой я напишу и буду использовать такую штукенцию. Остаётся открытым вопрос оптимального размера буфера для чтения/записиRouse_ говорит, что для чтения оптимальный размер буфера 256кб. По его тестам буфер меньше или больше негативно влияет на производительностьбудут ли другие мнения ?оптимальный размер буфера на запись ?p.s. сегодня попробовал прочитать файл размером 200мб через CreateFileMapping — скорость в 2 раза медленнее, чем с предварительной буферизацией в куче. Readonly. Обращение к памяти стабильно по возрастанию

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

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

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

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

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

> DevilDevil © (25.01.13 13:07) [3]блок 64k, IOCompletionPort

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

> QAZ10 (25.01.13 13:08) [4]Я правильно понял, мы говорим о работе с файлом, которого нет в кеше? HD хранит в своем железном буфере данные, над которыми прошла головка.Важно успевать их забирать, пока их не затерли новые данные.Причем тут размер файла?

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

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

> Дмитрий С © (25.01.13 13:47) [10]значит, твоя задача отличается от задачи автора вопроса

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

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

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

> Sha © (25.01.13 13:36) [6]вот ты говоришь 64кба Rouse_ и QAZ10 говорят 256кби что лучше ?

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

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

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

> и что лучше ?нублин затесть и так и так и по другому> Sha © (25.01.13 13:56) [13]я когда тестил свои диски по отдельности а потом в рейде с разным размером стрипато например при файлах 128мб и выше практически линейная скорость при буферах от 64кб до 8мб а на файлах 64мб и ниже уже ёлочно-ступенчатая с пиком в районе кокраз 256 кб буфера

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

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

> DevilDevil © (25.01.13 14:35) [18]> > Sha © (25.01.13 14:25) [17]дело не в алгоритме, а оптимальности > для железа/драйверов/ОСпонятно, что есть зависимость 1. от железа, например, для рейда буфер должен быть больше, чем для отдельного диска, 2. от алгоритма и от используемых возможностей ОС > я хочу перенять опытразвернутый ответ в пятницу? )

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

> DevilDevil © (25.01.13 15:54) [23] не парь мозг,делай одинаковый,считал-обработал-записала если начнеш дробить еще на куски при за писи, выйдет булщит

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

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

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

вот бери 256 и иди работай 🙂

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

> QAZ10 (25.01.13 17:03) [28]> Павиа (25.01.13 17:15) [29]берите во внимание, что большой буфер — тоже не всегда хорошоибо чем меньше буфер — тем проще его поместить в кэш какого-то там уровня

> 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 Кб), дальше производительность падала.

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

> Pavia © (25.01.13 20:10) [39]Ну у меня это ничем не подтвердилось.

> DevilDevil © (25.01.13 12:38) > > Периодически сталкиваюсь с задачами потокового чтения/записи > файлов. Выбираю разные подходы и размеры буферов. И в последнее > время всё чаще возникала мысль написать что-то более-менее > универсальное.> Советую оформить буферизованный ввод-вывод в виде класса-наследника TStream (по-умному декоратора, обертки), тогда можно будет сделать буферизованный ввод-вывод для любого другого класса-потока, в. том числе и TFileStream. Размер буфера можно сделать свойством или передавать в конструктор. Максимальный размер буфера я бы выбрал 64к, минимальный 4к.

> тебе говорит что нибудь такое понятие как «кэшмисс» ?ну ты загоняешся бро, непотеме ;)при чем тут кэш чтения файла и кэшь проца да еще и с компилятором дельфи

Источник

Поделиться:
Нет комментариев

Добавить комментарий

Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.

×
Вам будет интересно