LINUX.ORG.RU

Буфер при копировании файлов — всего 8К, почему так?

 , ,


0

4

Собственно, при копировании файлов чтение и запись файла идёт через буфер buf, размер которого зашит в программе и равен 8К (см. mc-4.8.16/src/filemanager/file.c, строка 1799):

        while (TRUE)
        {
            char buf[BUF_8K];

            /* src_read */
            if (mc_ctl (src_desc, VFS_CTL_IS_NOTREADY, 0))
                n_read = -1;
            else
                while ((n_read = mc_read (src_desc, buf, sizeof (buf))) < 0 && !ctx->skip_all)

Собственно, почему такой, и не маловат ли?

Интерес мой возник в связи с использованием mc на GlusterFS: с некоторых пор очень медленно копирует (см. http://darksoft.org/webbzr/mydocs/trunk/annotate/head:/Administration/Server/...):

midnight-commander have very small copy buffer and for this reason performs really bad

Может, стоит увеличить размер буфера? Я сделал себе 2М и скорость копирования больших файлов возросла почти на 2 порядка :)

★★★★☆

Последнее исправление: Sahas (всего исправлений: 1)

Это говорит о том, что оверхед на один рид сопоставим с собственно латентностью дисковой подсистемы. То есть не буферы надо увеличивать, а искать какого хрена там mc_read() столько времени ковыряется.

arturpub ★★
()
Ответ на: комментарий от arturpub

а смысл делать небольшой буфер? Как мне видится, это может ускорить копирование мелких файлов, да и то сомнительно...

Не уверен, что проблема в mc_read - там после read ещё куча действий выполняется до собственно write, как я понял

Sahas ★★★★☆
() автор топика

Не знаю, что за GlusterFS, но чисто теоретически манипуляции с размером буфера могут дать какой-нибудь прирост к скорости копирования на медленную дешёвую флешку с NTFS?

Psych218 ★★★★★
()
Ответ на: комментарий от Psych218

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

Sahas ★★★★☆
() автор топика
Ответ на: комментарий от Sahas

в дебрях этого монстра ковыряться

в первую очередь, проверь как там mmap себя чухает

ananas ★★★★★
()
Ответ на: комментарий от ananas

а ты заметил в коде mc хоть какую-то сепарацию по платформам?

конкретно в месте копирования файлов - нет, а так не знаю

в первую очередь, проверь как там mmap себя чухает

ну, вроде как, источник проблем известен - GlusterFS пытается распараллелить операции чтения/записи, но это, видимо, вносит некоторый overhead на каждую операцию чтения/записи, из-за чего при работе с малыми объёмами и происходит «торможение». Если эту опцию отключить, то копирование выполняется так же быстро, как и раньше

Sahas ★★★★☆
() автор топика

Кстати, а кто из более-менее активных разработчиков mc остался на ЛОРе?

Sahas ★★★★☆
() автор топика
Последнее исправление: Sahas (всего исправлений: 1)
7 мая 2016 г.

Попробовал увеличить этот буфер в десять раз: на обычном винте с ext4 быстрее не стало, но нагрузка на процессор упал примерно в 5 раз.

MihailZenkov
()
Ответ на: комментарий от MihailZenkov

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

Sahas ★★★★☆
() автор топика

Я сделал себе 2М и скорость копирования больших файлов возросла почти на 2 порядка :)

Лгешь ведь. Буферизация давно выполняется ядром.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Лгешь ведь.

нет

Буферизация давно выполняется ядром.

дело не в ней, во-первых. Во-вторых, я про другой буфер говорю (залезь в код mc и сам посмотри, что там за буфер).

Sahas ★★★★☆
() автор топика
Ответ на: комментарий от Sahas

Буферизация давно выполняется ядром.

дело не в ней, во-первых.

Судя по

Sahas> с некоторых пор

дело именно в ней (если дело вообще есть).

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Вот интересно: ты, толком не разобравшись с вопросом, полез в обсуждение, где уже даже приведена ссылка на ticket (более того, обсуждаемый недостаток уже устранён разработчиками mc) и начал кидать какие-то непонятные и в целом огульные оскорбления?..

