Далеко не все работающие на сегодняшний день компьютеры и ноутбуки имеют объём оперативной памяти, гарантированно перекрывающий потребности возложенных на них задач. Для ноутбуков среднего и нижнего ценовых сегментов типовой задачей может быть работа с большим количеством открытых вкладок браузера, для более дорогих ноутбуков или системных блоков — ресурсоёмкие игры, рендеринг, видеомонтаж, для серверов — базы данных и прочие требовательные к RAM задачи.
Когда RAM близка к заполнению, данные неактивных в данный момент приложений начинают выгружаться из неё на диск, в файл или раздел подкачки. Когда при запуске ещё одного приложения, открытии файла или вкладки браузера, потребуется срочно освободить нужный для этого действия объём оперативной памяти, пауза в работе компьютера может быть заметна, даже когда в системе стоит SSD. На HDD же, в случае запуска ресурсоёмкого приложения, подкачка может приостановить работу и на несколько десятков секунд. Кроме того, постоянная подкачка на SSD приводит к его ускоренному износу, что с учётом цены SSD, также не лучшее решение. Если типовые задачи вашего компьютера требуют в 2-3 раза больше оперативной памяти, чем стоит в системе, наилучшим решением будет её увеличение. Если установить больше памяти невозможно технически (самый, пожалуй, острый пример — нетбуки на процессоре Atom с максимально возможным объёмом RAM 2 Гб) — ресурсоёмкие задачи лучше перенести на более мощный аппарат, а этот использовать только для офисно-браузерных задач (отдать детям или родителям). В случае же менее значительной нехватки (в пределах половины имеющегося объёма RAM), есть возможность улучшить ситуацию.
В современных проприетарных операционных системах (Windows начиная с 10, Mac OS начиная с 10.9 Mavericks) сжатие данных в RAM является штатной функцией операционной системы. Так ли это в Linux? Оказывается, да, но с оговорками: оно встроенное, но не преднастроенное. Более того, бытует мнение, что оно может конфликтовать с гибернацией, что в особенности критично для ноутбука.
Прежде чем мы разберёмся, так ли это, давайте определимся, что есть что. Начнём с гибернации.
Что такое гибернация и для чего она нужна
Во время гибернации содержимое RAM сохраняется в специальном файле образа (которым вполне может служить файл или раздел подкачки), после чего компьютер выключается. После включения содержимое образа RAM переносится обратно в те же адреса оперативной памяти, после чего операционная система продолжает прерванную работу с того же места.
Все активные операции — архивация, воспроизведение музыки и видео, копирование файлов — после выхода из гибернации продолжаются штатно. Это важнейшее преимущество гибернации перед выключением. Если к этому добавить весомый выигрыш во времени, по сравнению с обычной загрузкой ОС (например, для MacBook Pro на процессоре Intel время загрузки системы и программ из списка автозагрузки может составлять до 3 минут, а время выхода из гибернации — до 15 секунд), польза подобной функции неоспорима.
Отдельным преимуществом этой технологии для ноутбука является возможность автоматически вводить ноутбук в гибернацию при закрытии крышки (закрыл, взял и пошёл).
Разумеется, не лишены такого удобства и пользователи Linux. В большинстве систем Linux этот пункт находится в графическом окне настроек системы (например, для Mint в разделе Настроек «Оборудование», значок «Управление питанием», как описано в статье).
Можно также напрямую воспользоваться файлом конфигурации, как указано там же, или чуть более подробно в статье. Кроме того, будет актуально включить (при наличии в вашем дистрибутиве Linux) гибридный спящий режим, Suspend + Hibrnate, чтобы до израсходования батареи иметь возможность более быстрого пробуждения (а после полной разрядки и подключения к розетке — обычного выхода из гибернации). Именно так, например, по умолчанию сконфигурированы Macbook: крышка закрыта — вход в гибридный сон. Батарея не села — при открытии крышки быстрый выход из сна, села — помедленнее из гибернации, отменили выход вручную — ещё более медленная загрузка.
С гибернацией мы определились. Вернёмся к сжатию содержимого RAM.
Способы сжатия данных RAM в Linux
Сжатие данных в оперативной памяти (в нашем случае — ZRAM или ZSwap) позволяет без потери быстродействия работать с объёмом данных, в полтора раза большим реального объёма оперативной памяти нашей системы, не вытесняя данные в подкачку на диске. Обе этих технологии вполне могут сосуществовать вместе (лично у меня включены обе и нареканий не вызывают). Как по мне, ZRAM несколько проще мониторить, поскольку она имеет фиксированный объём, часть которого занята текущими данными. В свою очередь, ZSwap постоянного объёма не имеет и представляет собой просто динамический кэш дисковой подкачки. Он сжимает данные подкачки и накапливает их в RAM, пока есть свободное место, чтобы затем сбросить на диск сжатым дискретным пакетом. Таким образом, время и объём подкачки на диск максимально сокращаются, но подкачка всё ещё выполняется. ZRAM же позволяет в пределах всего своего объёма (а это половина объёма RAM со средним коэффициентом сжатия 2) не использовать диск совсем.
Разумеется, сильно сжатое изображение в формате jpeg вряд ли сожмётся более, чем в 1,1 раза, в то время как текст можно сжать гораздо больше, чем в 2 раза. В среднем же, в подавляющем большинстве случаев, все эти разнородные данные в RAM занимают после сжатия от трети до половины исходного объёма, что и позволяет нам в итоге хранить в RAM данные, в полтора раза превышающие её физический объём.
Исходя из обсуждения, некоторые пользователи ранее имели незначительные нарекания к совместной работе ZRAM и ZSwap, однако более поздних нареканий к их совместной работе я не нашёл.
Наиболее ёмко и исчерпывающе различие технологий описано в статье — позволю себе процитировать:
«ZRAM — модуль ядра Linux, ранее известный как compcache. До версии ядра 3.14 находился в экспериментальной ветке, с 3.14 перемещён в основную. Суть его в том, что в оперативной памяти создаётся сжатый раздел подкачки (swap). Создавая swap в ОЗУ, мы тем самым хоть и уменьшаем объем доступной оперативной памяти, но тем не менее информация в оперативной памяти всегда хранится в несжатом виде. А при использовании ZRAM происходит следующее: как только системе начинает не хватать оперативной памяти, она начинает активно занимать swap, а так как swap у нас в оперативной-же памяти, то по факту система начинает просто сжимать информацию из оперативки и помещать ее в оперативку же.
Скорость работы ОЗУ всегда существенно выше чем дисковой подсистемы, а алгоритмы сжатия lzo и lz4 настолько быстры, что в итоге мы получаем существенное «увеличение» оперативной памяти за счет небольших процессорных издержек на архивацию. Таким образом, ZRAM позволяет разместить в оперативной памяти в несколько раз больше информации за счёт сжатия. Эта технология активно используется в Android, ТВ-приставках, ChromeOS, SteamOS и много где ещё. При использовании ZRAM, swap-раздел на диске необязателен. Это особенно полезно для SSD-накопителей, так как частые записи для них вредны.
ZSWAP — модуль ядра Linux, доступный с версии 3.11. Отличается от ZRAM тем, что использует существующий swap-раздел на диске, а в ОЗУ создаётся пул со сжатыми данными (кэшем). После того как пул до отказа забьётся сжатыми данными, он сбросит их в раздел подкачки и снова начнёт принимать и сжимать данные. Размер пула можно указать вручную, по умолчанию он динамический (то есть будет использовать всю доступную оперативку).
Реализация такого подхода позволяет, при возникновении необходимости сброса памяти в раздел подкачки, сократить ввод-вывод и повысить скорость работы системы в целом, за счет того, что по возможности избегается использование медленного носителя. Ценой сокращения ввода/вывода является увеличение нагрузки на процессор, который тратит дополнительные ресурсы на сжатие и распаковку данных. По утверждению разработчиков, в их конфигурации при компиляции ядра в ситуации когда происходит своппинг, выигрыш по объему ввода/вывода составил 76%, а время выполнения операции сократилось на 53%. При использовании ZSWAP задействуется раздел swap на диске, в ОЗУ хранится только сжатый кэш».
Следует помнить (ниже, в итогах тестирования, я особо отметил это наблюдение и для своей системы), что SSD (даже высокоскоростной M2, не говоря уже о SATA) не избавляет нас полностью от замедления и подвисаний системы во время подкачки, а лишь уменьшает время ожидания, пока система завершает подкачку, чтобы снова обеспечить нам комфортный и отзывчивый доступ к тому, с чем мы в данный момент работаем. Только zram и zswap, благодаря высокому быстродействию RAM, позволяет, не увеличивая объём оперативной памяти, нивелировать снижение быстродействия при подкачке в пределах полутора объёмов RAM. Небольшой выход за эти полтора объёма RAM мы вряд ли даже заметим (в самом крайнем случае перезапустим браузер и закроем несколько ненужных вкладок), но если на машине, с запасом подходящей для офисных задач, помимо Ворда и браузера нам потребуется Фотошоп, Автокад или пара виртуальных машин — либо запускаем их где-то ещё, либо перед их запуском закрываем браузер, либо набираемся терпения и ждём подкачку!
У каждого приложения имеются свои рекомендуемые системные требования. В случае необходимости их совместного использования они далеко не всегда будут одновременно нагружать процессор по максимуму (если это не сервер, то большую часть времени процессор будет максимально нагружать приложение, в окне которого вы работаете, а на все фоновые окна и процессы желательно просто иметь некоторый запас), а вот требования нужных в работе приложений к RAM сразу следует сложить. Таким образом, можно заранее определить порог комфортной работы, после которого будем считать нашу систему неподходящей для возложенного на неё круга задач — очевидно, что без zram это примерно 110-115% от объёма RAM, а после установки данной службы порог комфортной работы составит примерно 160-165% RAM, далее подкачку на диск уже будет сложно игнорировать.
Таким образом, Zram позволит, если не полностью, то в значительной мере, нивелировать как проблему с быстродействием при подкачке на HDD, так и проблему с повышенным износом SSD при подкачке.
Так насколько же обе технологии сжатия данных в RAM совместима с гибернацией? Давайте перейдём к совместной работе обеих служб.
Совместимость гибернации и ZRAM/ZSwap. Изучение проблемы
После небольшого изучения публикаций, посвящённых данному вопросу, выясняется, что в обсуждениях и статьях основное нарекание пользователей вызывает конфигурация дистрибутива Fedora, в которой по умолчанию после установки нет подкачки на диске, но есть zram. Подробно ситуация описана в статье, а обсуждается как на русскоязычных форумах, так и англоязычных.
Сама по себе подобная конфигурация подкачки нареканий не вызывает, но в ней отключена гибернация, пользу которой мы уже отметили выше. Пытаться использовать для гибернации zram, совершенно бессмысленно, так как данные хранятся в RAM, содержимое которой при отключении питания сразу же будет потеряно.
Конечно, для ноутбука также актуален гибридный спящий режим, в котором оперативная память остаётся включенной. И, пока не разрядилась батарея, ноутбук просыпается из спящего режима, а после разрядки — уже из гибернации. Если же, как описано в упомянутой статье, ограничиться только zram/zswap, после разрядки батареи выход из гибернации будет невозможен. В качестве исправления ситуации упомянутая статья предлагает создать файл подкачки для сохранения в него образа RAM при гибернации, а непосредственно перед гибернацией отключать zram, после чего включать заново при пробуждении системы. То есть запускать скрипт отключения zram при запуске команды входа в гибернацию, а скрипт включения — после выхода из неё. А учитывая необходимость подкачки на диск при отключении ZRAM, такая подготовка к гибернации может потребовать времени, в случае с HDD — до нескольких десятков секунд. На мой взгляд, в такой ситуации схема «закрыл-взял-пошёл», так удобная при гибернации ноутбука, для ноутбука с HDD будет существенно нарушена — ведь HDD, несмотря на автоматическую парковку головок при резком ускорении, не всегда может полностью компенсировать толчки во время активной работы (а подкачка — это очень активная работа!) и нередко получает при этом небольшие царапины поверхности магнитной головкой, что может быть фатально как для файлов, которым «не повезло» попасть под удар, так и постепенно для самого диска.
Попробуем проанализировать возможные варианты совместных настроек zram и гибернации.
Выбор конфигурации подкачки
Для начала отметим, что в случае с SSD файл подкачки технологически более оправдан, чем раздел, так как контроллер SSD может сам управлять его размещением и, как и со всеми прочими файлами, перемещать его фрагменты по менее изношенным областям SSD, чтобы равномерно вести запись на весь объём SSD для недопущения повышенного износа отдельных его областей. С разделом такая выборочная фрагментация средствами контроллера уже невозможна, а значит, фиксированная область пространства подкачки будет подвергаться большему износу и снижению срока службы. Тем не менее во время установки Linux при ручной разметке диска гораздо быстрее и удобнее создать выделенный раздел, просто отметив его как раздел подкачки. Все дальнейшие действия по его подготовке и внесению в файлы конфигурации (/etc/fstab) установщик Linux выполнит автоматически. При выборе разбивки по умолчанию пространство подкачки чаще всего также будет размещено в разделе, а не в файле. Например, в Linux Mint умолчания именно такие.
Что же касается размера подкачки, его следует настраивать с учётом рекомендаций.
При выборе возможной совместной конфигурации служб гибернации и zram, видится 3 наиболее явных варианта использования файла/раздела подкачки для гибернации:
1) Использование раздела подкачки только для гибернации, без подкачки, как описано в уже упомянутой статье. Вполне работоспособный вариант, если сценарий использования системы гарантированно не предполагает выхода за пределы полуторного объёма RAM. После переполнения RAM и доступной подкачки система попытается принудительно выгрузить часть программ без сохранения данных, используя службу Out-of-memory killer, хотя в некоторых случаях может просто зависнуть.
2) Параллельное использование раздела подкачки и для подкачки, и для гибернации, как это настроено у меня, согласно форуму или статье. Такой вариант конфигурации подразумевает и гибернацию, и аварийный резерв подкачки на случай переполнения zram.
3) На основе дальнейших (см. ниже) результатов тестирования конфигурации из п. 2, объединить оба подхода (сделать и раздел подкачки, и файл подкачки, а затем выбрать, что из них использовать только для подкачки, а что — только для гибернации), чтобы раздел или файл подкачки, куда сохраняется содержимое RAM при гибернации, не был задействован для подкачки и всегда был доступен в нужном для гибернации объёме. Дополнительное преимущество такой конфигурации в том, что в случае использования для подкачки файла, а для гибернации — раздела подкачки, файл будет использоваться намного интенсивнее, при этом контроллер SSD вполне сможет его перемещать по разделу, чтобы исключить повышенный износ участка SSD, в котором этот файл содержится.
Тестовая конфигурация
Zram
Рассмотрим, как именно заняты память и подкачка после подключения zram.
На моей рабочей системе Linux Mint 21.2 Victoria при установке я разметил раздел подкачки 8 Гб, что в 2 раза больше объёма RAM. Фактически доступная RAM составляет 3,8 Гб (остальное выделено встроенному в процессор видеоконтроллеру). Виртуальный раздел zram (согласно выводу swapon -s) имеет имя /dev/zram0 и объём 1844812 байт, то есть занимает половину RAM (см. скриншот ниже).
На скриншоте полностью задействован раздел zram и частично использован раздел подкачки. Скриншот без нагрузки я делать не стал. После загрузки ОС оперативная память занята чуть более, чем на четверть, нагрузка же на скриншоте соответствует 28 открытым (и полностью загруженным) вкладкам firefox.
По моим более ранним наблюдениям, после подключения zram/zswap до начала вытеснения данных из RAM в подкачку на диске (вывод команды swapon -s, столбец Used>0) можно открыть примерно в полтора раза больше вкладок в Firefox, чем без zram/zswap. Это вполне соответствует ожидаемому двух- трёхкратному (в среднем, конечно, как уже отмечено выше) сжатию данных в разделе zram, занимающем половину RAM.
В соответствии с автоматической настройкой приоритетов пространств подкачки (колонка Priority на скриншоте, число меньше — приоритет выше), теперь SSD не будет задействоваться для подкачки до использования полуторного объёма RAM, а значит, он будет участвовать в подкачке гораздо меньше и реже (да ещё и сжатыми пакетами zswap), что уже заметно снизит объём и частоту записи на SSD, а, значит, и его износ. Кроме того, в большинстве ситуаций zram/zswap работает со скоростью RAM, что в 10-40 раз (или в 5-20, если считать, что число операций чтения-записи в RAM удваивается при работе с разделом zram) выше скорости SSD, согласно измерениям, приведённым в статье, а значит, и потери быстродействия при перезаписи в zram отсутствуют, остаётся только время самого сжатия данных, но учитывая незначительно возросшую загрузку процессора, (наблюдаемый прирост загрузки менее 5%) оно не перекрывает выигрыша от производительности RAM). Конечно, при загрузке процессора более 90-95% (например, при архивации) быстродействие zram может снижаться, но при такой нагрузке и без zram общее снижение быстродействия будет по ощущениям аналогичным.
Подробные инструкции по настройке zram и zswap можно найти здесь и здесь.
Отмечу, что сам я использую значение параметра vm.swappiness = 85, то есть начинаю использовать подкачку, когда остаётся уже 85% свободной памяти, не дожидаясь её более полного заполнения. При скорости работы zram/zswap считаю это оправданной заблаговременной экономией оперативной памяти.
Также отметим, что более ранние версии zram для балансировки нагрузки между ядрами процессора создавали несколько разделов zram, по числу ядер процессора. Например, в установленной у меня более двух лет назад Linux Mint 20 Ulyana на виртуальной машине Parallels на Mac Mini с назначенными виртуальной машине двумя ядрами процессора Core i5 и 2 Гб выделенной RAM, служба zram по умолчанию создала 2 раздела: /dev/zram0 и /dev/zram1 по 507192 байт каждый, то есть по одному разделу на ядро (поток) процессора общим размером 50% от имеющейся RAM. (см. скриншот ниже)
В нашем же случае, как было видно на предыдущем скриншоте, при имеющихся 4 ядрах Core i5 имеем только /dev/zram0 объёмом 1844812 байт, многопоточность работы zram обеспечивается программно.
Гибернация
Теперь перейдём ко второму компоненту нашей конфигурации — гибернации Linux. Образ оперативной памяти для гибернации Linux формирует непосредственно перед гибернацией, в указанном в /etc/default/grub файле или разделе подкачки. Рассмотрим настройки подкачки.
Для успешной гибернации системы с 4 Гб RAM, согласно рекомендациям, требуется не менее 6 Гб пространства подкачки. Как мы видим на скриншоте ниже, раздел /dev/sda2 в моей системе занимает даже больше — 8 Гб.
В моей системе реализован второй вариант конфигурации (один раздел подкачки на диске, как для подкачки, так и для гибернации, см. скриншот ниже), как сочетающий большую простоту, гибкость использования раздела подкачки и при этом более высокий уровень надёжности, чем первый вариант. Проведём тестирование этого варианта конфигурации как под высокой нагрузкой на память, так и в типовом сценарии его рабочего использования.
Цели и задачи тестирования
Положительным результатом тестирования будем считать стабильный уход в гибернацию с последующим выходом из неё при такой нагрузке на оперативную память, которая обеспечивает заполнение раздела zram или даже выход за его объём. Целевой выход за объём /dev/zram0 будем считать не более 15% от объёма RAM (0,6 Гб), что в сумме с zram и оставшейся частью RAM как раз и будет соответствовать оговорённому выше порогу комфортной работы в 165% объёма RAM.
Тестирование выбранной конфигурации
После выполнения всех необходимых настроек согласно ссылкам выше, перезагрузки и проверки успешности входа в гибернацию командой sudo systemctl hibernate, тестируем гибернацию при высокой загрузке подкачки:
Открываем Firefox, обновляем все вкладки (необновлённые вкладки сразу после открытия браузера не загрузятся, на них надо либо зайти, либо выделить несколько вкладок, нажать правую клавишу мыши и выбрать пункт «Обновить», что даёт нам довольно удобный способ регулировать заполнение RAM). Для первой проверки я обновил 160 вкладок для гарантированной подкачки значительного объёма.
Как видно из скриншота выше, загружаемые страницы вытесняются в swap раздел постепенно. Теперь запускаем гибернацию.
Как и ожидалось, после полного заполнения /dev/zram0, а затем заполнения более 2 ГБ раздела /dev/sda2, гибернация не происходит по причине нехватки свободного места в /dev/sda2 для создания образа RAM (см. скриншот с ошибкой ниже). Компьютер только блокирует сеанс пользователя.
На скриншоте выше отфильтрованы все события журнала, связанные с гибернацией (команда journalctl | grep hibernat), на скриншоте ниже — только статус самой последней гибернации (команда systemctl status system-hibernate.service):
После неудачной гибернации входим с паролем. Закрываем Firefox, открываем, затем постепенно обновляем вкладки, пока колонка Used /dev/zram0 не сравняется с колонкой Size, а колонка Used /dev/sda2 не станет больше нуля.
После нескольких уточняющих попыток выяснилось, что гибернация в моей системе продолжала штатно работать, пока данные в /dev/sda2 не переваливали за 400-500 Мб, что соответствовало примерно 162% от объёма RAM и происходило после загрузки 24±1 вкладок браузера. При использовании большего объёма памяти получаем ошибку, как на скриншотах выше.
Разумеется, при необходимости /dev/sda2 можно увеличить или даже дополнить файлом подкачки с приоритетом 2 (третий вариант конфигурации подкачки), но во-первых, поставленная при тестировании задача этого не подразумевает, а во-вторых, если какие-то из типовых задач нашей системы превысят оговорённый выше порог комфортной работы в 165% от объёма RAM, целесообразнее будет или закрывать часть ненужных программ при достижении какого-то числа уже открытых, или увеличить RAM, или перенести самые ресурсоёмкие задачи на более подходящий компьютер. В пределах же указанного объёма гибернация выполняется штатно:
Следует также отметить, что во многих случаях после пробуждения из гибернации заполнение /dev/sda2 увеличивается и достигает 0,9-1,2 Гб (часть данных при входе в гибернацию вытесняется в раздел подкачки), что при округлении в большую сторону до целых гигабайтов вполне соответствует как рекомендациям по настройке размера подкачки, так и размеру несжатого содержимого ZRAM + оставшейся части RAM.
Именно такой объём образа RAM, ко всему прочему, говорит нам о том, что оперативная память сохраняется в файле полностью — вместе с содержимым zram, которое при выходе из гибернации также восстанавливается в неизменном состоянии.
После отключения питания, повторного подключения и возврата из гибернации (чтобы гарантированно обойти гибридный режим с пробуждением из работающей оперативной памяти), все выполняемые процессы продолжаются штатно.
К сожалению, для проверки целостности процессов не удалось задействовать в тестах на гибернацию VirtualBox. Он просто предотвращает уход в гибернацию при работающих виртуальных машинах, они должны быть предварительно приостановлены, что при желании можно даже автоматизировать этим скриптом.
Операция архивирования после гибернации успешно продолжается, для загруженных до ухода в гибернацию вкладок Firefox не приходится ждать их загрузки заново. А вот менеджер обновлений системы продолжает работу хоть и штатно, но уже со следующего пакета. Пакет обновления, загрузка которого происходит при уходе в гибернацию, после пробуждения отмечается неудачно загруженным (см. скриншот ниже). Впрочем, система предупреждает о выполняющемся обновлении до ухода в гибернацию и предлагает либо отменить гибернацию, либо выполнить её принудительно.
После почти десятка повторений такой гибернации «под нагрузкой» в течение нескольких дней, а также регулярного использования гибернации в рабочем порядке, я готов признать такую конфигурацию вполне стабильной.
Если же открытые приложения заняли чуть больше 162% RAM, придётся зайти в систему, закрыть браузер (или Photoshop, видеоплеер, любое приложение, которое не потребуется при выходе из гибернации сразу же) и отправить систему в гибернацию повторно.
Итоги тестирования и выводы
В течение недели система использовалась для офисных задач, работы с браузером, настройки и тестирования различных служб и программ Linuх, установки ПО из deb пакетов, распаковки архивов и конвертации архива gzip2 в squashfs прямой перепаковкой без распаковки на диск. При этом дисковый swap /dev/sda2 начинал использоваться только при запуске виртуальных машин или обновлении более 20 вкладок Firefox. После обновления более 24-25 вкладок браузера и заполнения более 500 Мб swap раздела гибернация переставала выполняться из-за нехватки места для образа RAM в разделе подкачки. При 24-25 открытых вкладках гибернация выполнялась штатно, причём после выхода из неё swap раздел /dev/hda2 оказывался заполненным уже на 0,9-1,2 Гб.
Никаких ошибок и конфликтов гибернации и zram в течение недели интенсивной работы выявлено не было. В случае, если свободного объёма раздела подкачки не хватает для гибернации — она просто не происходит, никаких сбоев и потерь данных такая ситуация не вызывает, а при неоднократном повторении может говорить лишь о не совсем подходящей для задач конфигурации, что вполне исправимо. Если требуется отправлять систему в гибернацию с большим количеством открытых приложений и вкладок браузера, следует сделать размер раздела подкачки больше, или же добавить файл подкачки, как описано в конфигурации 3. Но при таком варианте настроек следует помнить, что, как уже подробно описано выше, даже в системе с SSD подкачка на диск заметно замедляет систему, хоть и не так критично, как с HDD. Так, в одном из случаев, когда занятое место в разделе подкачки подошло вплотную к 1 Гб, вход в гибернацию выполнялся несколько минут из-за активной работы с подкачкой, но гибернация прошла штатно.
Во время работы виртуальных машин VirtualBox гибернация невозможна, но после выключения или приостановки виртуальных машин гибернация во всех случаях работала штатно, архивация (конвертация архива) и системные обновления корректно продолжались после выхода из гибернации.
Также следует иметь ввиду, что при работе ВМ с Windows XP (1,5 Гб выделенной RAM) и обновлении более 4-5 вкладок Firefox в системе могли наблюдаться недолгие подвисания как браузера, так и виртуальной машины при их конкуренции за память и работе с дисковым разделом swap. При одновременном обновлении более 6 вкладок с работающей виртуальной машиной начинаются уже долговременные подвисания виртуальной машины и браузера (при этом в системе стоит SATA SSD, то есть, как уже отмечено выше, даже SSD не предотвращает полностью замедление системы во время подкачки на диск!). Дело тут в том, что активный объём данных, с которым в данный момент работает приложение, по определению в подкачку не вытесняется. Это актуально как для активных виртуальных машин VirtualBox, так и для загружаемых в данный момент вкладок Firefox, которые не выгрузишь в подкачку до полного окончания загрузки, оставив только одну — открытую. 3,8 Гб – 1,5 (VirtualBox) – 1,8 (zram) = 0,5 Гб. По нынешним временам это в лучшем случае 2-3 вкладки…
Автор статьи @Kssenofont
НЛО прилетело и оставило здесь промокод для читателей нашего блога:
-15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.
