Какая операция в linux происходит быстрее и требует меньше ресурсов

btrace позволяет наглядно посмотреть реальное количество записанных данных, но понять, какие именно программы совершают запись, из её вывода сложно.

Определение программ, производящих запись на накопитель

Программа iotop покажет процессы, пишущие на диск, и размер записанных данных.
Наиболее удобный вывод обеспечивают следующие параметры:

# iotop -obPat

Пример вывода программы

02:55:47 Total DISK READ : 0.00 B/s | Total DISK WRITE : 30.65 K/s 02:55:47 Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 0.00 B/s TIME PID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND b'02:55:47 753 be/4 root 0.00 B 0.00 B 0.00 % 0.04 % [dmcrypt_write/2]' b'02:55:47 788 be/4 root 72.00 K 18.27 M 0.00 % 0.02 % [btrfs-transacti]' b'02:55:47 15057 be/4 valdikss 216.00 K 283.05 M 0.00 % 0.01 % firefox' b'02:55:47 1588 ?dif root 0.00 B 0.00 B 0.00 % 0.00 % Xorg -nolisten tcp -auth /var/run/sddm/ -background none -noreset -displayfd 18 -seat seat0 vt1' b'02:55:47 15692 be/4 valdikss 988.00 K 9.41 M 0.00 % 0.00 % python3 /usr/bin/gajim' b'02:55:47 15730 ?dif valdikss 9.07 M 0.00 B 0.00 % 0.00 % telegram-desktop --' b'02:55:47 2174 ?dif valdikss 1840.00 K 2.47 M 0.00 % 0.00 % yakuake' b'02:55:47 19827 be/4 root 16.00 K 896.00 K 0.00 % 0.00 % [kworker/u16:7-events_unbound]' b'02:55:47 19074 be/4 root 16.00 K 480.00 K 0.00 % 0.00 % [kworker/u16:4-btrfs-endio-write]' b'02:55:47 19006 be/4 root 16.00 K 1872.00 K 0.00 % 0.00 % [kworker/u16:1-events_unbound]' b'02:55:47 1429 be/4 root 484.00 K 0.00 B 0.00 % 0.00 % accounts-daemon' b'02:55:47 15820 be/4 valdikss 312.00 K 0.00 B 0.00 % 0.00 % firefox -contentproc -childID 6 -isForBrowser -prefsLen 7894 -prefMapSize 223880 -parentBuildID 20191022164834 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 15057 tab' b'02:55:47 2125 ?dif valdikss 0.00 B 92.00 K 0.00 % 0.00 % plasmashell' b'02:55:47 1268 be/3 root 0.00 B 4.00 K 0.00 % 0.00 % auditd' b'02:55:47 1414 be/4 root 0.00 B 4.00 K 0.00 % 0.00 % sssd_nss --uid 0 --gid 0 --logger=files' b'02:55:47 15238 be/4 valdikss 0.00 B 4.00 K 0.00 % 0.00 % thunderbird' b'02:55:47 18605 be/4 root 0.00 B 3.19 M 0.00 % 0.00 % [kworker/u16:0-btrfs-endio-write]' b'02:55:47 18867 be/4 root 0.00 B 96.00 K 0.00 % 0.00 % [kworker/u16:5-btrfs-endio-meta]' b'02:55:47 19070 be/4 root 0.00 B 160.00 K 0.00 % 0.00 % [kworker/u16:2-btrfs-freespace-write]' b'02:55:47 19645 be/4 root 0.00 B 2.17 M 0.00 % 0.00 % [kworker/u16:3-events_unbound]' b'02:55:47 19982 be/4 root 0.00 B 496.00 K 0.00 % 0.00 % [kworker/u16:6-btrfs-endio-write]'

В глаза бросается Firefox, записавший 283 мегабайта за несколько минут работы iotop.

Определение файлов, в которые производится запись

Информация о процессе, насилующим диск — хорошо, а пути, по которым производится запись — еще лучше.

Воспользуемся программой fatrace , которая отслеживает изменения файловой системы.

