4

Я заметил, что всякий раз, когда я копирую или перемещаю большие файлы с моего SSD, который я использую в качестве системного диска, на мой жесткий диск или на внешний жесткий диск или флэш-диск, график скорости, отображаемый Windows, всегда выглядит одинаково: скорость передачи начинается с 450 МБ / с и через несколько секунд падает до 90-130 МБ / с и остается стабильным до конца операции копирования / перемещения.

График скорости передачи

Это вызвало мое любопытство, поэтому я решил выяснить, что является причиной этого. Вот некоторые из моих мыслей:

Может быть, это фактическая скорость, с которой происходит передача

Сомнительно. Несмотря на то, что скорость 450 МБ / с соответствует номинальной скорости моего твердотельного накопителя, учитывая, что у меня также есть некоторые другие операции чтения / записи дисков, выполняемые в фоновом режиме, жесткий диск со скоростью 7200 об / мин не сможет справиться с этим, так как Скорость в 130 МБ / с, которую я получаю позже, - это тоже самое, что я могу ожидать от нее. Итак, куда же попадают дополнительные данные?

Дополнительные данные хранятся в кэш-памяти жесткого диска.

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

Дополнительные данные хранятся в оперативной памяти

Это имеет смысл. Моя RAM - единственная другая часть моей системы, которая может соответствовать скорости моего SSD, и у меня ее много. Давайте проверим эту теорию!

Я открываю диспетчер задач и смотрю на вкладку «Производительность». Использование памяти стабильно на уровне 3,7 ГБ. Затем я начинаю еще 15 ГБ передачи файлов. Использование памяти начинает расти и останавливается на 5,3 ГБ, так как скорость передачи падает до 130 МБ / с. Он остается неизменным до конца передачи файла (диалоговое окно передачи закрывается), а затем медленно возвращается к уровню 3,7 ГБ, который был до передачи.

Итак, моя последняя теория верна. Дополнительным подтверждением является тот факт, что дополнительная использованная память помечена как Modified

модифицированный ,

В чем смысл?

У меня вопрос, какова цель сделать это? Хотя я не против использовать часть моей оперативной памяти для передачи файлов, так как даже во время самой тяжелой из моих многозадачных сессий я никогда не видел, чтобы ее использование превышало 70%, в чем преимущество хранения 1,6 ГБ данных, которые вы выиграли не делать какую-либо обработку в вашей оперативной памяти?

Я не вижу никакой выгоды с точки зрения целостности данных, так как вы просто копируете файлы, и в случае сбоя питания ни ОЗУ, ни жесткий диск не будут особенно успешными в сохранении данных при передаче.

Я вижу преимущество в том, что исходный диск (SSD) быстро освобождается, поэтому, если другому процессу требуется выполнить много операций чтения / записи, он может сделать это без передачи файлов, препятствующей этому, но если это в таком случае, почему бы не пойти дальше и загрузить все 15 ГБ с максимальной скоростью в память?

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

Имейте в виду, что я не проверил это тщательно со съемными дисками, так как Windows может обращаться с ними по-другому, делая мой последний пункт недействительным.

2 ответа2

2

Почему при передаче файлов между дисками используется ОЗУ?

Потому что операции ввода-вывода (почти всегда) выполняются между периферийным устройством и оперативной памятью.
Таким образом, копирование файла - это две операции на диске: чтение (в ОЗУ) и запись (из ОЗУ).

Некоторые системы могут выполнять периферийные операции (и, следовательно, не требуют буфера в оперативной памяти). Я видел хост-адаптеры SCSI, которые могут выполнять передачу с диска на диск (без вовлечения ЦП и ОЗУ с использованием встроенного процессора и ОЗУ /FIFO). Я видел контроллеры DMA, которые могут выполнять передачу данных с периферии на периферию. Это исключения, а не правило или общее использование.

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

У меня вопрос, какова цель сделать это?

Исходные данные (считываемый / копируемый файл) должны считываться в ОЗУ просто потому, что это характер компьютерной архитектуры (в сочетании с использованием DMA).
В те времена, когда оперативной памяти было мало, а операционные системы были не такими сложными, типичным выбором было выполнение этих передач с использованием как можно меньшего размера буфера (например, только одного сектора или блока) или буфера, который оптимизировал бы скорость (например, мульти -сектор передачи).
В настоящее время с относительно большой памятью и сложными алгоритмами, типичная ОС будет пытаться использовать любую / всю свободную / неиспользуемую память для буфера для чтения этих исходных данных.

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

