Как быстро записать на диск в одном потоке?

Question

[Eugene Usachev]

Есть программа, каждые n времени происходит дамп огромного буфера на диск. Сложность в том, что я хочу, чтобы программа не особо замечала этот дамп.

Как сейчас работает программа: она собирает из огромного буфера данные в малый буфер до его заполнения и дампает на диск, и так пока не пройдёт по всему огромному буферу (происходит копирование). Я запускаю её в один поток и полностью нагружаю одно ядро. Однако я заметил, что из 10 секунд на дамп + копирование в малый буфер, я трачу 7 секунд на сам дамп. Я могу распараллелить процесс на несколько файлов, но тогда мне нужно и несколько потоков (по-одному на файл).

Как я полагаю, большую часть времени я жду, пока диск прокрутиться до нужного файла, в этот момент программа с полным малым буфером ждёт и бездействует. Хотелось бы создать условно k файлов и писать в каждый по мере его доступа, чтобы один поток мог писать без остановки (порядок данных не важен). Существует ли готовое решение для этого и существует ли решение для записи, которое быстрее, чем стандартный

use std::fs::File;
use std::io::Write;
use std::{thread};
let mut output = File::create(path.clone()).expect(&*format!("failed to create file with path {}", path.clone()));
// some code
output.write(&*buf).expect("failed to write");

Comments

[Дмитрий Беляев]

А если вынести запись в файл в фоновый поток, куда мувать малый буфер через канал, а в основном потоке просто алоцировать новый малый буфер?

[Eugene Usachev]

Дмитрий Беляев, Не поспел за ходом вашей мысли. Не могли бы вы привести хотя бы схематичный код?

[Дмитрий Беляев]

Eugene-Usachev, что-то вроде такого:

use std::{fs::File, io::Write, mem, path::PathBuf, sync::mpsc, thread};

fn main() {
    let (tx, rx) = mpsc::channel::<Vec<_>>();
    let handle = thread::spawn(move || {
        let path = PathBuf::from("...");
        let mut output = File::create(&path).unwrap_or_else(|e| {
            panic!(
                "failed to create file with path {:?}: {:?}",
                path.as_os_str(),
                e
            )
        });
        loop {
            let Ok(buf) = rx.recv() else {
                break;
            };
            output.write(&buf).expect("failed to write");
        }
    });

    let big_buffer = get_big_buffer_input();
    let mut buf = Vec::with_capacity(1024);
    for byte in big_buffer {
        buf.push(byte);
        if buf.len() == buf.capacity() {
            let buf = mem::take(&mut buf);
            tx.send(buf).expect("failed to send buf");
        }
    }
    handle.join().unwrap();
}

fn get_big_buffer_input() -> impl Iterator<Item = u8> {
    todo!()
}

[Eugene Usachev]

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

[Дмитрий Беляев]

Eugene-Usachev, здесь идея в том, что основной поток не ждет записи на диск

Answer 1

[mayton2019]

Я могу распараллелить процесс на несколько файлов

Разпараллеливание записи на несколько файлов не имеет смысла для обычных десктопных дисков.
Это только в серверных системах хранения где RAID - такая оптимизация имела-бы смысл.

Чтоб оптимизировать запись (развязать ожидания рабочих потоков от потока записи) можно
создать кольцевой буфер записи и поручить его сброс отдельному потоку. Размер этого
кольца можно выбрать экспериментально. Я не очень понимаю зачем тебе нужен набор
буферов (больших и малых) это возможно часть алгоритма. Но я-бы избавился от ненужных
копирований внутри памяти если есть возможность.

Можно еще посмотреть какие возможности в Rust есть в части асинхронного I/O но я здесь не специалист
в расте насколько глубоко чтоб знать где это и как называется.

Comments

[Василий Банников]

Ну для асинхронного io есть tokio

[Griboks]

не имеет смысла для обычных десктопных дисков

