Оптимизация массовой записи на диск

У меня есть приложение C (VStudio 2010, win7 64bit), работающее на машине с двумя чипами xeon, что означает 12 физических и 24 логических ядра и 192 гигабайта оперативной памяти. РЕДАКТИРОВАТЬ: ОС - win7 (т.е. Windows 7, 64-разрядная версия).

Приложение имеет 24 потока (каждый поток имеет собственное логическое ядро), выполняющих вычисления и заполняющих различные части массивной структуры C. Структура, когда все потоки завершены (и все потоки идеально сбалансированы, поэтому они завершаются одновременно), составляет около 60 гигабайт.

(У меня есть контроль над настройкой оборудования, поэтому я собираюсь использовать 6 дисков по 2 ТБ с RAID 0, что означает, что физические ограничения на запись будут примерно в 6 раз выше средней скорости последовательной записи, или около 2 гигабайт в секунду.)

Каков наиболее эффективный способ получить это на диск? Очевидно, что время ввода-вывода превысит время вычислений. Из моих исследований по этой теме кажется, что write() (в отличие от fwrite()) — это правильный путь. Но какие еще оптимизации я могу сделать на стороне программного обеспечения, с точки зрения настройки размеров буфера и т. д. Может ли mmap быть более эффективным?


c io raid fwrite mmap
person PaeneInsula    schedule 09.12.2011    source источник
comment
пожалуйста, добавьте тег на языке, на котором вы хотите писать. Это поможет другим легко найти этот вопрос.   -  person Buddha    schedule 09.12.2011
comment
Сколько времени занимает вычисление?   -  person Martin James    schedule 09.12.2011
comment
Я вижу тег mmap. Это доступно для вашей системы?   -  person Jens Gustedt    schedule 09.12.2011
comment
Просто напишите это. Он будет быстро скопирован в кэш файловой системы с копированием из памяти в память. С которого он будет записан на диск спустя долгое время после выхода вашей программы. У вас много оперативной памяти.   -  person Hans Passant    schedule 09.12.2011
comment
Моя ошибка насчет mmap; Я не понимал, что это недоступно при использовании визуального c (которым я являюсь, а не С++). Вычисление занимает около 0,5 секунды.   -  person PaeneInsula    schedule 09.12.2011

Ответы (2)


arrow_upward
6
arrow_downward

Трудно судить, что лучше всего подходит для вашей ситуации.

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

Тогда у вас есть выбор между mmap и write. Это также зависит от операционной системы, которую вы используете. В Unix я бы попробовал и mmap, и pwrite. pwrite полезен, потому что каждый из ваших потоков может записывать в файл в желаемой позиции файла, не борясь за смещения файла.

mmap может быть полезен, потому что вместо того, чтобы делать копии в файловый кеш, ваши потоки будут писать непосредственно в файловый кеш. 60 ГБ, вероятно, слишком велики для mmap всего файла, поэтому каждому потоку, вероятно, потребуется свое собственное окно mmap для файла, которое он может перемещать.

В Windows вы, вероятно, захотите попробовать использовать перекрывающийся асинхронный ввод-вывод. Это можно сделать только с помощью вызовов Win32 API.

person Zan Lynx    schedule 09.12.2011
comment
В Windows есть эквивалент mmap (CreateFileMapping, MapViewOfFile), и он, вероятно, будет хорош по тем же причинам, что перечислил Зан. - person Adrian McCarthy; 09.12.2011
comment
И по тем же причинам (это то, что использует ОС) сопоставленные файлы также хорошо работают в Windows. Кроме того, Windows может отображать файл на сетевом диске. Раньше Unix не мог выполнять mmap поверх nfs — изменилось ли это? - person Martin Beckett; 10.12.2011

arrow_upward
8
arrow_downward

mmap() или ускорить mmap почти всегда лучший подход. ОС умнее тебя, пусть думает, что кешировать!

Вы не сказали, какая ОС, но в Linux безумие или эквивалентные подсказки повышения производительности действительно могут повысить производительность.

person Martin Beckett    schedule 09.12.2011
comment
+1, всегда, всегда позволяйте кому-то другому выделывать как можно больше деталей! - person Spencer Rathbun; 09.12.2011