Обратите внимание, что этот кеш файлов по сути бесплатный; для получения этого кэша не потребовалось дополнительных операций ввода-вывода в ОС. Единственной ценой является поддержание каталога содержимого, которое можно компенсировать при попадании в кэш (и сохранить ввод-вывод перечитанного).


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


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

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

В операции записи (или копирования) современная ОС будет пытаться быть доступной пользователю, как только все операции записи будут по крайней мере поставлены в очередь (это означает, что они могут не завершиться).
Это облегчает многозадачность. Если вы хотите сделать что-то еще, что даже не связано с этим диском, почему вы должны ждать завершения операций на этом диске, чтобы сделать что-то еще?
Компромисс состоит в том, что вы должны быть образованным пользователем и понимать, что (устройства хранения) должны быть правильно размонтированы.

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


Заметка
Передача данных может не использовать буфер ОЗУ, если:
1. запрограммированный ввод / вывод (с использованием ЦП) выполняется как для операций ввода, так и для вывода,
А ТАКЖЕ
2. вход и выход имеют соответствующие скорости передачи данных и размеры передачи,
А ТАКЖЕ
3. оба устройства ориентированы на символы и не являются блочными. (Это исключило бы дисководы.)

Однако ОС редко выбирает использование запрограммированного ввода-вывода, когда доступно DMA или мастеринг шины, и вряд ли будет запрограммировано для обработки двойной сложности парной передачи ввода-вывода.

-1

Управление памятью Windows - сложная вещь. Как видите, у разных устройств разное поведение.

У разных операционных систем разное управление памятью.

Ваш вопрос был очень интересным. Я делюсь страницей MSDN, которая объясняет часть управления памятью в Windows и, более конкретно, "Mapped Files"

Это документация для разработчиков программного обеспечения, но Windows тоже программное обеспечение.

Одним из преимуществ использования ввода-вывода MMF является то, что система выполняет все передачи данных для него на страницах данных 4K. Внутренне все страницы памяти управляются менеджером виртуальной памяти (VMM). Он решает, когда страница должна быть выгружена на диск, какие страницы должны быть освобождены для использования другими приложениями, и сколько страниц может иметь каждое приложение из всего выделенного объема физической памяти. Поскольку VMM выполняет все операции дискового ввода-вывода одинаковым образом - считывание или запись в память по одной странице за раз - он был оптимизирован, чтобы сделать его максимально быстрым. Ограничение инструкций чтения и записи диска последовательностями из 4Кб страниц означает, что несколько меньших операций чтения или записи эффективно кэшируются в одну более крупную операцию, уменьшая количество перемещений головки чтения / записи жесткого диска. Чтение и запись страниц памяти за один раз иногда называют пейджингом и является общим для операционных систем управления виртуальной памятью.

К сожалению, мы не можем легко понять, как Microsoft реализует чтение / запись - это не с открытым исходным кодом.
Но мы знаем, что это очень разные ситуации:

From      To
==================
SSD       HDD
HDD       Busy SSD ??
NTFS      FAT
NTFS      ext4
Network   HDD
IDE0slave IDE0master // IDE cable support disk to disk transfer.
IDE       SATA // in this case you have separated device controllers.

Вы поняли ... Может быть жесткий диск, файловые системы могут отличаться (или могут быть одинаковыми)...

Например: команда dd в Linux копирует данные "побайтово" - это очень быстро (потому что головки обоих жестких дисков перемещаются синхронно), но если файловые системы различны (например, с разными размерами блоков) - скопированные данные не будут быть читабельным, потому что файловая система имеет другую структуру.

Мы знаем, что оперативная память намного быстрее, чем HDD. Поэтому, если нам нужно будет выполнить какой-то анализ данных (чтобы соответствовать выходной файловой системе), лучше будет хранить эти данные в ОЗУ.

Также представьте, что вы копируете файл напрямую из-в.
Что происходит, если вы перегружаете источник другими потоками данных? Как насчет пункта назначения?
Что делать, если у вас почти нет свободной оперативной памяти в этот момент?
...

Только инженеры Microsoft знают.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .