27

ALT Linux p9 и диски SSD

Случилось прекрасное. Вы обладатель SSD накопителя, на который установили систему ALT k/Workstation или Simply, тем самым подняв ее быстродействие до запредельных высот. Все хорошо, вот только настоящее устройство обладает ограниченным количеством раз записи информации. А Linux, как и многие другие ОС, весьма часто обращается к накопителям читая и сохраняя временные файлы, журналы работы и различные кэши. В принципе, ничего особо страшного – внутренние механизмы последних ядер скидывают данные на носители реже, предпочитая держать их в памяти, для ускорения доступа. Тем не менее, обмен информацией все же идет.

Будет рассмотрен комплексный подход для ALT Linux 9, позволяющий снизить нагрузку на SSD диск. И начнем мы со свопа. Последний нужен только в тех случаях, когда информация не помещается в памяти. Используется он и для обеспечения быстродействия работы, то есть отключать его совсем нельзя. Но можно перенести своп в память, держа его там упакованным, при помощи программы zram. В ALT установку ее можно произвести через Synaptic или воспользовавшись командной строкой. Понадобится два пакета: alterator-zram-swap и zram-swap. Итак, для консоли:


su -
<вводите пароль root>
apt-get install zram-swap alterator-zram-swap

После, заходим в «Центр управления системой» из главного меню рабочего стола. Ищем «Настройка zram-swap». Кликаем по пункту и в открывшемся окне устанавливаем флажок на «включить модуль zram-swap». Следом «применить» и можно закрывать окно.

Теперь правим подключение физических накопителей. Нужно вначале выяснить, на каком из них находиться SSD. Смотрим командой lsblk. Выдается список всех разделов и их UUID. Вот последние нам и нужны. У меня на представленной картинке «/» и «home» висят на SSD.

Открываем файл /etc/fstab в текстовом редакторе конкретной системы. В Workstation это xed, в той что с индексом k вначале — kwrite, для Simply — mousepad.

Находим все упоминания swap в файле и удаляем содержащие их строки целиком.

Находим записи, относящиеся к SSD, и в конце каждой из них, но перед последними двумя цифрами добавляем опции «,data=writeback,delalloc,nobarrier». Пример:

Идем дальше. Папку /tmp запихиваем в память, и вносим аналогичную запись для /home/tmp. Последнего каталога не существует, но он нужен (честно скажу — хз зачем, но файлы в нем появляются) и мы создадим его вручную позже. Итак, что добавить в конец /etc/fstab:

tmpfs /tmp/ tmpfs nosuid,nodev 0 0
tmpfs /home/tmp tmpfs nosuid,nodev,size=128M 0 0

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


Можно перекинуть аналогично в память /var/log, но некоторым пользователям бывают нужны журналы выполняемых программ. Если все же возникла такая идея, то добавляем в fstab:


tmpfs /var/log tmpfs nosuid,nodev,noexec,size=64M 0 0

Сохраняем, введя пароль администратора и закрываем kwrite.


Подождите перегружаться, еще не все.


Если приведенная настройка выполнялась для раздела «/», – требуется об этом напрямую проинформировать ядро. Открываем через kwrite (или иной текстовой редактор) файл /etc/sysconfig/grub2


Находим строчку, начинающуюся с GRUB_CMDLINE_LINUX_DEFAULT. Перед splash размещенном в одинарных кавычках, указываем « rootflags=data=writeback » (с пробелами до и после). Сохраняем.

Теперь путь наш лежит в консоль. В ней:


su -
<вводим пароль рута>
update-grub

Здесь же создаем точку монтирования tmp в home:


mkdir -pv /home/tmp

Если выкинули в память /var/log, то требуется после перезагрузки восстанавливать его каталоги. Нужно для некоторых программ (Не помню, какая ругалась, но было. Вроде rpc bind). Создаем файл /etc/rc.d/rc.local следующего содержания:


#!/bin/sh
mkdir -p /var/log/ahttpd \
/var/log/audit \
/var/log/chrony \
/var/log/cups \
/var/log/journal \
/var/log/mysql \
/var/log/ppp \
/var/log/private \
/var/log/samba/old \
/var/log/wpslog

Сохраняем, делаем исполняемым из консоли:


su -
<вводим пароль рута>
chmod +x /etc/rc.d/rc.local

Примечание: человек, администрирующий ваш компьютер (если это не вы) может сильно огорчиться узнав, что логи вы держите в памяти и обновляете их с нуля при каждом запуске машины. Ведь они показывают и неисправности. Я крайне не рекомендую помещать в tmpfs /var/log. Но каждый сам кузнец своего счастья.

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


Firefox:

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

Находим и меняем параметры:


