Performance ru

Производительность

Настройка производительности в MiniOS — это в основном баланс между временем загрузки, использованием RAM, чтением во время работы, издержками на сохранение и надежностью хранения данных. Для точного описания параметров и границ безопасности используйте Режимы загрузки, Загрузка модулей initrd, и Сохранение initrd.

Параметры загрузки для производительности

Параметры загрузки позволяют перераспределять работу при старте и обращения к данным между RAM и исходным устройством. См. Параметры загрузки для полного списка.

Загрузка системы в RAM (toram)

toram может снизить задержки во время работы при использовании медленного USB-устройства или ISO по сети, но увеличивает время загрузки и существенно увеличивает занятость RAM. Обычный toram использует полный копирование. toram=trim обычно расходует меньше RAM, но из-за ограниченного копирования могут отсутствовать данные или модули, которые понадобятся позже.

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

Фильтрация модулей (load и noload)

Фильтрация позволяет уменьшить объем копируемых данных и количество монтируемых слоев, особенно при toram=trim. Это приводит к менее функциональной системе и большему риску сбоев при загрузке или работе, если какая-либо зависимость не будет включена. Проверьте итоговый набор модулей; синтаксис фильтрации и ограничения защищенных модулей описаны в разделе Загрузка модулей initrd.

Оптимизация сохранения данных

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

Режимы сохранения (perchmode)

• native: Сохраняет изменяемый слой напрямую как обычные файлы. Это обеспечивает минимальные накладные расходы контейнера и отсутствие фиксированного размера, но требует файловой системы, поддерживающей Linux-метаданные и операции, необходимые для MiniOS.
• raw: Использует один ext4-образ с фиксированной ёмкостью. Длина файла устанавливается в соответствии с заданной ёмкостью, а увеличение объёма происходит явно, что делает этот режим простым и предсказуемым, но он не поддерживает динамическое выделение, как у других бэкендов. FAT32 ограничивает размер одного образа 4000 МиБ.
• dynfilefs: Бэкенд FUSE/format-400 увеличивает хранилище по требованию и поддерживает носители, которые иначе были бы непригодны. Его индекс не разрежённый: каждый объявленный логический блок 4 КиБ требует одного смещения размером 8 байт, поэтому логическая ёмкость требует примерно 2 МиБ RAM и около 2 МиБ индексного хранилища на каждый ГиБ, даже если полезная нагрузка пуста. Это делает режим эффективным для средних объёмов, но дорогим по ресурсам для больших тонких хранилищ.
• dynblk: Бэкенд format-1 DBSPRS01 ядра хранит таблицы отображения на диске и ограниченный кэш метаданных в RAM (по умолчанию 1 МиБ). Заполнение существующего устройства не требует выделения полной карты в памяти. Описания экстентов и каталоги масштабируются в зависимости от объявленных частей; кэш файлов и память кодека используются дополнительно. dynblk limits --format dynblk сообщает о максимальной геометрии; dynblk status /dev/dynblkN --json отображает учтённые буферы и статистику кэша. Обычные перезаписи остаются на месте; частичные сжатые обновления в данный момент пересжимают 64-КиБ блок. Выбирайте политику кэширования вложений осознанно: unsafe отказывается от гарантий надёжности.
• vmdk: Использует драйвер ядра DynBlk со стандартным раздельным разрежённым VMDK-хранилищем. Объём увеличивается по мере необходимости, но сжатие на уровне бэкенда отсутствует. Как и нативные контейнеры DynBlk, его можно копировать в RAM независимо от системных модулей и явно сохранять обратно на диск.
• squashfs: Сохраняет сжатый снимок и восстанавливает изменяемый верхний слой в RAM при каждой загрузке. Это минимизирует постоянное хранилище для в основном стабильных сессий, но требует затрат CPU и RAM при восстановлении и пересохраняет снимок при сохранении. Если позволяет память, при сохранении создаётся стабильная копия изменений в RAM и сразу сжимается в отдельный файл в каталоге сессии. После проверки и синхронизации MiniOS атомарно заменяет changes.sb; второй сжатый файл не создаётся. Если RAM не может вместить дерево подготовки, используется существующее дисковое рабочее пространство для этого дерева.

LUKS2 может использовать Raw, DynFileFS, DynBlk или VMDK. Шифрование добавляет задержку при разблокировке и криптографическую нагрузку, сохраняя при этом ёмкость и поведение исходного бэкенда. Сжатие DynBlk отключается при использовании LUKS2; VMDK никогда не поддерживает сжатие на уровне бэкенда.

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

Сократите количество операций записи в кэш и логи с помощью perch

