Открываются ли файлы процессами загружены в RAM?
Этот ответ приходит с опозданием и, возможно, не на 100% отвечает на первоначальный запрос. Тем не менее, базовую функцию можно получить с помощью специального апплета (используя его сейчас с 3.0, он также использовался в предыдущих версиях Cinnamon): Сетка рабочего пространства (2D) и переключатель .
Когда он активен и добавлен на панель, этот апплет фактически позволяет вам определять «реальную» сетку рабочего пространства (количество строк / количество столбцов) и предоставляет возможность «Использовать сочетания клавиш (Ctrl + Alt + Up / Down). ) »Для переключения строк рабочего стола». Если этот параметр отмечен, он фактически переопределяет ярлыки для «Toggle Expo» и «Toggle Scale» для переключения между рабочими пространствами (и вы сможете перемещать окна в рабочее пространство вверх / вниз с помощью CTRL + ALT + SHIFT + Up / Down ).
Обратите внимание, однако, что кажется возможным сохранить возможность иметь ярлыки для Expo / Scale, глядя на комментарии на странице апплетов.
Хорошо, так что просто заменив 'switch-to-workspace-up' и 'switch-to-workspace-down' на 'switch-to-workspace-11' и 'switch-to-workspace-12' в " applet.js »-файл, назначив им сочетания клавиш с помощью« горячих клавиш »в« системных настройках »и отметив опцию« Использовать сочетания клавиш (Ctrl + Alt + вверх / вниз) для переключения строк рабочего стола »в настройках апплета, все, что нужно Работа. Теперь я могу указать ярлыки для экспо / масштаб и отдельно перемещаться вверх / вниз. Отлично!
However when commands are being run, a copy of their files from the hard disk is put into the RAM,
Это неправильно (вообще ). Когда программа выполняется с (по execve (2)... ), процесс (, выполняющий эту программу, )меняет свое виртуальное адресное пространство и ядро переконфигурирует MMU для этой цели. Читайте также про виртуальную память . Обратите внимание, что прикладные программы могут изменять свое виртуальное адресное пространство, используя mmap (2)& munmap& mprotect (2 ), также используемые динамическим компоновщиком (. ] см. ld -linux (8)). См. также madvise (2)& posix _fadvise (2)& mlock (2).
Будущие ошибки страниц будут обрабатываться ядром для ленивой загрузки ()страниц из исполняемого файла. Читайте также о взбивании .
Ядро поддерживает большой кэш страниц . Читайте также про копируем -на -пишем . См. также упреждающее чтение (2).
OK, so what I wonder about is if the double life of a command, one on the hard disk, the other in the RAM is also true for other kind of files, for instance those who have no logic programmed, but are simply containers for data.
Для системных вызовов , таких как чтение (2)и запись (2)также используется кэш страницы. Если данные для чтения находятся в нем, дисковый ввод-вывод выполняться не будет. Если требуется дисковый ввод-вывод, прочитанные данные, скорее всего, будут помещены в кеш страницы. Таким образом, на практике, если вы дважды запустите одну и ту же команду, может случиться так, что физический ввод-вывод не будет выполняться на диск во второй раз (, если у вас есть старый вращающийся жесткий диск -, а не SSD -. ] вы можете это услышать; или внимательно наблюдайте за светодиодом жесткого диска ).
Я рекомендую прочитать такую книгу, как Операционные системы :Three Easy Pieces (, которую можно бесплатно загрузить, по одному файлу PDF на главу ), в которой все это объясняется.
См. также Linux Ate My RAM и выполните такие команды, как xosview, top, htopили cat /proc/self/mapsилиcat /proc/$$/maps(см. proc (5)).
ПС. Я ориентируюсь на Linux, но другие ОС также имеют виртуальную память и кеш страниц.
No. Хотя иметь гигабайты ОЗУ в наши дни — это фантастика, было время, когда ОЗУ было очень ограниченным ресурсом (я учился программированию на VAX 11/750 с 2 МБ ОЗУ), и единственной вещью в ОЗУ были активные исполняемые файлы и страницы данных активных процессов и файловых данных, которые находились в буферном кеше.
Буферный кеш был очищен, а страницы данных выгружены. И часто временами. Исполняемые страницы, доступные только для чтения, были перезаписаны, а таблицы страниц помечены, поэтому, если программа снова касалась этих страниц, они загружались из файловой системы. Данные были выгружены из свопа. Как было отмечено выше, библиотека STDIO подтягивала данные блоками и получала программой по мере необходимости: fgetc, fgets, fread и т.д.
С помощью mmap файл может быть отображен в адресное пространство процесса, как это делается с объектами разделяемой библиотеки или даже с обычными файлами. Да, у вас может быть некоторая степень контроля над тем, находится он в ОЗУ или нет (mlock), но это не так далеко (см. раздел кода ошибки mlock).
Нет, файл не считывается автоматически в память при его открытии. Это было бы ужасно неэффективно. sed, например, считывает свой ввод строка за строкой, как и многие другие инструменты Unix. Редко приходится хранить в памяти больше, чем текущая строка.
С awkто же самое. Он считывает запись за раз, что по умолчанию является строкой. Если вы храните часть входных данных в переменных, то это будет лишним, конечно 1 .
У некоторых людей есть привычка делать такие вещи, как
for line in $(cat file); do...; done
Поскольку оболочке придется полностью расширить $(cat file)подстановку команд перед запуском даже первой итерации цикла for, этот будет считывать всю fileв память (в память, используемую оболочкой, выполняющей цикл for). Это немного глупо, а также неэлегантно. Вместо этого следует
while IFS= read -r line; do...; done <file
Это будет обрабатывать fileстроку за строкой (, но читать Понимание "IFS= читать -r строку").
Построчная обработка файлов в оболочке требуется редко, так как большинство утилит в любом случае -ориентированы на строки (см. Почему использование цикла оболочки для обработки текста считается плохой практикой?).
Я работаю в области биоинформатики, и при обработке огромных объемов геномных данных я мало что смог бы сделать, если бы не хранил в памяти только те биты данных, которые были абсолютно необходимы. Например, когда мне нужно удалить биты данных, которые можно использовать для идентификации людей, из набора данных объемом 1 терабайт, содержащего варианты ДНК в файле VCF (, потому что этот тип данных не может быть обнародован ), я выполнять построчную обработку с помощью простой awkпрограммы (это возможно, поскольку формат VCF построчно -ориентирован ). Я не читаю файл в память, не обрабатываю его там и не записываю обратно! Если бы файл был сжат, я бы скармливал его через zcatили gzip -d -c, что, поскольку gzipвыполняет потоковую обработку данных, также не считывало бы весь файл в память.
Даже для форматов файлов, которые не ориентированы на строки, например JSON или XML, существуют потоковые синтаксические анализаторы, которые позволяют обрабатывать огромные файлы, не сохраняя их все в оперативной памяти.
С исполняемыми файлами все немного сложнее, так как общие библиотеки могут загружаться по требованию и/или использоваться совместно процессами (см. Загрузка общих библиотек и использование оперативной памяти , например ).
Кэширование — это то, о чем я здесь не упоминал. Это действие по использованию оперативной памяти для хранения часто используемых фрагментов данных. Файлы меньшего размера (, например исполняемые файлы ), могут кэшироваться ОС в надежде, что пользователь будет делать на них много ссылок. Помимо первого чтения файла, последующие обращения будут осуществляться к оперативной памяти, а не к диску. Кэширование, как и буферизация ввода и вывода, обычно в значительной степени прозрачно для пользователя, и объем памяти, используемый для кэширования, может динамически изменяться в зависимости от объема ОЗУ, выделенного приложениями и т. д.
1Технически, большинство программ, вероятно, считывают часть входных данных за раз,либо с использованием явной буферизации, либо неявно с помощью буферизации, которую выполняют стандартные библиотеки ввода-вывода, а затем представить этот фрагмент построчно в пользовательском коде. Гораздо эффективнее читать кратное размеру блока диска, чем, например. персонаж за раз. Однако размер этого фрагмента редко превышает несколько килобайт.