# fatrace -f W

Пример вывода программы

firefox(15057): CW /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite-wal firefox(15057): CW /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal firefox(15057): CW /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/usage-journal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/usage firefox(15057): CW /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/usage firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite-wal firefox(15057): CW /home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/https+++habr.com/ls/data.sqlite-journal firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite firefox(15057): W /home/valdikss/.mozilla/firefox/xyf4vqh2.default/webappsstore.sqlite

Fatrace не умеет показывать количество записанных данных вследствие использования довольно простого отслеживания факта обращения к файлам через inotify.

Из вывода видно, как хабр сохраняет мою статью в local storage браузера, пока я её пишу, а также расширение Group Speed Dial, которое, как удалось обнаружить именно с помощью fatrace, читает свои данные каждые 30 секунд. Именно читает, а не записывает: CW перед файлом говорит о том, что файл открывается на чтение и запись, с одновременным созданием файла, если он отсутствует (вызывается openat с флагом O_RDWR|O_CREAT), но не говорит, что в файл действительно писалась какая-либо информация.

На всякий случай, чтобы удостовериться в этом, воспользуемся strace, с фильтром на файловые системные вызовы:

strace -yy -e trace=open,openat,close,write -f -p 15057 2>&1 | grep extension

Вывод команды