Конфигуратор MiniOS — вкладка Дополнительно предоставляет отдельные параметры хранения для обычных системных логов, загрузок APT и стандартных кэшей браузеров. Эти параметры также работают в minios/config.conf или его config.conf.d/*.conf фрагментах:

LIVE_LOG_STORAGE="volatile"
LIVE_APT_CACHE="volatile"
LIVE_BROWSER_CACHE="volatile"

Каждый параметр принимает persistent (по умолчанию) или volatile. После изменения параметра перезагрузите систему. minios-boot применяется только после успешной активации постоянного хранения на долговременном носителе или в записываемой сессии RAM с защищённой ram-origin записью; просто запросить постоянство недостаточно. Для однократной загрузки используйте log-storage=volatile, apt-cache=volatile или browser-cache=volatile на командной строке ядра. Формы с префиксом live-config.- также работают и имеют приоритет над файлами конфигурации. Эти параметры не активируют perch самостоятельно. Подробнее см. в разделе Файл конфигурации о порядке обработки исходных файлов и в разделе Параметры загрузки о полной синтаксической структуре.

Параметр	Что остаётся в RAM при volatile	Что сохраняется на постоянном носителе
LIVE_LOG_STORAGE	Журнал systemd (максимум 32 Миб) и обычные /var/log файлы (32 Миб tmpfs).	Диагностика загрузки в /var/log/minios/ и /var/log/live/, включая три предыдущие версии логов.
LIVE_APT_CACHE	Загруженные пакеты в /var/cache/apt/archives (256 или 512 Миб tmpfs, в зависимости от доступной памяти).	Состояние пакетов в /var/lib/dpkg, списки репозиториев в /var/lib/apt/lists, а также установленные файлы.
LIVE_BROWSER_CACHE	Один общий tmpfs 512 Миб для стандартных каталогов кэша Firefox/ESR, Chromium, Chrome, Edge, Brave, Vivaldi, Opera и Yandex Browser в домашней папке live-пользователя ~/.cache. Системная политика отключает дисковый кэш Firefox.	Профили, cookies, пароли, данные сайтов и кэши других приложений.

Кэши APT и браузеров RAM пропускаются, если доступно менее 1 Гиб или активен swap не на zRAM. Архив APT в tmpfs не переполняется на устройство: загрузка, превышающая оставшийся объём, может завершиться неудачей. Существующий кэш Firefox policies.json не заменяется; проверьте его настройку дискового кэша отдельно. Стандартные пути кэша браузеров подготавливаются после создания live-пользователя, включая случаи установки браузера позже. Пользовательские пути, установки Flatpak/Snap и пользователи, созданные после этой настройки, не перенаправляются автоматически. Ранее сохранённые кэши браузеров скрываются монтированиями RAM на эту загрузку и снова становятся доступны при возврате к persistent.

При долговременном сохранении логи загрузки всегда остаются в записываемом хранилище сессии независимо от параметра обычных логов; долговременная сессия SquashFS хранит их вне changes.sb, поэтому они не зависят от сохранения снимка при завершении работы. Копия сессии, созданная через perchtoram — это другой случай: её логи остаются в памяти до сохранения на диск. При volatile остальные файлы в /var/log (включая текстовую историю APT/dpkg) удаляются при перезагрузке. EXPORT_LOGS=true — это отдельный явный экспорт на носитель MiniOS. При заполнении tmpfs для логов (32 Миб) новые записи не принимаются и не переносятся на флеш-накопитель. Если позже будет подключён swap на диске, файлы из памяти могут быть выгружены туда. Подробнее см. в разделе Устранение неполадок о поиске диагностических логов загрузки.

MiniOS также использует noatime при монтировании собственных данных и контейнерных файловых систем, чтобы избежать обновления метаданных времени доступа; это не перемонтирует другие пользовательские диски. Стандартный relatime уже ограничивает такие обновления, поэтому перед тем как считать это значительной экономией, проверьте разницу на практике. Журнал файловой системы, барьеры и fsync должны оставаться включёнными для съёмного постоянного хранилища.

Для контролируемой записи лог-файла объёмом 16 Миб с последующим sync, виртуальная машина Testo зафиксировала 33 304 сектора, записанных на нижний виртуальный диск в режиме постоянства, и 8 — в режиме volatile. Это демонстрирует изменение пути записи для такой нагрузки. Это не измеряет записи внутри контроллера USB-накопителя и не предсказывает срок службы NAND. Для объективных выводов о сроке службы сравнивайте идентичные рабочие нагрузки приложений на реальном устройстве.

Настройка ZRAM

Zram использует ресурсы процессора для увеличения объёма сжатой памяти и может избежать использования гораздо более медленного подкачивания на диске. Большое устройство zram позволяет хранить больше неактивных страниц, но не создаёт физическую RAM; несжимаемые рабочие нагрузки всё равно занимают память. Алгоритмы сжатия балансируют между пропускной способностью, загрузкой процессора и степенью сжатия, а их доступность зависит от ядра. Начните с алгоритма по умолчанию и изменяйте zramsize, zramcompили nozram только для конкретной рабочей нагрузки; см. Параметры загрузки для допустимых значений.

Файловые системы и оборудование для хранения данных

• Выбор устройства: Более высокая последовательная скорость передачи сокращает время копирования больших модулей, а низкая задержка при случайном доступе важнее для постоянных рабочих нагрузок на настольных системах. Оценивайте устройство вместе с корпусом; только по поколению USB нельзя судить о производительности флеш-накопителя или SSD.
• Выбор файловой системы: Родная файловая система Linux позволяет использовать нативную устойчивость без накладных расходов на контейнер. Кроссплатформенные файловые системы повышают переносимость, но для поддержки метаданных Linux требуется совместимый контейнерный бэкенд, что добавляет слои отображения и файловой системы. Выбирайте с учётом требований к переносимости, восстановлению и результатам тестирования.