browser.cache.disk.enable и ставим его в false
browser.cache.memory.enable в True (если не установлен)
browser.cache.offline.enable в false
browser.cache.memory.capacity устанавливаем в -1

Chrome, Edge, Chromium, Yandex browser.

Первое, что нужно сделать найти содержащий их запускающий файл .desktop. Выполняем в консоли:


cd /usr/share/applications
grep -l 'yandex-browser' *.desktop
grep -l 'chrome' *.desktop
grep -l 'chromium' *.desktop
grep -l 'edge' *.desktop

Результат - список .desktop содержащих командные строки запуска браузеров.


Во всех найденных файлах, в конце строчки Exec= добавляем « -disk-cache-dir=/tmp». Сделать это можно при помощи того же kwrite. Внимание! В файле .desktop может быть несколько таких строк. Везде требуется вписать добавочные параметры.

Побочным действием будет некоторое ускорение работы интернет-браузера.


Вот и все!


UPD: Чуть не забыл. В crontab от рута нужно добавить /sbin/fstrim -A на то время, когда машина точно включена. К примеру, у меня строка имеет вид:


0 5 * * * /sbin/fstrim -A

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


UPD2: В связи с частым вопросом зачем нужно размещать своп в память и использовать zram, объясняю в комментарии https://pikabu.ru/story/alt_linux_p9_i_diski_ssd_7914443?cid=188141077


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

GNU/Linux

1.2K поста15.6K подписчика

Правила сообщества

Все дистрибутивы хороши.

Будьте людьми.

Вы смотрите срез комментариев. Показать все
Автор поста оценил этот комментарий

Маленький аптейт про то, зачем нужен своп в памяти. Файл swap служит ее расширением. Когда заканчивается место указанное в vm.swappiness, процентами от свободной памяти, ядро начинает сбрасывать редко используемые данные во внешний файл - своп. Используя zswap можно сделать его сжатым, так как в основном он пуст и просто занимает место. Рассмотрение его компрессии на устройстве постоянного хранения выходит за рамки статьи, поэтому рассматриваться не будет. Описанная же технология zram позволяет разместить его в оперативную память компьютера, уже в сжатом виде. В чем плюс: скорость записи/чтения. Особенно на старых машинах. К примеру, вот SSD:


sudo hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 800 MB in 3.00 seconds = 266.61 MB/sec

А вот zram:

sudo hdparm -t /dev/zram0
/dev/zram0:
HDIO_DRIVE_CMD(identify) failed: Inappropriate ioctl for device
Timing buffered disk reads: 742 MB in 1.03 seconds = 718.02 MB/sec

Разница в скорости почти трехкратная в пользу оперативки.

Опять же. Своп занимает место памяти, только в том случае, если используется. В остальных его объем 0. И даже когда идет обмен данных с ним через zram, они сжимаются приблизительно в три раза. На половину каждого оставшихся свободными гига оперативки вы получаете 1,5 Гб дополнительного свопа. То есть, осталось 2 Гб. Считаем: 2Гб/2*3=3Гб свопа. +1Гб оставшейся доступной оперативы.


Принцип использования zram не позволяет перехватывать на блочные устройства более половины оставшегося места. Работает утилита не только в отношении файла подкачки. Любое блочное устройство размещенное в памяти сжимается. В статье на таких (tmpfs) размещены каталоги /tmp /homt/tmp /var/log

раскрыть ветку (2)
2
Автор поста оценил этот комментарий

Когда заканчивается место указанное в vm.swappiness, процентами от свободной памяти
swappiness - это не процент. Несмотря на то, что изменяется в пределах сотни. Это значение, задающее приоритет анонимных страниц памяти перед "page cache". Если установить vm.swappiness=100 то их приоритет с точки зрения kswapd будет одинаков и, соответственно, он будет одинаково сканировать оба типа страниц.

раскрыть ветку (1)
Автор поста оценил этот комментарий

И что, мне нужно было половину хабра засунуть и kernel.org с описанием что такое своп? Сделал проще -- "дополнительная память", "процент" для кофейников. В любом случае, что ни говорите - память у вас эти данные занимают? Нужно от них избавиться? Сжимаем и помещаем для скорости на виртуальное блочное устройство. В объеме оперативки образуется свободное место? ДА или НЕТ? Часть мы оперативки фактически сжали. Стало места больше текущим программам? Если требуется обратиться к сжатым данным, не получит ли доступ к ним ядро быстрее с оперативки, чем из физического накопителя? Ответьте для себя на вышеназванные вопросы, а потом оспаривайте статью.


Тут еще нужно сделать маленькое отступление сжатие сбрасываемых данных в виртуальный своп относится к потокам и происходит единовременно. Т.е. не храниться на виртуальном блочном устройстве (грубо) swap.zip. Сжатие происходит частей в него записываемых.

Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку