быстрое копирование файлов
Вот тебе про другую ОС: http://forums.storagereview.net/index.php?act=ST&f=2&t=1631
Что-то у тебя маленькие файлы, сколько RAM в тачке?
Как кэш очищаешь между экспериментами?
Как кэш очищаешь между экспериментами?
памяти 1 Gb. кэш специально не очищаю. специфика данной задачи в том, что данные скорее всего лежат в кэше. поэтому запускаю тест много раз, чтобы файл точно лежал в кэше.
продолжение эксперимента: с увеличением размера файла в первом способе время растет линейно, во втором - начинается тормоза. файл в 330 мегов копируется первым способом быстрее. похоже, что второй способ генерирует слишком много грязных страниц (?).
я изменил mmap/mmap на mmap/write, т.е. исходный файл читатеся через mmap, а в конченый пишется через write. в этом случае, на маленьких файлах время среднее (ровно в 1.5 раза больше исходного 2-го способа а на больших - чуть лучше первого. похоже это оптимальный вариант. хотелось бы все-таки понять это все из теории.
продолжение эксперимента: с увеличением размера файла в первом способе время растет линейно, во втором - начинается тормоза. файл в 330 мегов копируется первым способом быстрее. похоже, что второй способ генерирует слишком много грязных страниц (?).
я изменил mmap/mmap на mmap/write, т.е. исходный файл читатеся через mmap, а в конченый пишется через write. в этом случае, на маленьких файлах время среднее (ровно в 1.5 раза больше исходного 2-го способа а на больших - чуть лучше первого. похоже это оптимальный вариант. хотелось бы все-таки понять это все из теории.
как соотносятся слова
> основной тормоз - винт
и
> запускаю тест много раз, чтобы файл точно лежал в кэше
?
> основной тормоз - винт
и
> запускаю тест много раз, чтобы файл точно лежал в кэше
?
> Кто может объяснить это теоретически?
А на хер?
А на хер?
>как соотносятся слова
>> основной тормоз - винт
gkrellm показывает очень маленькую загрузку проца и очень большую загрузку hda
> запускаю тест много раз, чтобы файл точно лежал в кэше
но если делать запуски, то время монотонно убывает, стремясь к некоторой константе. чего у нее при этом в кэше лежит - хз.
>> основной тормоз - винт
gkrellm показывает очень маленькую загрузку проца и очень большую загрузку hda
> запускаю тест много раз, чтобы файл точно лежал в кэше
но если делать запуски, то время монотонно убывает, стремясь к некоторой константе. чего у нее при этом в кэше лежит - хз.
у тебя время выполнения очень маленькое, сама по себе разница в секунду не решает
а если, например, копировать много файлов подряд, то возможно и результаты совсем другие станут
про теоретическое обоснование:
само наличие разницы объяснить просто - разные операции, разный код, соотв. разный результат
объяснить, почему результаты именно такие теоретически скорее всего не удастся, и даже если получится, то за время, потраченное на поиск объяснение, VM в ядре несколько раз перепишут
а если, например, копировать много файлов подряд, то возможно и результаты совсем другие станут
про теоретическое обоснование:
само наличие разницы объяснить просто - разные операции, разный код, соотв. разный результат
объяснить, почему результаты именно такие теоретически скорее всего не удастся, и даже если получится, то за время, потраченное на поиск объяснение, VM в ядре несколько раз перепишут
а на 100G файл запусти свою прогу :-)
А при write пользовательские данные случаем не копируются во внутренний буфер? При file map'e то наверняка в лоб постранично пишут.
я тоже так думал. однако это противоречит наблюдениям: при размерах > 300 Mb второй способ медленне первого.
а разве mmap может увеличить размер файла?
покажи проги короче
покажи проги короче
А ты попробуй проконтролировать в процессе размеры кешей объектов ядра, возможно интенсивная запись приводит к тому, что накапливается много буферов засирающих память и вызывается swap. А write медленнее и диск успевает справиться.
> а разве mmap может увеличить размер файла?
не может. но я сначала делаю stat, потом truncate.
> покажи проги короче
да там все тривиально: http://lorien.local/pub/docs/temp/1.cpp
не может. но я сначала делаю stat, потом truncate.
> покажи проги короче
да там все тривиально: http://lorien.local/pub/docs/temp/1.cpp
Очень похоже на то. Хотя вроде памяти-то много: 1 Gb, свободно около 500 Mb, файл 330 Mb. То есть 1 раз файл точно должен влезать, даже половина от выходного влазит. Почему же он тогда начинает так дико винтом дрыгать? Может у нее какое-то ограничение стоит на размер кэша (на запись если он большой, она начинает принудительно все на винт скидывать?
А как можно контролировать размер кэшей в процессе работы?
А как можно контролировать размер кэшей в процессе работы?
Это в /proc/meminfo - общая информация, можно посмотреть как всякие clean, dirty и active списки меняются +
/proc/slabinfo - там уже инфа о кешах, формат -
Name, Objects in use, total number, size of object, помоему число страниц задействованных на активные object'ы, сколько вообще страниц задействовано, ненужная инфа
/proc/slabinfo - там уже инфа о кешах, формат -
Name, Objects in use, total number, size of object, помоему число страниц задействованных на активные object'ы, сколько вообще страниц задействовано, ненужная инфа
Оставить комментарий
Landstreicher
Нужно быстро скопировать файл. Я решил провести небольшой эксперимент: копируется 2-мя способами:1) cp file1 file2
2) программа на C, которая ползет окном по файлу, mmap-ит его в обоих файлах и делается memcpy
Измерения показали:
Видно, что споcобы отличаются стабильно в 2 раза.
Почему? Кто может объяснить это теоретически?
Процессор не грузится в обоих случаях, основной тормоз - винт.
PS. Кто-нибудь может провести этот эксперимент в других ОС?