А вы когда-нибудь пробовали сравнить? Лично у меня в аналогичной ситуации наблюдается выигрыш в 27 раз.

[mayton2019]

Griboks, надо изучить вашу конфигурацию и вашу задачу. Я писал ETL процессы (I/O bounded задача) и понятное дело что на моем десктопе с 1 HDD не было смысла повышать степень параллелизма дисковых операций. Процесс в 1 поток работал обычно быстрее чем процесс в 2-3-4 потока.

[Griboks]

mayton2019, я записывал много данных в несколько архивов на стареньком HDD 2010 года. Сначала использовал 1 поток, потом 8, затем 60 (это максимум для windows python). В результате время уменьшилось с ~30 минут до ~1 минуты.

Лично у меня сработало два нюанса (я писал на питоне):
1) драйвер файловой системы/операционной системы/диска эффективнее кэширует и записывает несколько поток, чем ручная программа
2) Не нужно использовать малый промежуточный буфер. Если на компьютере 16 Гб RAM, то и на буферы записи имеет смысл выделить ~ 10 Гб. Ну в крайнем случае 100 Мб на буфер.

[mayton2019]

Griboks, видимо у вас сработал эффект медленного поступления данных из источников. И имело смысл запускать 8 потоков. Да.

Файловая система вообще не обязана ничего писать до тех пор пока к ней не приходит
явный fsync. Где этот fsync стоит в вашем приложении - неизвестно. Но можно словить разные
эффекты от его применения. Слишком частые фиксации тоже вредны и это я ловил на запуске
записи логов в мультипоточке.

[Griboks]

mayton2019,
Нет, данные читались с SSD, затем обрабатывались в RAM. Тут сработал именно планировщик ос/фс. Идея в том, что умные дяди сами подбирают размер буфера и частоту fsync. А потоки исключительно, чтобы сообщить им о наличии данных (по сути, это дробление большой очереди на несколько малых).

[Eugene Usachev]

Василий Банников, имел возможность протестировать только на 6 ядрах, но на 6 ядрах обычный std::thread показал себя гораздо лучше, чем tokio. Причём я тестировал как и 6 потоков (в этом случаи логично, что std::thread быстрее), так и на 2048 потоков (и даже тут std::thread оказался гораздо быстрее). Я был бы рад узнать, почему все рекомендуют использовать tokio, вместо std.

[mayton2019]

Eugene-Usachev, был такой интересный проект Loom для Java. Вобщем была идея,
сохранив исходный код в виде классической мультизадачности на базе Thread, использовать
потоки на базе корутин или фиберов (я уж не помню точно). Сейчас он релизнулся или нет я не знаю.
Он как раз дает возможность запускать большое число потоков (2048) (которые в основном стоят в ожидании
какого-то события) но при этом не потребляют потоков ОС и не преключают контекст потока ОС каждые 20мс
как это делает линукс. Мне эта идея нравится. Она сохраняет структурное программирование
(вся бизнес логика в одном месте а не разбросана по всему коду как в асинхронщине).

В классическом (дефолтном) варианте даже 1000 потоков запускать - уже проблема. Т.к. они
ориентированы на интенсивные вычисления а не на ожидание событий notify или снятия локов.

[Eugene Usachev]

mayton2019, я тоже слышал про подобные различия, поэтому провёл 2 теста: в первом 2048 потоков писали по TCP, получали ответ и писали снова, во втором тесте каждый поток ждал 10 микросекунд, после чего писал по TCP, получал ответ и так N раз. В первом тесте std::thread показал себя много лучше (вплоть до 50% по скорости при меньшей нагрузке на процессор). Во втором тесте tokio и std::thread выдали одинаковые результаты, так что я предположил, что std::thread производительнее tokio, но std::thread::sleep много хуже, чем sleep из tokio. Не вижу смысла использовать tokio для повышения производительности. Но я не могу уверенно говорить, что на большем числе ядер ситуация останется такой же.