[pid 20352] openat(AT_FDCWD, "/home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 153 [pid 20352] read(153, "SQLite format 3\0\20\0\2\2\0@ \0\0\0d\0\0\0\23". 100) = 100 [pid 20352] read(153, "SQLite format 3\0\20\0\2\2\0@ \0\0\0d\0\0\0\23". 4096) = 4096 [pid 20352] openat(AT_FDCWD, "/home/valdikss/.mozilla/firefox/xyf4vqh2.default/storage/default/moz-extension+++e5c304fb-af40-498a-9ba8-47eb0416e933^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite-wal", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 166 … [pid 20352] read(54, "\0\0\0\r\4\30\4\36\4\35\4\35\4\36\4-\0 \4\20\4!\4'\4\1\4\"\0250 &". 4096) = 4096 [pid 20352] read(54, "\0\0\0\0\1\36P\t\226\250\4\0O\245\320\16:\"\16.\27\0r\245\306>\246\1\t\1q\370". 4096) = 4096 [pid 20352] close(77) = 0 [pid 20352] close(54) = 0

Нет ни одного вызова write() , что говорит об отсутствии записи в файл.

Определение накладных расходов файловой системы

Большая разница в показаниях iotop и btrace натолкнула на мысль протестировать файловую систему путем ручной записи данных в файл и отслеживания показаний btrace.

Если полностью исключить запись на диск, загрузившись в emergency-режим systemd, и записать вручную пару байт данных в существующий файл, btrace на SSD с btrfs сообщает о записи 3 мегабайт реальных данных. Свежесозданная файловая система флешке размером в 8 ГБ записывает минимум 264 КиБ при записи одного байта.
Для сравнения, запись пары байт в файл на ext4 оканчивается записью 24 килобайтов данных на диск.

В 2017 году Jayashree Mohan, Rohan Kadekodi и Vijay Chidambaram провели исследование усиления записи разных файловых систем, их результаты для btrfs и ext4 при записи 4 КБ соотносятся с моими.

Заключение и вывод

1. Частая запись состояний заданий для принтера демоном печати CUPS в /var/cache/cups каждую минуту. Проблема устранена очисткой /var/spool/cups (хотя никаких заданий печати не было);
2. Факт чтения базы данных каждые 30 секунд расширением Group Speed Dial для Firefox;
3. Периодическая запись журналов различными сервисами отслеживания производительности в Fedora, что приводило к записи нескольких мегабайт данных на btrfs: pmcd.service, pmie.service, pmlogger.service;
4. Огромная амплификация при записи небольшого количества данных при использовании btrfs.

Какая операция в linux происходит быстрее и требует меньше ресурсов

Подсистема работы с оперативной памятью в Linux - достаточно многогранная конструкция. Чтобы разобраться в её деталях нужно целенаправленно погрузиться в тему, с обязательным чтением исходников ядра, но это нужно не каждому. Для разработки и эксплуатации серверного программного обеспечения важно иметь хотябы базовое предстваление о том, как она работает, но меня не перестает удивлять насколько небольшая доля людей им обладает. В этом посте я постараюсь кратко пробежаться по основным вещам, без понимания которых на мой взгляд очень легко натворить глупостей.

Какая бывает память?

Физическая и виртуальная

Начнем издалека. В спецификации любого компьютера и в частности сервера непременно числится надпись "N гигабайт оперативной памяти" - именно столько в его распоряжении находится физической памяти.

Задача распределения доступных ресурсов между исполняемым программным обеспечением, в том числе и физической памяти, лежит на плечах операционной системы, в нашем случае Linux. Для обеспечения иллюзии полной независимости, она предоставляет каждой из программ свое независимоевиртуальное адресное пространство и низкоуровневый интерфейс работы с ним. Это избавляет их от необходимости знать друг о друге, размере доступной физической памяти и текущей её занятости. Адреса в виртуальном пространстве процессов называют логическими.

Для отслеживания соответствия между физической и виртуальной памятью ядро Linux использует иерархический набор структур данных в своей служебной области физической памяти (только оно работает с ней напрямую), а также специализированные аппаратные контуры, которые в совокупности называют MMU .

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

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

Файловая и анонимная

У приложений существует много способов выделить себе память для тех или иных нужд. Высокоуровневые языки программирования и библиотеки часто прячут от разработчиков какой из них в реальности использовался и другие детали (хотя их всегда можно "раскусить" с помощью strace ). Если углубляться в особенности каждого доступного варианта, эта статья быстро бы превратилась в книгу. Вместо этого предлагаю разделить их на две, на мой взгляд, крайне важные группы по тому, какую память они выделяют:

• Файловой памяти однозначно соответствует какой-либо файл или его часть в файловой системе. Первым делом в ней как правило находится исполняемый код самой программы. Для прикладных задач можно запросить отображение файла в виртуальное адресное пространство процесса с помощью системного вызова mmap - после чего с ним можно работать как с любой другой областью памяти без явного чтения/записи, что будет при этом происходить с данными в файловой системе и что будут видеть другие процессы "отобразившие" этот же файл зависит от настроек.
• Любую другую выделенную память называют анонимной, так как ей не соответствует никакой файл, которые как известно именованы. Сюда попадают как переменные на стеке, так и области, выделенные с помощью функций вроде malloc (к слову, за сценой для выделения больших блоков памяти они обычно тоже используют mmap с особым набором настроек, а для всего остального - brk/sbrk или выдают ранее освобожденную память).

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

Вытесняемая и нет

Суммарный объем используемой виртуальной памяти всех программ запросто может превышать объем доступной физической памяти. При этом в каждый конкретный момент времени приложениями может использоваться лишь небольшое подмножество хранимых по виртуальным адресам данных. Это означает, что операционная система может откладывать не используемые в данный момент данные из оперативной памяти на жесткий диск ("вытесняя"" их из памяти), а затем при попытке к этим данным обратиться - скопировать обратно в физическую оперативную память. Этот механизм официально называется major page fault, но под просто page fault как правило подразумевают тоже её, так как minor page fault мало кого заботит (отличие в том, что в случае minor ядру удается найти запрашиваемые данные уже загруженными в память с какой-то другой целью и обращения к диску в итоге не происходит).

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

• Прочитать 4Кб данных с обычного серверного жесткого диска 7200rpm занимает порядка 10 мс, при хорошем стечении обстоятельств чуть меньше.
  • Если вытесненных страниц оказывается много, запросто могут набегать заметные доли секунды (как условным пользователям, так и на внутренних приборах, в зависимости от задачи).
  • Особенно опасны циклические pagefaults, когда есть две или более регулярно используемые области памяти, которые вместе не помещаются в физическую память, по-этому бесконечно вытесняют друг друга туда-обратно.
  • При этом диск вынужден делать честный seek, что само по себе тоже может быть не кстати. Например, если с этим же диском работает какая-либо база данных.

  Стоит отметить, что с точки зрения приложения всё это прозрачно и является внешним воздействием, то есть может происходить в самый не подходящий, с точки зрения решаемой им задачи, момент.

  Думаю понятно, что приложения, которым важна высокая производительность и стабильное время отклика, должны избегать pagefault'ов всеми доступными методами, к ним и перейдем.

  Методы управления подсистемой памяти

  swap

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

  С анонимной памятью такой трюк не работает: ей не соответствует никакой файл, по-этому чтобы данные не пропали безвозвратно, их нужно положить куда-то ещё. Для этого можно использовать так называемый "swap" раздел или файл. Можно, но на практике не нужно. Если swap выключен, то анонимная память становится невытесняемой, что делает время обращения к ней предсказуемым.

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

  mlock

  По-умолчанию вся файловая память является вытесняемой, но ядро Linux предоставляет возможность запрещать её вытеснение с точностью не только до файлов, но и до страниц внутри файла.

  Для этого используется системный вызов mlock на области виртуальной памяти, полученной с помощью mmap . Если спускаться до уровня системных вызовов не хочется, рекомендую посмотреть в сторону консольной утилиты vmtouch , которая делает ровно то же самое, но снаружи относительно приложения.

  Несколько примеров, когда это может быть целесообразно:

  • У приложения большой исполняемый файл с большим количеством ветвлений, некоторые из которых срабатывают редко, но регулярно. Такого стоит избегать и по другим причинам, но если иначе никак, то чтобы не ждать лишнего на этих редких ветках кода - можно запретить им вытесняться.
  • Индексы в базах данных часто физически представляют собой именно файл, с которым работают через mmap , а mlock нужен чтобы минимизировать задержки и число операций ввода-вывода на и без того нагруженном диске(-ах).
  • Приложение использует какой-то статический словарь, например с соответствием подсетей IP-адресов и стран, к которым они относятся. Вдвойне актуально, если на одном сервере запущено несколько процессов, работающих с этим словарем.

  OOM killer

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

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

  cgroups

  По-умолчанию все пользовательские процессы наравне претендуют на почти всю физически доступную память в рамках одного сервера. Это поведение редко является приемлемым. Даже если сервер условно-однозадачный, например только отдает статические файлы по HTTP с помощью nginx, всегда есть какие-то служебные процессы вроде syslog или какой-то временной команды, запущенной человеком. Если же на сервере одновременно работает несколько production процессов, например, популярный вариант - подсадить к веб-серверу memcached, крайне желательно, чтобы они не могли начать "воевать" друг с другом за память в случае её дефицита.

  Для изоляции важных процессов в современных ядрах существует механизм cgroups , c его помощью можно разделить процессы на логические группы и статически сконфигурировать для каждой из групп сколько физической памяти может быть ей выделено. После чего для каждой группы создается своя почти независимая подсистема памяти, со своим отслеживанием вытеснения, OOM killer и прочими радостями.

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

  Но на мой взгляд именно контроль за потреблением памяти - самый необходимый минимум, который определенно стоит настроить, остальное уже по желанию/необходимости.

  NUMA

  В многопроцессорных системах не вся память одинакова. Если на материнской плате предусмотрено N процессоров (например, 2 или 4), то как правило все слоты для оперативной памяти физически разделены на N групп так, что каждая из них располагается ближе к соответствующему ей процессору - такую схему называют NUMA .

  Таким образом, каждый процессор может обращаться к определенной 1/N части физической памяти быстрее (примерно раза в полтора), чем к оставшимся (N-1)/N .

  Ядро Linux самостоятельно умеет это всё определять и по-умолчанию достаточно разумным образом учитывать при планировании выполнения процессоров и выделении им памяти. Посмотреть как это все выглядит и подкорректировать можно с помощью утилиты numactl и ряда доступных системных вызовов, в частности get_mempolicy / set_mempolicy .

  Операции с памятью

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

  • Операции, работающие с памятью:
    • В большинстве своем не атомарны (то есть другой поток может их "увидеть" на полпути), без явной синхронизации атомарность возможна только для блоков памяти не больше указателя (т.е. как правило 64 бита) и то при определенных условиях.
    • В реальности происходят далеко не всегда в том порядке, в котором они написаны в исходном коде программы: процессоры и компиляторы на правах оптимизации могут менять их порядок, как считают нужным. В случае многопоточных программ эти оптимизации часто могут приводить к нарушению логики их работы. Для предотвращения подобных ошибок разработчики могут использовать специальные инструменты, в частности барьеры памяти - инструкции, которые запрещают переносить операции с памятью между частями программы до неё и после.

    Итого

    Подсистему памяти в Linux нельзя бросать на произвол судьбы. Как минимум, стоит следить за следующими показателями и вывести на приборы (как суммарно, так и по процессам или их группам):

    • Скорость возникновения major page faults;
    • Срабатывания OOM killer;
    • Текущий объем использования физической памяти (это число обычно называют RSS , не путать с одноименным форматом для публикации текстового контента).

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

    • Статья написана с ориентиром на современные Debian-like дистрибутивы Linux и физическое оборудование с двумя процеcсорами Intel Xeon. Общие принципы ортогональны этому и справедливы даже для других операционных систем, но вот детали могут сильно разниться даже в зависимости от сборки ядра или конфигурации.
    • У большинства упомянутых выше системных вызовов, функций и команд есть man , к которому рекомендую обращаться за подробностями об их использовании и работе. Если под рукой нет linux-машины, где можно набрать man foo - они обычно легко ищутся с таким же запросом.
    • Если есть желание углубиться в какую-либо из затронутых вскользь тем - пишите об этом в комментариях, любая из них может стать заголовком отдельной статьи.

    P.S.

    На последок ещё раз повторю цифры, которые настоятельно рекомендую запомнить:

    • 0.0001 мс (100 нс) - обращение к оперативной памяти
    • 0.1-1 мс (0.1-1 млн. нс) - обращение к SSD при major pagefault, на 3-4 порядка дороже
    • 5-10 мс (5-10 млн. нс) - обращение к традиционному жесткому диску при pagefault, ещё на порядок дороже

    // мс - миллисекунды, нс - наносекунды.

    Linux использует меньше оперативной памяти, чем Windows?

    

    Linux — отличный способ вдохнуть новую жизнь в старую машину. Зачем? Поскольку большинство дистрибутивов Linux предъявляют более низкие системные требования, чем Windows, операционная система установлена ​​на большинстве ПК, продаваемых в магазинах. Linux обычно меньше нагружает процессор вашего компьютера и не требует много места на жестком диске. Но как насчет оперативной памяти?

    Это зависит. Windows и Linux могут использовать ОЗУ не одинаково, но в конечном итоге они делают то же самое. Итак, чтобы ответить на этот вопрос, давайте сначала разберем, что такое оперативная память.

    Что такое оперативная память?

    RAM (оперативное запоминающее устройство) — это область вашего компьютера, которая позволяет записывать и читать файлы в короткие сроки. Эти данные физически отделены от файлов на жестком диске, и чип часто быстрее по физическим и механическим причинам. В отличие от вашего жесткого диска, RAM не хранит данные, когда нет питания. Когда вы перезагружаете компьютер, ОЗУ становится пустым. Компьютеры используют оперативную память для временного хранения, пространство для создания данных, которые должны быть доступны быстро и часто.

    

    Не все ОЗУ одинаково. Есть два типа: DRAM и SRAM. DRAM обеспечивает время доступа около 60 наносекунд. SRAM сокращает это число до 10. Таким образом, 4 ГБ SRAM будут быстрее, чем 4 ГБ DRAM, но вы все равно часто будете использовать DRAM, потому что это значительно дешевле.

    Но какой операционной системе нужно больше оперативной памяти?

    Системные Требования

    Windows 10 требует 2 ГБ оперативной памяти, но Microsoft рекомендует иметь как минимум 4 ГБ. Давайте сравним это с Ubuntu, самой известной версией Linux для настольных компьютеров и ноутбуков. Canonical, разработчик Ubuntu, рекомендует 2 ГБ оперативной памяти .

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

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

    Но сравнение чисел это только часть истории. Существует больше понимания RAM, чем уверенность в том, что у вас достаточно компьютера для работы.

    Как работает RAM

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

    Быстрый веб-браузер может загрузить веб-страницу за считанные секунды. Но независимо от того, насколько он хорош при загрузке битов через Интернет, он может работать лучше, если эта информация уже хранится на вашем ПК. Такие приложения, как Google Chrome и Mozilla Firefox, могут загружать сайты быстрее, кэшируя те, которые вы посетили в оперативной памяти. Все, что пользователь должен видеть, это более быстрое время загрузки.

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

    Ваши приложения — не единственные фрагменты кода, которые используют оперативную память как быстрое место для хранения временных файлов. Операционная система сама должна иметь доступ к этой части вашего компьютера тоже. Чем больше оперативной памяти требуется вашей ОС, тем меньше места для программ. Вот почему Windows предъявляет более высокие системные требования — в ней больше компонентов, пытающихся использовать оперативную память в любой момент времени. Достаточно взглянуть на все, что происходит в меню «Пуск» Windows на новой машине. Затем подумайте, как на заднем плане происходит еще больше, чего вы не можете видеть.

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

    

    Преимущество Linux

    Сила Linux не в волшебной способности заставить ваш компьютер запускать одни и те же приложения, используя меньше памяти. Веб-браузер в Linux будет жрать ГБ ОЗУ так же, как в Windows.

    Чтобы получить больше оперативной памяти в Windows, у вас есть несколько ограниченных вариантов. Вы можете уменьшить количество программ, в том числе фоновых, работающих одновременно, или получить больше оперативной памяти. Чтобы сделать последнее по дешевке, вы можете использовать ReadyBoost, чтобы превратить USB-накопитель во временную оперативную память.

    Вы можете делать это в Linux, но это только начало. Для начала, вы можете попробовать перейти с относительно ресурсоемкого рабочего стола Ubuntu по умолчанию на альтернативу, которая намного экономит ресурсы Есть сотни других дистрибутивов на выбор, и довольно много целевых старых машин, которые поставляются с гораздо меньшим объемом оперативной памяти.

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

    Даже если вы отказываетесь от установки нового дистрибутива или другой среды рабочего стола, вы все равно можете уменьшить нагрузку на свое оборудование, выбрав одно из множества легких приложений, доступных для Linux Это то, что вы также можете сделать в Windows, используя те же приложения, но запуск легких приложений в среде с тяжелым рабочим столом только поможет вам.

    Так что использует меньше?

    Если у вас есть машина с 512 МБ ОЗУ, вы захотите использовать Linux . Существует множество дистрибутивов и настольных сред, в которых ваш компьютер будет машина. Но есть определенные задачи, интенсивно использующие ОЗУ, которые будут выполняться медленно, и, к сожалению, просмотр веб-страниц является одним из них.

    Есть много дистрибутивов Linux, которые используют меньше оперативной памяти, чем Windows 10, но есть и другие, которые не так уж и менее нужны. При таком большом количестве выбора это решение действительно определяет объем используемой оперативной памяти. Вы не можете сделать предположение, что только потому, что вы используете рабочий стол Linux, вы используете меньше оперативной памяти. Хотя есть довольно хороший шанс, что ты есть.

    Сколько оперативной памяти в вашем компьютере? Вы используете Windows или Linux? Каков твой опыт? Звоните ниже и дайте нам знать!

    Похожие публикации:

    1. Initstate flutter statefull как сделать
    2. Как добавить файл в gitlab
    3. Как скрыть страницу на тильде
    4. Не ломайся как отечественный автопром