http://www.midnight-commander.org/ticket/3624

http://www.midnight-commander.org/ticket/2193

Sahas ★★★★☆
() автор топика
Ответ на: комментарий от Sahas

Я полез сказать, что дело в кэшировании ядром и, судя по тикетам, я прав. Ну и в увеличение скорости на 2 порядка я до сих пор не верю.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ну и в увеличение скорости на 2 порядка я до сих пор не верю.

Так речь идёт о GlusterFS. Это распределённая ФС, работающая через fuse. По какой причине появились тормоза на ней — хз, но факт остается: увеличение буфера кардинально улучшает скорость (да, на 2 порядка — с 1 мб/с до 100 мб/с)

Sahas ★★★★☆
() автор топика
Ответ на: комментарий от Sahas

По какой причине появились тормоза на ней — хз, но факт остается

Надеюсь, ты зарепортил баг и на GlusterFS тоже.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

это не похоже на баг GlusterFS, поскольку операция копирования при помощи cp выполняется так же быстро, как и раньше. Так что скорее это недостаток mc. Залезь в код да посмотри: mc читает в буфер часть файла, а потом делает кучу разных действий (связанных с прогресс-баром и, возможно, ещё чем-то). Видимо, частая «остановка» в чтении файла и приводит к проседанию скорости и излишней нагрузке на процессор.

Sahas ★★★★☆
() автор топика
Ответ на: комментарий от Sahas

Видимо, частая «остановка» в чтении файла и приводит к проседанию скорости и излишней нагрузке на процессор.

К большей нагрузке на ЦП - естественно, для задачи требуется больше системных вызовов. А на кэширование влиять не должно (и на ext4 не влияет).

tailgunner ★★★★★
()

Почему копирование файлов из архивов .tgz так ужасно лагает, особенно когда много мелких файлов?? tar xvzf file.tgz исполняется в 10-30 раз быстрее. Неужели за столько лет никто так и может починить?

anonymous
()
Ответ на: комментарий от post-factum

write-behind включен?

да. Не уверен, что именно эта опция всему виной (поскольку не я занимаюсь настройкой GlusterFS), но отключение многопоточной записи в GlusterFS ведёт к ускорению копирования в mc до нормального уровня.

Sahas ★★★★☆
() автор топика
Ответ на: комментарий от Sahas

P. S. GlusterFS себя вообще плохо ведёт, если, например, на один файл делать append в несколько потоков. Мы так логи на него пытались напрямую писать, но ничего хорошего не получилось, даже учитывая, что трафик этих логов — пара килобайт в минуту.

post-factum ★★★★★
()
Ответ на: комментарий от post-factum

Это какая опция?

вот этого я как раз не знаю. Знаю только, что при этом GlusterFS пишет многопоточно (что хорошо, когда сразу может много файлов записываться разными программами, как в нашем случае).

Sahas ★★★★☆
() автор топика
Ответ на: комментарий от Sahas

Или это performance.client-io-threads, или я чего-то не знаю. Однако, при использовании performance.client-io-threads бывают заскоки на клиенте, так что её обычно отключают.

post-factum ★★★★★
()
Ответ на: комментарий от post-factum

Думаю, это оно, поскольку опция performance.client-io-threads включена. Заскоки может и есть, но без неё всё очень печально при одновременной записи несколькими приложениями, что для нас весьма существенно (GlusterFS используется на вычислительном кластере)

Sahas ★★★★☆
() автор топика
Ответ на: комментарий от Sahas

С этой опцией раньше (на самой последней версии не тестил) клиент вис на rsync'е. Не сразу, но гарантированно вис. Поэтому, я её благополучно отключил и больше не использовал. Хотя по-хорошему нужно опять потестить и накатать багрепорт.

post-factum ★★★★★
()
Ответ на: комментарий от post-factum

rsync пользуемся не так часто, но, вроде, зависаний замечено не было... Версия Gluster 3.7.8

Sahas ★★★★☆
() автор топика
Ответ на: комментарий от Sahas

Я на 3.7.6 тестил. Всё, за чем следил после 3.7.6, — это утечки памяти, которые в основном были пофикшены.

post-factum ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.